If you face with the problem that ASP.Net SessionID is changed for each request, then after googling for solution, the most frequent will be suggestion to store something to the session: when session is empty ASP.Net generates new SessionID for each request by design and it confuses many developers. But what to do if you tried it and it didn’t help?
We encountered with this problem on the computer of one user. For this customer there was site on Sharepoint 2010 and have 2 environments: QA and production. The problem was reproduced only on QA, but since it was very critical to have working QA on this project, it was necessary to fix it. Problem was reproduced both on IE and FF and only from user’s computer, i.e. it wasn’t reproducible when we tried to open site in RDP session directly.
First of all I created simple application layouts page in order to check that problem still here for non-empty session:
1: <%@ Page Language="C#" %>
2: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
3: "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
4:
5: <html xmlns="http://www.w3.org/1999/xhtml">
6: <head runat="server">
7: <title></title>
8: </head>
9: <body>
10: <form id="form1" runat="server">
11: <%1:2: HttpContext.Current.Session["foo"] = "bar";3: this.lbl.Text = HttpContext.Current.Session.SessionID;%>
12: <asp:Label ID="lbl" runat="server" />
13: </form>
14: </body>
15: </html>
It showed the same session id for me, but different for the user on each request. It forced me think that the problem is in client’s browsers configuration. The fact that on production environment everything works helped, because I could compare configurations on client and server side for both environments. I checked that there were no significant changes in web.configs on both environments. Also both QA and production URLs (https was used for them) were added to the trusted site and configurations of proxy were the same.
Solution was found quite unexpectedly: we removed QA URL from trusted site and session id stopped changing on each request. This was the first time in my practice when removing site from trusted site fixed the problem. It may be some customer-specific environment problem of course, but if you will try all possible solutions and they won’t work, there will be one more thing to try.
No comments:
Post a Comment