My Logon ID

S

samsmithnz

Senior Contributor
Joined
Jul 22, 2003
Messages
1,038
Location
Boston
I have an ASP.NET application where I login a 3rd party application, (its really just a layer between the UI and the DB) and that returns me a logon 'token', an encrypted string that I use for the rest of the 'session' for the user to use other features in the 3rd part application.

In the past in ASP land we would probably have thrown this string in a session variable, so that after a certain amount of time the variable expires and the user has to logon again.

But I've always been told to not use Session variables, (not scalable or something ?), so I was wondering what my options were in ASP.NET land!?

Remember that we have several pages and we want to know the token for all of them...

Comments??
 
When I use to work for e-commerce shops, sessions were bad, even if we were froogle with what we used it for. Now that I work more on intranet web apps, and I know ppl are using cookies and the number of expected users, sessions are good. So it depends on your restrictions. If its just a string that is stored, why not just use a cookie. That or use a session state server like a db or a separate windows service.
 
A cookie is no good, as multiple people may use the same computer over a period of a couple of hours. When the browser closes I don't need to remember the logon token.

Tell me more about this session state server...?
 
You can set the cookie to expire once the browser closes.

in the web.config, you can specify to use a state server, which can be a db for example. you run installsqlstate.sql from the .net framework, this generates some tables and som SPs. then when the web server issues a asp.net session id cookie to the client, this is a pointer to the db record. this way, if you set something to a session variable, the web server only retains this pointer id, the actual data is in the db. i believe only serializable objects can be put into the db. this is good becuase its independant of other processes. However, if I were just going to store a single string in a session, then i would just use a cookie considering the client will need to be able to accept cookies anyways for session variables to work.
 
No this is over kill. What about Session Cookies then? I've just been reading about them, and they aren't really 'cookies' at all, (as they don't write to files, just to memory).

These seem to be a bit more like the session states, except only strings (which is all I need)...
 
Session variables are stored in memory on the webserver. In order to point the right session to the right client, the server issues a cookie to the browser. So, i was saying that if you just needed to store a string, and are worreid about session variables not being scalable for your purposes, why not just use a cookie for this. Becuase either way, the client's browser needs to be able to accpet cookies to begin with with session variables.
 
Or configure your site to use Cookieless state management and stuff your values in the url, but if you do, then you cant go back to using cookies, pretty much a pain in my opinion.
 
You could also use the viewstate, so when the user is done and closes the browser, the information is gone...
 
Back
Top