Settings per connected user

Question

I have an windows forms application which I'm migrating from MySql to MsSql. In MySql we are using database users for every user. So every user connects to the database using their own account. This is not what we want, because in the future we want the application set open to the world and database users is not a thing on the wishlist. So this is going away.

The problem is that many views work with a function which uses CURRENT_USER() to give access to records (because users are part of a department and are not allowed to see all records of all departments).

In MsSql we are using just one type of connectionstring, but every application connects the database directly. Is it possible in MSSQL to store variables per connection so I can identify a user in the view by the variable I set after creating the connection?

So it would be like this:

1. Start application
2. Users logs on
3. Application creates connection with mssql
4. Application sets a variables on sql-server
5. User opens a screen with a view
6. SQL server returns the view using the variable that has ben set earlier to only return the allowed records to view.

So every user must have it's own variable. Is that possible?

Application is build with NET and iBatis. Not the best combination, but iBatis is to much integrated to throw it all overboard.

Answer 1

While this may or may not be possible, it's definitely not the right way to go. As you said, you're using a single connection string, and likely using a pool of connections to access the database. As you want users to be able to pick any available connection in the pool to do their queries, you don't want any user state (or any state at all for that matter) to be tied to the connection.

As you're opening up to the world, you don't want the application to directly connect to the database. Instead, you should implement middleware that will handle authentication and access rights, and only return data from the database that the user may access. So instead of

user application <- iBatis -> MSSQL

you'll have:

user application <- HTTP/something else -> API <- iBatis -> MSSQL

This is the approach taken used by websites as well. In addition, you'll be able to add functionality like caching, connection pooling etc. to the API, making it possible to support more users.