I would like to do both of the following things:
use audit triggers on my database tables to identify which user updated what;
use connection pooling to improve performance
For #1, I use 'system_user' in the database trigger to identify the user making the change, but this prevent me from doing #2 which requires a generic connection string.
Is there a way that I can get the best of both of these worlds?
ASP.NET/SQL Server 2005
Unfortunately, no. Identifying the user just from the database connection AND sharing database connections between users are mutually exclusive.
Store the user from your web application in the database and let your triggers go off that stored data. It might even be better to let the web app handle writing all logging information to the database.
Related
Im developing a database application using MariaDB where I have a table for clients registers. I want them to be able to query the database, but I don't know if I have to create a database user account for each one in order to allow simultanious connections without collitions(same user trying to query at the same time) or can I use the same user account for simultanieous queries.
I'm kind of new to MariaDB.
Thanks in advise.
Databases are good at handling 'simultaneous' accesses by multiple connections to the same table.
The question of "one" versus "many" user accounts is independent of simultaneous access.
Most accesses work just fine without any problem. In the extreme, I suggest you read about "deadlocks".
I am currently testing signalr with sql server as my backplane. If I switch sql with redis, how would I be able to incorporate sql database in that design via programming not set up.
For example My stored procedure saves user profile properties like (height, interests), now when i need to grab that information into an object along with data in redis(how many likes a photo has within that user profile by providing the user profile as a key).
I initially had sql server doing the work where I edit the number of likes on the table and bam, it pops up automatically with signalr like it supposed to.
Now because of performance reasons I would like the same results, except having redis storing the likes of the user profile, and sql persisting the rest of the user profile object.
Sorry if I confused anyone, let me know and I will re-edit immediately.
In the past, when I implemented my own authentication mechanisms I would have a user table with relationships to other tables in my application's MySQL database. However, now that I'm considering using ActiveDirectoryMembershipProvider, I see no way to create similar relationships between AD users and those tables.
What's the normal way to resolve this issue? Should I just accept the fact that someone could potentially insert records with user IDs that don't correspond to existing users? I don't realistically expect this to happen, but I'm used to ensuring integrity at the database level.
I think you'll have to give up on database referential integrity in this case. Just have your application code check for the existence of the Active Directory account before adding the record to the DB.
In theory, some user could go in manually and type a SQL INSERT statement which refers to an invalid AD account. But in practice, hopefully you aren't giving a bunch of users direct table access. If the application code is the only thing accessing the DB, the application code is validating the account before inserting the row, and that validation code is tested, then you should be OK.
Just to be safe, you could have a nightly batch process that validates all rows in your referencing table(s) against Active Directory. If it finds any inconsistency, it can send you an email. This won't prevent integrity violations, but at least it will let you know about them.
I don't know of anyway you could do this via MySQL. If you were using SQL server, you could write a trigger that would call a C# dll that would verify that they were an AD member. Then if they weren't you could block the insertion into the DB. You might be able to do something like this with MySQL, but my knowledge of MySQL is pretty slim.
I am using a ASP.net session in SQL Server mode. I have created the necessary tables and stored procs in a custome db
My question is:
Can I use this database to serve more than one application / web site ?
Is there anything to take into consideration having multiple websites use the same db for their session store
cheers
Yes you can use this database to server more than one site. The session provider will take care of the semantics of that.
It would make the profiling more difficult if there is a performance problem. Why not create a second state db for the second application? It's not much to do, simple with a different name and specify the different db in your session configuration.
The short answer though is you can use the same session database and each session should be fine, though I wonder if anyone has any comments on colliding sessionIds between the two applications.
My company is building an ASP.NET HR application and we have decided to create one database per client. This ensures that clients cannot accidentally view another client's data, while also allowing for easy scalability (among other benefits, already discussed here).
My question is - what is the best way to handle security and data access in such a scenario? My intent is to use a common login/account database that will direct the user to the correct server/database. This common database would also contain the application features that each user/role has access.
I was not planning to put any user information in each individual client database, but others on my team feel that the lack of security on each database is a huge hole (but they cannot articulate how duplicating the common access logic would be useful).
Am I missing something? Should we add an extra layer of security/authentication at the client database level?
Update:
One of the reasons my team felt dual user management was necessary is due to access control. All users have a default role (e.g. Admin, Minimal Access, Power User, etc.), but client admins will be able to refine permissions for users with access to their database. To me it still seems feasible for this to be in a central database, but my team doesn't agree. Thoughts?
We have a SaaS solution that uses the one DB per client model. We have a common "Security" database too. However, we store all user information in the individual client databases.
When the user logs into the system they tell us three pieces of information, username, password and client-id. The client-id is used to lookup their home database in the "security" database, and then the code connects to their home database to check their username/password. This way a client is totally self-contained within their database. Of course you need some piece of information beyond username to determine their home database. Could be our client-id approach, or could be the domain-name requested if you're using the sub-domain per client approach.
The advantage here is that you can move "client" databases around w/out having to keep them synced up with the security database. Plus you don't need to deal w/cross-db joins when you're trying to lookup user information.
Update: In response to your update... One of the advantages to each customer having their own DB is also the ability to restore a customer if they really need it. If you've split the customer's data into two databases how do you restore it? Also, again, you'll need to worry about cross-db data access if the users are defined in a DB other than the home DB.
I've always been of the opinion that security should be enforced at the application level, not the database level. With that said, I see no problem with your intended approach. Managing accounts and roles through a central database makes the application more maintainable in the long run.
You may want to look into using the ASP.NET membership provider for handling the authentication plumbing. That would work with your stated approach and you can still keep all of the authentication data in a separate database. However, I agree with Chris that keeping one DB will utlimately be more maintainable.