I have been asked to work of a very large web application and deploy it. The problem that I'm facing here is that when I deploy the application and more that 1 user logs into the system, the sessions seem to cross over i.e:
Person A logs in and works on the site, all good. When person B logs in, person A will then be logged in as person B as well.
I have been asked to work of a very large web application and deploy it. The problem that I'm facing here is that when I deploy the application and more that 1 user logs into the system, the sessions seem to cross over i.e:
Person A logs in and works on the site, all good. When person B logs in, person A will then be logged in as person B as well.
If anyone has experienced this behaviour before and can steer me in the right direction, that would be first prize, Second prize would be to show me how I can debug this situation so that I can find out where the problem is and fix it.
Some information about the application. From what I've been told and what I've seen within the app is that it started as a .Net 1.1 application and got upgraded to .Net 2 and that's why the log in system was done the way it is. (The application is huge and now complete and that's why I cant rewrite the whole user authentication process, it will just take to long and I don't know what effect it might have)
All the Logged in User information is stored in properties that have been added in the Global.asax.vb file. (could this be the problem?)
Any help here would be greatly appreciated
Sessions on the server doesn't cross over, so the actual reason has to be that there isn't actually two separate users, or that the information isn't actually stored in separate sessions.
Browser sessions
When you open a new browser window from another window in Internet Explorer, they are in the same browser instance, and thus still the same user. There is no way for the server to distinguish between the windows based on the session id, as they share the cookies and send the same id. You have to start a new instance to log in as a separate user.
In Firefox there is ever only one instance. Even if you try to start another instance, it will just open a window in the existing instance. Thus, you can not log in as separate users in separate windows.
Session objects
To store information in the user's session, you actually have to store it in the Session object. If you create properties in the GLobal object in global.asax, they are shared by all users. Even if you are in a method like Session_Start, the user doesn't have a separate instance of the Global object.
We had a similar situation in our code done by a vendor. In our case the probplem was due the use of global static variables assigned from session.
I don't suppose by any chance that when the user's identity is read from the session it's being stored in a static field rather than an instance field in a base class is it? And then being written back to the session from there? I've come across this before.
Related
I have a web application (.net VB code) that utilizes session variables to store the username (here login name) and the profile (admin/client), authentication is handeled by asp membership. The application then relies on these session variables on the load events. This application has been running fine for a couple of years. However, recently users complain about occasional error messages after logging in and attempting to load a new page that needs one of these variables. It happens most frequently Chrome, but also IE and Firefox.
Users that experience the error need to log out and clear the browsing history, after that it works again. The error is not easy to replicate - I was able to trigger it on my machine 'violently' using the 'back' button a couple of times that eventually tripped it - then I had to clear my browsing history to get the application to work again.
What might cause this to happen?
the session gets set on the load event of the 'login' page with 'Session("Type") = "Admin"' and subsequent pages check for the value of Session "Type"
I understand that I could use a cookie instead, but I chose not to for security reasons. Could this be prevented using a cookie instead? or do I need to use the membership.getuser method to get the username and then look up the values in the database? That does not seem efficient.
Ideas?
FYI, the ASP.NET Session ID is stored in a cookie that travels back and forth with each request/response. The actual session state values for a given session are not stored in cookies ... they are stored on the server only. They could be stored in memory, or in a SQL database, depending on how you've configured ASP.NET Session State.
But Session State can get destroyed for a variety of reasons. IIS might suddenly decide to restart your Application Pool, for example, in which case all your Session State would be gone.
Basically, you need to write your web app to always handle the possibility that Session State may be empty. If it is empty, then you probably need to redirect the user to the login screen to enter his credentials again.
Clearing the browsing history should have no effect, so I can't explain why that would help get past the problem.
We have a web application through which customers access information. It has been reported by many customers that they are logged out within 5 minutes of no activity. I believe this should only occur after the default 20 minute idle timeout, and this is the case when accessing the web app from inside our domain.
I also spent a few days troubleshooting an error in which some of the user's session data was lost between post backs about 60% of the time, causing an application error since the next page needed the data. The only resolution was a work-around in which I use an additional mechanism for caching the data between postbacks and pull the data from that cache if the session data is gone.
I have also noted that some websites that I visit which require logon credentials will also kick me out between postbacks. For example, a website for a school I take classes at requires logon credentials to their portal. At home I never have any issue, but if I access it from my work domain I often get random errors indicating that my credentials have been lost (i.e. "Unauthorized access is not permitted" after logging in and browsing to a page).
Combing the web for ideas has led me down a few paths, but most address the IIS worker process and ASP.NET and have not helped me.
Does anyone have any ideas or suggestions about how to resolve this?
this is not because of the programming problem...this is because of your host capacity...as you know session are a type of memory that is create for each user when they access to your website and it's terminated when they finish visiting...so in this case I suppose the number of site visitors has risen up,so by default when the memory become full, it kicks one session out and causes all these problems...I think the best thing to do is calling where you get your host services and ask for a service that cover sites needs
You just store your session value in to cookie so you can access that value when session terminate.. or you can use global file to manage session state..
I have the oddest situation...
On my ASP.NET website when the application pool recycles the user is logged out. This is fine. I know this is suppose to happen. But when the user logs back in and selects any link within the website, they are logged back out immediately. They consistently get logged out. I don't know what causes this and I don't know how to fix it.
The odd part is the work-around. If I log in from a different computer or from the IIS Server itself than the user that is getting logged out can log back in.
Does anyone have any ideas as to what is happening?
Standard Forms Authentication in ASP.NET is cookie-based and should not be affected by the session vanishing. But, you're probably relying on something in the session to determine whether or not the user is logged in. If you're using in-process session storage (and it sounds like you are), then your application code might act strangely if you get in a state where the Forms Authentication cookie still exists and is valid but the session information is missing. Instead of going to a different computer, try blowing away your cookies and logging in again, and I would presume that your issue is resolved.
One step is to move to out-of-process session storage (such as the ASP.NET State Server, which is simple to use with a few config changes) or to eliminate session usage entirely (by depending on values stored in cookies, though there are security implications there to consider if these values are not encrypted). Then, take a close look at how your application code handles the condition where a login cookie is set but the session data is invalid.
It's a shot in the dark based on the information provided, but hopefully it puts you or someone else on the right track.
I discovered the problem. In the Security settings of the ASP.NET Configuration each user that logs in needed to have one of the roles defined in the "Description" field. This is very odd to me be but it seemed to do the trick. Anyone know why this needs to be done?
I'm seeing multiple users logging in to my .NET 3.5 web application and sharing the same session ID. This appears to be happening most often when users are on different computers on the same network, but it appears to be happening between users on different networks as well. My users are logging in within a minute of each other and getting the same session ID. Consequently, user B is seeing user A's data.
We are using multiple worker processes on the Server 2003 R2 box. Session AND viewstate are stored in SQL Server. Session is set up to use cookies, not URL, to store the ID.
This question is similar to these questions, but neither matches my scenario:
This one turned out to be a false report
This one used IIS7 <--It particularly looks like this one, but I'm on IIS 6, which does NOT use dynamic output caching, right?
Why is my application assigning the same session ID to different machines? How can I stop it from happening?
Edit: I am highly skeptical that session is the culprit, but I am being outweighed by my colleagues. It is more likely that there is a code problem, but I can't explain why the session IDs that we are logging are identical. Yes, there could be a problem with the logging code, but that wouldn't explain why user B is getting user A's stored session data.
Do you have any code that is static (shared in vb.net). This could cause the problem. Also, Session is not truly initialized until something is actually stored in session.
I'm porting an ASP.NET application to MVC and need to store two items relating to an authenitcated user: a list of roles and a list of visible item IDs, to determine what the user can or cannot see.
We've used WSE with a web service in the past and this made things unbelievably complex and impossible to debug properly. Now we're ditching the web service I was looking foward to drastically simplifying the solution simply to store these things in the session. A colleague suggested using the roles and membership providers but on looking into this I've found a number of problems:
a) It suffers from similar but different problems to WSE in that it has to be used in a very constrained way maing it tricky even to write tests;
b) The only caching option for the RolesProvider is based on cookies which we've rejected on security grounds;
c) It introduces no end of complications and extra unwanted baggage;
All we want to do, in a nutshell, is store two string variables in a user's session or something equivalent in a secure way and refer to them when we need to. What seems to be a ten minute job has so far taken several days of investigation and to compound the problem we have now discovered that session IDs can apparently be faked, see
http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/
I'm left thinking there is no easy way to do this very simple job, but I find that impossible to believe.
Could anyone:
a) provide simple information on how to make ASP.NET MVC sessions secure as I always believed they were?
b) suggest another simple way to store these two string variables for a logged in user's roles etc. without having to replace one complex nightmare with another as described above?
Thank you.
Storing the user's role information in a server-side session is safe providing a session cannot be hijacked. Restating this more broadly, it does not matter where user role info is stored if an authenticated session is hijacked.
I advise not putting too much faith in the article you linked to, but the 2002 vintage report linked to from your link is of interest. Here are my take-aways:
Don't accept session IDs embedded in URLs.
Focus your time on eliminating cross site scripting dangers i.e. scan all user supplied data and parse out executable java script.
Issue cookies for complete domains (e.g. myapp.mydomain.com)
Host your domain at a high class DNS operator e.g. one that only allows DNS changes from a preset remote IP address.
Don't issue persistent session cookies.
Reissue a session cookie if someone arrives at a login page with a sessionID already associated with an authenticated session.
Better still, always issue a new session cookie on successful authentication and abandon the prior session. (Can this be configured in IIS?)
The only way to make a secure cinnection is to use SSL. Anything less than that, and you simply have to make the evaluation when it's "safe enough".
A session variable works fine for storing a value, with the exception that the web server may be recycled now and then, which will cause the session to be lost. When that happens you would have to re-authenticate the user and set the session variable again.
The session variable itself is completely safe in the sense that it never leaves the server unless you specifically copy it to a response.
Have you considered setting up a custom Authorize tag in MVC. I gave an example of this in another question.
On initial authorization (sign-in screen or session start) you could seed a session value with the IP address also. Then in your custom authorization, you could also verify that IP's still match up as well. This will help make sure that someone isn't 'stealing' the person's session. Everytime you access your session data just make sure to pass the requester's IP and have some check on it.
Are you trying to control the access to functions at the client level? That is the only reason I would expose the roles and items to control client side functions.
Alternatively, you could create a function to obtain the items that the roles of the user are allowed to use, and then even if the function is called outside of the items given back to the web application, you can prevent the user from accessing them.
4Guys seems to show how to control functions with the roles.
The approach I have used in the past is to use symmetric encryption of a cookie alongside SSL. Encrypt the user information in the reponse and decrypt it in the request. I'm not claiming this is foolproof or 100% secure and I wouldn't want to do this on a banking application, but it is good enough for many purposes.
The main issue with session variables is that if you store them inProc rather than persisting them, then you need to apply 'sticky' sessions to your load balancing in a web farm environment. Guffa is correct that without this persistence session variables will occasionally be lost causing a poor user experience.
Sticky sessions can lead to uneven load balancing, perhaps reducing the value of being able to scale out.
If you are going to be be persisting the sessions so they can be accessed by all servers in your web farm, you may be better off using a Guid to identify the user, encrypting this in a cookie and retrieving the user record from your data store each time.
My obvious question is that why do you want to store a users role in session ?
Here is my answer to your query, how this helps. I have attached a small demo application for you to take a look at and understand my points. When you open this project in visual studio, click on the project tab on the top and select asp.net configuration. From the page that will show up you can do the user administration stuff.
You need to store the roles of a user in some secure manner ? The answer to this question is that there is no need for you to worry about storing the role for any user, when we have the asp.net membership, profiles and roles framework to help us out on this. All you need to do is create a role in the aspnet database and assign that role to the user.
Next you want to store two string in some secure manner. I suggest you user profile for storing user specific information. This way you have the information available to you where ever you want from the profilecommon class.
Also please see the attached demo application placed at the end of my blog http://blogs.bootcampedu.com/blog/post/Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx
Just a suggestion, you might consider using this little library:
http://www.codeproject.com/KB/aspnet/Univar.aspx
It has a server side implementation of the cookie whereby all cookies can be stored on the server while asp.net authentification is used to identify the user. It supports encryption and is also very flexible making it very easy to switch from one storage type to another.