1

In my ASP.NET MVC application I allow users to log in. Each user is associated with a company. Company ID and company data is not part of the Users table in the database. User and Company are connected through a related table (one to many relationship). Company ID is not part of the Users table as a foreign key because the design of the Users table did not predict that and we are not allowed to change it.

When user logs on we want to take the company ID for this user and store it somewhere. We would use this ID later for querying and other kinds of filtering by company because the content is stored per company.

Where should I store the company ID setting to make it persistant over many web request?

mare
  • 13,033
  • 24
  • 102
  • 191

3 Answers3

3

I see three viable options

  • Session

  • Cookie
    This may or may not be in the authentication cookie, your choice.

  • Keep it in the database
    Query as and when needed. If it's needed less than x% of the time, just fetch it as and when needed from the datasource.

Russ Cam
  • 124,184
  • 33
  • 204
  • 266
  • 2
    I would vote for "Keep it in the database" for performance reasons alone. – NotMe Oct 26 '10 at 21:48
  • I eventually decided to go with Session but to store it in SQL Server for the sake of reliability. – mare Oct 29 '10 at 17:47
  • @mare- does that offer any advantage over having it in the database, if your using SQL server based session storage? – Russ Cam Oct 29 '10 at 19:54
  • For me the advantage is that I used aspnet_regsql to create the two Session tables in my database and when setting up the correct connection string in web.config I am able to use the builtin SQL Session state provider and that has saved me from writing a single line of code for Session management. – mare Oct 30 '10 at 11:45
  • @mare - what I mean though is that the value is coming from a database originally, is put into session, which is database backed. Each time it is needed from session, a database call needs to be made, which doesn't seem to yield any advantage over retrieving it from where it is originally stored. – Russ Cam Oct 30 '10 at 12:26
  • @ChrisLively let me ask you about the "Keep in the database". Is it better because it keeps the system stateless, thus reducing server load (doesn't have to keep sessions)? The idea should be creating a table with UserId and SelectedCompany for example for this situation? If I saved in the AuthenticationCookie wouldn't the result be the same (or even better, if I log with the same user in 2 browsers I would be able to select 2 different companies to work on)? – Rafael Merlin May 12 '14 at 16:50
  • 1
    @RafaelMerlin: It really boils down to how you intend to use it. If the user is only ever associated with a single company then it should be in the database in order to facilitate security. If a user is associated with multiple companies, but has the ability to select one to work with then you'll likely want to store that selection in a cookie or session... while ensuring the user still has access to that company on each query. This would allow you to have multiple browsers, same user and be able to have different companies pulled up. – NotMe May 12 '14 at 19:39
1

Maybe this sounds so stupid but.. what about storing the info into an object and putting that object in the session?

Jesus Rodriguez
  • 11,918
  • 9
  • 64
  • 88
  • I am using the session currently. So that is one option. I am looking for other options also. – mare Oct 26 '10 at 21:39
0

Most people use Session or Cookies for this type of functionality:

Can't answer any better than the answers in this question:

Cache VS Session VS cookies?

Community
  • 1
  • 1
John Farrell
  • 24,673
  • 10
  • 77
  • 110