0

I've an ASP.NET web site that uses FormsAuthentication and a standard Session mechanism. In one of it's webpage the processing(on click of refresh button grid rebinds) is base on session value.If i leaves the screen open for a 'long time' and then tries the refresh. Nothing refreshes.It because session value expires.

So is there any way, i can set configure setting in web.config and synchronize both authentication cookie timeout and session timeout ?

Milan Mendpara
  • 3,091
  • 4
  • 40
  • 60

2 Answers2

0

In web.config, set the timeout value of the sessionState element, and the same value in the authentication element.

Alexander
  • 2,457
  • 1
  • 14
  • 17
  • This doesn't sync both. You're merely saying they have x time before each expires and/or are sliding. You can't assume that a login occurs on each session start (however the developer defines it). You can start both at the same time (login and set session vars), but that's not a "setting", it's an attempt to do so. – EdSF Jun 05 '13 at 12:04
  • Sorry, I assumed (but forgot to write) that the values automatically get synched by setting sliding expiration? – Alexander Jun 05 '13 at 12:16
0

First, see this SO thread for your answer.

You can attempt to "synch" - perhaps by logging in and setting session vars in the same method, but that's not really a "setting"....

What follows is just my take/opinion that expands on that answer.

IMHO, I think you need to rethink what each type of "storage" is for. Forms Authentication is exactly for that purpose - authentication to some "content" or "resource" that you deem needs to be protected.

Session is more for exactly that - e.g. because some data/resource is "volatile" (changes within x time) - the usual example for this is if you have an ecommerce site, you have to track inventory changes for availability of a product (inventory changes because of purchases/returns made by users, while other users are browsing/shopping). That or the simpler process of users adding items to a cart (sessions and/or cookies, aka "persistence").

Its important to know that on the client (browser), cookies are the primary mechanism for sessions (or url for cookie-less sessions).

So depending on what content/resource it is you are referring to, change the process depending on which of the 2 types they fall under.

  • if it's a protected resource then display/access should be controlled by your auth scheme
  • if it's volatile/changing content/persistence needs, then sessions or just cookies might fit the bill (or newer client side storage)
  • if it's both (protected and volatile) then, auth first and then whatever mechanism fits the bill for volatile/persisted content.

Hth....

Community
  • 1
  • 1
EdSF
  • 11,753
  • 6
  • 42
  • 83