Member Avatar for pyari_priya1981

Hi all,

I am facing problem in session variables. We are a Call Center and we have a CRM application in ASP.Net which has two interfaces, one is for tech executive level another is for auditor. When a auditor opens both simulatanously.Sometime Session variables clashes for both interfaces and forms submitted by auditor has userid of tech executive , which she has opened just to check some information on tech executive level.

so how to resolve this problem and stop the wrong userid to be filled in audited data.

Thanks

Priya

  • 4 Contributors
  • 4 Replies
  • 194 Views
  • 3 Weeks Discussion Span
  • Latest Post Latest Post by kedar_challa

Dani AI

Generated

This is most likely a cookie / session collision rather than a mysterious IIS bug. ASP.NET ties a browser instance to a single session (default cookie name ASP.NET_SessionId) and Forms Authentication issues a separate auth cookie (default .ASPXAUTH). When an auditor opens two accounts in the same browser (tabs or windows that share cookies) both contexts send the same cookies, so the same Session object and auth ticket are used and the last login can overwrite session keys — which explains ABC/XYZ getting mixed up. See Microsoft’s session and forms-auth docs: Securing Session State and FormsAuthenticationConfiguration. (learn.microsoft.com)

Renaming the key (Session["username"] → Session["Auditor_username"], as suggested) helps only if sessions are actually separate; it won’t stop two tabs that share the same session cookie from clobbering each other. ’s point that IIS creates separate sessions is correct in the sense that sessions are isolated per browser session (cookie) — not per arbitrary logical login. To truly isolate auditor state, run the auditor UI under a different application/path or change the session/auth cookie settings so the two interfaces do not share the same cookie space. The session cookie name can be changed and the auth cookie can be renamed/scoped in web.config. (learn.microsoft.com)

Quick practical options:

  • Fast workaround: open the second account in a different browser or an incognito/private window (separate cookie store).
  • Proper fix: split the auditor UI into a separate app or virtual directory and give it distinct cookie names or cookie paths (or different app scope).
  • Best practice: avoid relying on a single server Session to represent multiple simultaneous actors — use the authentication principal (User.Identity), or include a per-window token (GUID) in the form so each submission explicitly carries the intended actor. Avoid cookieless sessions unless aware of the URL-leak risks. See cookie/session guidance and best practices. (learn.microsoft.com)

Repro and debug checklist (no UI change required): reproduce with two tabs, then log at submit the values of Session.SessionID, User.Identity.Name, Request.Cookies["ASP.NET_SessionId"] and Request.Cookies[".ASPXAUTH"]. If the session ID and auth cookie value are identical across the tabs, the server is seeing a single session and that confirms cookie sharing. Example config snippet (isolate names/paths):

<system.web>
  <sessionState cookieless="UseCookies" cookieName="AuditSessionId" />
  <authentication mode="Forms">
    <forms name=".AUDITAUTH" path="/audit" loginUrl="~/AuditLogin.aspx" />
  </authentication>
</system.web>

Applying one of the isolation options above eliminates the observed username clashes.

Recommended Answers

All 4 Replies

Member Avatar for Letscode

What you are saying is when a tech executive signs in and logs out, her session is not expiring.
If the user has a page opened then the session will not expire unless you logout.
When the page closes then the session state variable will automatically expire.

Even if the session did not expire like what your saying,your session variable should be replaced by the existing value for the input user.Check whether your user input gets replaced in the session variable.

What kind of Authen mode are you using?

What Browser are you using?

Member Avatar for pyari_priya1981

No I don't mean so. When an auditor audits the calls, he also logins into the CRM to check for tickets against the audited calls. He uses different username for operating CRM, other than which he is using to give remraks to audit the calls. So When on a single client , 2 different username , passwords are used , and both usernames are kept in Session Variables. They clash sometime , and form submitted by auditor
stores the username not of auditor but of other username which he is using just to check tickets.

For example : username for Auditor is ABC and username for dummy tech exective (to check tickets only) is XYZ.
And username to be stored by auditing application should be ABC but sometime it stores XYZ , which was the dummy tech exective username.

I want to know What is the reason behind this, and what is the solution.

Thanks

Manjeet

Member Avatar for campkev

Hard to say without seeing code. Do you use the same name for the session variable for both? Maybe change the name of the auditor session variable, eg: Session["username"] and Session["Auditor_username"]

Member Avatar for kedar_challa

Hard to say without seeing code. Do you use the same name for the session variable for both? Maybe change the name of the auditor session variable, eg: Session["username"] and Session["Auditor_username"]

Hi,

I don't think it's problem with Session variables. Anyway IIS will create two seperate sessions for each user and they are iscolated. Priya, Could you please let me know more technically about what you implemented.

Thanks,
Kedar

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.