CODEWITHSUNDEEP
c#asp.netamazon-web-servicesiis
JamesYo
JamesYo

Reputation: 11

Session lost after redirect page

To describe the app, it has an default page where it will be checking user role from request header then assign the user id into session and redirect to corresponding pages. In every other pages, it will check whether the session has value or not, if no then will redirect the default page.

This has been tested in my dev environment and its working without any issue. However, when I hosted it in IIS (AWS EC2 environment). It started behaving very weird. If the application's bindings is stick to default. I can browse it in the server using http://localhost:26943/ with no issue.

default bindings

However, when i change the bindings to hostname and browse using http://testing.com/, I found that the session containing user ID is empty.

hostname bindings

I have tried several methods including :

  1. Add Session["init"] = 0 in Global.asax
  2. Change cookieless=true in web.config
  3. Change sessionState's mode to "StateServer"
  4. Redirect to "~/page.aspx" instead of "page.aspx"

Only change cookieless method worked for me but it will show session ID in the URL which I doubt is the correct method.

Details of app:

Upvotes: 1

Views: 5897

Answers (2)

Purvesh Sangani
Purvesh Sangani

Reputation: 305

HttpContext.Current.Session["myvariable"]

Upvotes: -2

Albert D. Kallal
Albert D. Kallal

Reputation: 49039

Since AWS is on a server farm? Then in-proc sessions are going to be VERY flakey and problematic. Those massive cloud systems will spool out your web server multiple times - a WILD guess as to where the next page will come from. If pages are served across different instances of the IIS server?

You going to lose session values. As noted, even some un-handled code errors will cause a app-pool re-set. All of these issues add up to easy and frequent loss of sessions.

I would suggest you adopt SQL server based session management. This should eliminate a zillion issues that can cause a session() re-set. I like in- proc. Memory based is fast, and since your not writing the next Facebook, then of course typical server loads are next to nothing (again, this favors use of in-proc sessions). However, since you a have server farm, and some application errors will become problematic? Adopt SQL server based sessions, and 99 if not 100% of your session() re-sets and loss will go away.

this suggestion is MUCH more warranted since you using AWS and you have little control over the VM's they run and their behind the scenes "fabric" controller could for fail safe and redundancy issues be running multiple copies of your server. So, adopt SQL based session management.

Upvotes: 0

Related Questions