Each user has multiple sites they can access reporting data for in an application I am working on. To prevent having to go to the database on every single request, I validate that they have access to the site only when they change sites and I then store the the current site id in the session.

I am trying to eliminate session state so that my async ajax requests are not synchronized and also so that the user can have a different site open on each browser tab. I also don't want to go back to calling the database on every request to validate that the user has access to the given site making a request. I've seen implementations where people will encrypt the id on the client, but it's not sure what would prevent a third party from looking over someone's shoulder (seeing the id on the query string perhaps) then using that same id with their own login to make a request.

I have two ideas:

1) Encrypt the id with the persons authenticated user name as the seed... Then encrypt it again with some private key. When the request comes in I would decrypt with the private key then try to decrypt with the current user name and get the id back. Or perhaps I would combine the user name with the id like username@username.com_[SITEID] then encrypt that with the private key and split them to see if the current username matches the first part. The problem with this though is that it never expires really, so they could in the future make a request even if they have lost access as long as they have the id around.

2) Similar to idea 1, but I would use the session id with encryption as a third key perhaps. The problem here though is if the session expires and they leave a tab open, all the requests would fail from the tab that was left open even though a session is active.

3) Use a cache so that async requests are not affected and just store keys like username@username.com_[VALIDATED_SITE_ID] then see if the key exists when the request comes in and if not, hit the database to establish the validation key.

Has anyone addressed this type of scenario where you need to validate the user can make a specific type of request, yet you doing it without session or hitting the database every time a request is made?

  • What's wrong with hitting the database? – Dan Pichelman Aug 2 '14 at 14:26
  • It reads like you're trying to re-invent some variation of the "remember-me" functionality. All your options involve either hitting the database multiple times to verify info or storing info in the session - "Use a cache", cache where? – kolossus Aug 3 '14 at 16:03
  • I don't want to use the database for performance reasons. The app is responsible for verifying their identity and whether or not they can make the request to the database. I use the windows azure cache as well as the redis cache which doesn't have the issues with using session state as long as I don't use the actual session provider. As soon as you use session your async requests will become parallel because of the locking. I can set no session on each controller but every controller needs to look in session so I need to eliminate the calls to session. – KingOfHypocrites Aug 3 '14 at 16:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.