Session State

[stumac]

Hi Guys,

Got an odd one here, well it's beyond me anyway. I'm relatively experienced in .NET development (VB flavour) but don't profess to know everything and learn something new every day!!

The problem - I've got a Session State being shared across users and I'm stumped.
I've been in touch with Tech Support who can replicate the problem but say that the Server cannot be causing the issue hence my post here.
So let me elaborate on how the problem manifests itself...........

1) User1 logs onto there account. The aspx login page posts back to itself and checks the validity of the login details. It does this by calling a data access class which does all the nitty gritty in calling the stored procedure. The upshot of the database confirming the details is that the class file sets the returned id into a Session variable, returns nothing to the calling aspx page which upon checking for a return message, finding none it does a Server.Transfer to the account page. The account page shows the correct summary details for his magazine.

BTW................web.config file has sessionstate with attributes mode=inproc and timeout=60

2) User 2 logs into there account in the same manner, obviously using a different login. He is again taken to his account summary page where his magazine details are shown correctly. So everything working as expected!!

HOWEVER.

3) User1 clicks on a sub heading which simply takes him to another view within the same page. In the code behind, the link calls the data access class, passing it 1 value, the magazine id taken from the Session variable we set during the logon procedure. This value is duly passed as a parameter to a Stored Procedure to retrieve the data for that view which is passed back as a sqldatareader. When the page loads, the magazine details shown are those for user2 instead of for user1. So somehow the magazine id passed is the last one to logon. If I was to logon to a 3rd magazine then it is this magazine id which is passed under all instances from the Session variable.

Completely and utterly confused.
It's probably something simple which I'm not understanding (I hope!). I don't mind being made to look stupid so long as I can learn something from it!

I've haven't included any code snippets yet as I'd rather provide specific code from requests rather than saturate you all with everything.

Your help is appreciated.

Regards,

Stuart.

[wisemx]

Hi,
This sort of thing has been driving developers nuts since ASP first arrived. http://community.discountasp.net/emoticons/tongue.gif
These two links should help a bit:
http://msdn.microsoft.com/en-us/magazine/cc163708.aspx
http://msdn.microsoft.com/en-us/library/system.web.sessionstate.httpsessionstate.remove.as px

Salute,
Mark

[stumac]

Hi Mark,


Thanks for the quick reply and links.


From the first link, the relevant part seems to be stating that whenever a new window is opened from an existing webpage, it inherits the Session state and cookies. That makes sense.


But does this extend to my problem? Or am I missing the point completely?


I have my account page for user1 displayed. Now when users2 logs on to a completely different account, he also gets his account displayed correctly. It's just when user1 clicks on a link within his account, he gets user2's details.


He's not opening up a new window at all. I've tried this in IE7, both in opening up a new tab and also in opening up a completely different browser application and the resut is the same. It even happens across physical sites as my business partner logged on after me yesterday and I got his account details after clicking on a link in my account.


Some further info.


I changed the web.config to add cookieless=true to the sessionstate tag and lo and behold, the problem has disappeared. But of course the session id is displayed in the url. Now I don't hold critical information in the session object, just common page elements like account name, date registered, etc so shouldn't be a problem wrt session hijacking.


BUT..............this shouldn't be happening. A session is set up per browser instance..........isn't it? So each user in his/her own browser on my website should have a unique session id shouldn't they?


Or am I still in the dark about this session thing?


What's equally confusing is that I have built this flavour of website before for a previous client and it worked perfectly, all be it on a different host. Session = server in my mind so is it a server thing, although tech support have reassured me it isn't?


I'm going to start stripping out my code today to see if I can see if there is any offending code causing a problem but to be honest, it only started happening yesterday after working OK on Monday. And yesterdays coding was primarily located around the look of the website so I can't see anything I've changed would have screwed things up............but who knows!!


I would still value anybodies insight into this!!


Cheers,


Stuart

[wisemx]

Hi,
I think you're on the right track and I'm not going to kid you that any answer will solve this for you easily.
Some things to check for are indeed sessions kept in cookies, but also viewstate and the current application pool.
For example, the root of your site is an application, but folders from the root are not unless you create an application.
Doing this can solve session state problems in both ASP.NET and Classic ASP.
Can, not will. It's just one more thing for you to try. http://community.discountasp.net/emoticons/wink.gif

Lookie: http://www.dotnetfunda.com/articles/article61.aspx
http://aspnetresources.com/blog/page_state_persisters_overview.aspx


Post Edited (wisemx) : 6/25/2008 10:21:23 AM GMT

[DotNetNutter]

Hi,

Are you writing out the session value somewhere on the page to check that it is being set properly?
If it is then you can move on to checking why the correct data is not being pulled out.

You can also try storing the session value in an hidden filed and then using that field.value to get your content [only for non secure items though] ~ might be worth a try.

Cheers,

J

[wisemx]

Here's a great article that just got published a few hours ago:
http://blogs.msdn.com/oanapl/archive/2008/06/27/server-transfer-response-redirect.aspx




MSDN said...


Server.Transfer / Response.Redirect


Server.Transfer and Response.Redirect are causing a new page to be processed, but the big difference is how they are doing it.
- Server.Transfer terminates the execution of the current request (Response.End) and begins execution of a new request using the supplied url. No trip back to client is performed.
- Respose.Redirect creates a special header, sends it to the client to ask the server for a different page.
o Response.Redirect(url) == Response.Redirect(url, true). In this case, right after creating the header, the page execution is done ? Response.End is called, and this one causes the current thread to be aborted (ThreadAbortException will be thrown).
o Response.Redirect(url, false) doesn?t abort the thread, so it is recommended because it avoids the exceptions. This form is used for example by FormsAuthentication.RedirectFromLoginPage method.
Therefore, if we are changing Session items and then call Response.Redirect(url) or Response.Redirect(url, false), the session items are not saved, so they will not be there when url is executing (see this post (http://blogs.msdn.com/oanapl/archive/2008/06/21/argumentexception-when-adding-objects-in-session-item-has-already-been-added-to-the-dictionary.aspx) for a brief explanation on how session works). Eg., when we want to log in a user, the following code won?t work:
Session["UserName"] =username;</o:p>
Response.Redirect("~/default.aspx");</o:p>
Response.Redirect(url, true) works, because we are not calling Response.End and session is saved.
What about Server.Transfer? Because the transfer happens without a trip back to the client (compared to Response.Redirect, it saves one client/server round trip), the page collections of the first page are simply used by the second. The drawback is that the user seems the same URL as for the first page and is unaware of the change. Relative links / image paths may not work if the new page is a different directory.
In my previous post (http://blogs.msdn.com/oanapl/archive/2008/06/21/argumentexception-when-adding-objects-in-session-item-has-already-been-added-to-the-dictionary.aspx), I talked about a session race condition when calling Server.Transfer between pages with different session modes. The problem wouldn?t have been seen if Response.Redirect would have been used instead. Of course, Response.Redirect might not suit other requirements that application had.

[stumac]

Thanks guys for all your time on this. I've been away on other issues.
I changed the sessionstate to be cookieless and that seems to have fixed the problem. It just looks a mess in the URL and at the moment I'm not sure of any other implications it may have. Session hijacking? I need to research this to ensure that this is an option. But deep down, I know next week that I'll go back to using cookie sessionstate and try and work it through. Just a bit war weary just now.
A bit of return knowledge as a thank-you for your help which you may or may not know.
I had a scheduled task set up to clean up any logins hanging around. This worked fine until I changed the sessionstate to cookieless. After contacting support, it turns out that a scheduled task can only call a file directly, i.e. in the scheduled task you set the file to be "www.awebpage.com/xyz.aspx (http://www.awebpage.com/xyz.aspx)". In a cookieless sessionstate, you get a pseudo page redirect as your file xyz.aspx gets appended with the session id and becomes for example "www.awebpage.com/(S(fjksgfgfjsafgjagfajf))/xyz.aspx. Scheduled tasks can't handle this and so doesn't run. No error message is posted either so it's an invisible failure.
Back to the main problem. I'll keep this ticket updated when I tackle the issue next week.

Cheers,

Stuart