| Adam Would Just Like To Know: How can I set a cookie to expire in 15 minutes? I know to use Response.Cookies(cookiename).Expires = Now() + ????????? Decius Innocently Replies: Have you considered using session variables? Session variables' default is 20 minutes.
However you can change this to 15 minutes.
Rob Shouts: session variables are the devil's spawn!
Anders Agrees: If session variables makes your world go round, by all means use them, but I
agree they should be used with care. However, I don't see why one always
would want to do an extremely hardcore workaround in order to get the same
flexibility as session variables offer - that is, use a guid or something to
represent user-state on the server. Would you store everything in a querystring? and then transfer that
querystring from page to page? Really cumbersome, if you have access to
session variables!
Rob Preaches: Personally I would only limit myself to the session object nightmare when 1. cookies don't matter
2. deployed for a very limited environment, and scalability is not a concern (Intranet) Once you've done it, and you did it well enough, it's very simple just to
plop your object in & setup a couple of tables to enable fully scalable
and flexible session support.
Nick Asks: Am I right in saying that session variables are bound to a browser, i.e. One
browser can't read the session variables of another!? How is this binding implemented automatically by IIS? It uses cookies, right?
What if the user has cookies turned off then how does it cope with that?
Rob Professes: Session variables are bound to one server. They are sitting in the
server's memory that created it. That is the main reason why they inhibit
scalability. In a truly scalable solution, each request is routed to
the first available server, regardless of its previous usage of the web
farm. But there are solutions (LocalDirector) which will route each user's
concurrent requests to the same machine, which it hits on the first time,
thus you will be able to use session variables and they will persist. But,
LocalDirector and other packages are very expensive, Session variables can
consume large amounts of memory (depending on the usage of course), and
you will be basically implementing a half-assed solution...It could be very
possible that the load balancing software could route incoming request to
the same machine, over time (statistically possible), which means
improperly allocated resources. And also, one major thing with the choice
to move to a load balanced environment is to have no single point of
failure (i.e., being able to unplug one machine, and have things still run
normally). Well give the above situation, unplugging one machine would
cause tremendous session losses for your users. (basically just plain out
pissing them off) -kiss that $10,000 sale good bye, not to mention the
negative word of mouth advertising you would get. Secondly...Session variable are maintained by a non-persistent cookie. I
know that in IE, if you hit Control-N, these non-persistent cookies will
carry forth to the new browser. But if you double click the IE icon on
your desktop, and start a whole new IE, these cookies will not be in the
new browser. Cookies need to be enabled. Session state will not be maintained using the
session object if the user has chosen to turn of cookie support. So
basically you're automatically excluding every American government
employee. (didn't the American Gov. set a standard that they cannot use or
accept cookies? I think they did...?!!)
Nick Continues the Inquiry: So unless the web system is to be used in a specific, dictable environment
it's best not to use cookies and have the session ID being passes around in
the URLs or as hidden form field. Then have the variables come from data!?
Rob Answers: Yes..basically..you persist the user by a UUID (unique user id). This is
passed around all over the place (of if you want, use cookies..your call)...
and then that relates back to the database, which hold the user's information. You, of course, would need to set it up for anonymous users, registered
users, etc... It takes a bit of time, initially, to setup the environment and create a
basic COM object that will handle the logging in, etc... but once you've
did it once, the rest is nothing. I think it took me about 3 hours to do
it from start to finish. Check these links: http://www.aspalliance.com/nothingmn or http://www.aspfree.com/authors/robert both have some *older* articles on this there...review them... I will be updating them this weekend, with most likely full source which you all can "borrow".... also: http://www.aspfree.com/authors/robert/faq.asp?id=1 and http://www.aspfree.com/devlinks
Category: State/Session Management might prove useful This conversation string was taken from the 15Seconds ASP Listserv on 3/6/01. If you have an ASP-related question or would like to share some of your knowledge with others, you may join the list by clicking here
|
