locked
Need to disable cache to force session values to load every time RRS feed

  • Question

  • User1300871232 posted

    We have an application in which the default.aspx.cs loads permissions.  But sometimes after changing the permissions, it ignores the latest changes until the cache is cleared.  After the cache is cleared, restarting the application indeed does cause the permissions to sync.

    Ideally we want to programmatically clear the cache.  How can this be done with asp.net and/or javascript?  The session values must load when it hits this page, no values should be remembered or cached.

    Monday, December 28, 2015 10:26 PM

Answers

  • User1300871232 posted

    Just to update everyone, I think I figured out the issue.  Thank you for suggesting that it was sessions and not the cache.  By clearing all internet explorer settings and seeing it work, I conflated it.

    The sessions has a 'memberid' in the database but if you change that 'memberid' the session can still outlive the database.  So dbasarab/ebsoftware in the database has a member id of 'xxx' but still maintains a server session id of 'yyy.'

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, December 30, 2015 10:02 PM

All replies

  • User475983607 posted

    Cache, Session, and user credential are 3 different frameworks and cache can exist on the client or server.  It's a bit difficult to provide assistance without knowing how the application is designed, specifically security.

    Tuesday, December 29, 2015 1:14 AM
  • User614698185 posted

    Hi dbasarab,

    Modify your OnLoad code to only clear the session when that login page is called for the first time, not on postback:

    protected void Page_Load(object sender, System.EventArgs e)
    {
    	if (!IsPostback) {
    		Session.RemoveAll();
    		Session.Clear();
    		Session.Abandon();
    	}
    }

    Best Regards,

    Candice Zhou

    Tuesday, December 29, 2015 9:26 AM
  • User1300871232 posted

    This destroys only sessions for one user, correct (the user who clicks the page)?  I don't want to destroy sessions for every user in the application.

    Tuesday, December 29, 2015 1:57 PM
  • User475983607 posted

    IMHO, this is a design issue. If permissions are updated in the DB but not immediately reflected in the application then you must have implemented some form of ASP State Management to store access rights.

    In the past, I've used server cache to persist user's access to resource simply because the access roles did not change often and it seemed like a wasted of resources to continually query the DB for same results set on every request when I could simply query the cache. However, this design posses an issue when access rights change because the cache and DB become out-of-sync.  To mitigate the design issue, I set the cache to expire every 5 minutes and wrote code to re-populate cache when cache is empty.  The cache and DB are out-of-sync for a maximum of 5 minutes which was acceptable for this particular application.

    Maybe you can implement something similar.  Again, without details on the design it is difficult to provide assistance.

    Tuesday, December 29, 2015 3:45 PM
  • User1300871232 posted

    The problem is that our website is designed such that if the session did expire, they would be knocked back to the original default.aspx file when they were browsing deeper into the website.

    We consider it acceptable if the permissions are out of sync when the users is already past the default.aspx file browsing deeper into the application, but we need to make sure they when first entering the application, permissions are checked every time.

    If the code given earlier kills the session for the user that clicked the page and then initiates a new grabbing of the permissions - great.   But if this code resets the session for all the users, then every single user will knocked to the home page when any user looks at it.

    Wednesday, December 30, 2015 2:38 PM
  • User475983607 posted

    dbasarab

    The problem is that our website is designed such that if the session did expire, they would be knocked back to the original default.aspx file when they were browsing deeper into the website.

    We consider it acceptable if the permissions are out of sync when the users is already past the default.aspx file browsing deeper into the application, but we need to make sure they when first entering the application, permissions are checked every time.

    If the code given earlier kills the session for the user that clicked the page and then initiates a new grabbing of the permissions - great.   But if this code resets the session for all the users, then every single user will knocked to the home page when any user looks at it.

    This is a common design issue that pops up when credentials are tied to Session (server persistence) as apposed to the conventional method of using a token (client persistence).  In my experience, developer use Session because it's relatively easy, readily available, and saves trips to the database but they fail to look at the down side of using Session.  1) User credentials (or whatever data sets) are stored in two different places the DB and Session.  This causes syncing issues as stated above 2) In the case of user credentials, the user must login again if the Session expires for any reason. There is no way to repopulate credentials in Session because the credentials are stored on the server. 3) Session does not scale well.

    I have a rule when it comes to using session in any design.  Never store anything in Session that I can't easily re-populate without user interaction.  

    IMHO, you are left with two options.  Either band-aid the current design or fix the design to use a conventional token.  

    Band-aid ideas:

    Add an extra layer that checks the user's credentials on every request as long as Session is not null. This can be done in the Global.asax.

    -or-

    Cache a global timestamp flag when access rights have changed.  Set the cache to timeout out at some interval and add code to repopulate the cache when it is empty. Then on each request compare the user's login timestamp to the cached timestamp flag. If the user timestamp is less than the timestamp flag, reset the user's Session. You might have to add a login timestamp to the user Session.

    Wednesday, December 30, 2015 3:37 PM
  • User1300871232 posted

    I think what you are implying is that there is no easy way to know which session from the server side is tied to which application user and selectively kill them.  This also implies that the commands listed above, earlier in the thread, kill every session.

    Is there anything that can be done client side in javascript to portray the client in such a way that the server would give it a new session?

    One solution, with its cons of course, is just to kill all sessions whenever security permissions are updated, warning the administrator with a message box.   Basically the boss tells his workers to hit save.  Or there could be an autosave, but you're back to pros and cons, as is the case in every single path.

    Wednesday, December 30, 2015 6:12 PM
  • User475983607 posted

    I think what you are implying is that there is no easy way to know which session from the server side is tied to which application user and selectively kill them.  This also implies that the commands listed above, earlier in the thread, kill every session.

    I'm not implying anything.  Session functionality is openly published and I assumed - maybe wrongly - that you knew how Session worked.  Session is a .NEt framework where user Session values are stored in server memory and the user (client) is given a key to unlock Session.  The first time Session is set, the server sends the key in the form of a Session cookie to the client. The client browser sends the Session cookie to the server on each and every subsequent request to unlock and retrieve the Session values.  The link between Session and the client is this cookie.  

    If you wanted to update all user Sessions you would need all the active the Session cookies.  I suppose you could store the cookies in a database when Session is established and remove the cookie when session expires. With Session Cookies persisted in the DB it's technical possible to update the user's Session, warmly referred to as Session Hijacking. Craft a utility app that retrieves all the current open session from the DB.  Loop through each Session ID and send a request to a utility page to update the user's Session contents.  

    Alternatively, you could move to SQL Session server.  I've never tried it but you might be able to script an update for updating Session.

    Is there anything that can be done client side in javascript to portray the client in such a way that the server would give it a new session?

    All the client's information comes from the server and the server has the Session not the client.  If the server is aware that a change occurred, the server can pass this information on to the client.  I'm not sure how useful this information is to the client.  

    One solution, with its cons of course, is just to kill all sessions whenever security permissions are updated, warning the administrator with a message box.   Basically the boss tells his workers to hit save.  Or there could be an autosave, but you're back to pros and cons, as is the case in every single path.

    The problem is the original design.  I provided a few ideas on how to handle this situation during run-time with little impact to the user.  Or you can throw the engineer switch. Whatever's clever

    Wednesday, December 30, 2015 8:32 PM
  • User1300871232 posted

    One more thing that I let out - it should be noted that we're using active directory to pass through the database. 

    The user doesn't actually 'log in.'  The user logs into windows and then is  automatically allowed in the application.  Because of that, the user also does not log out.

    Since we're not updating sessions but destroying them, the task is easier.   I looked up these commands:

    Session.RemoveAll();
    Session.Clear();
    Session.Abandon();

    https://msdn.microsoft.com/en-us/library/system.web.sessionstate.httpsessionstate.removeall%28v=vs.110%29.aspx

    From Microsoft's vague explanation, it seems like 'all keys and values from the session-state collection' means indiscriminately killing every session - not just the user who clicks it. 

    For our objectives, it's not really necessary to update sessions. It is equally acceptable to destroy them and then create another one - when the user enters from the front page. The point is that when the user goes into the front page, ideally the session data would be cleared - but only for that user.


    When you go to internet explorer and clear all the history and settings, you clear everything, both sessions and your cache. Observing that this made the application work, I conflated sessions with caches. I am persuaded by the arguments that the problem is likely the session, not caching.


    We are and always were considering ideas like yours (hitting the database more frequently to prevent mismatches) but that has its cons as well.

    Wednesday, December 30, 2015 9:25 PM
  • User1300871232 posted

    Just to update everyone, I think I figured out the issue.  Thank you for suggesting that it was sessions and not the cache.  By clearing all internet explorer settings and seeing it work, I conflated it.

    The sessions has a 'memberid' in the database but if you change that 'memberid' the session can still outlive the database.  So dbasarab/ebsoftware in the database has a member id of 'xxx' but still maintains a server session id of 'yyy.'

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, December 30, 2015 10:02 PM