I have deployed two web applications on my IIS7.
The problem is, IIS is generating the same Session.SessionID if I request both application using the same browswer (different tabs).
This is causing some problem with ASP.Net user authentication, it is some how overlapping with each other and the flag "User.Identity.IsAuthenticated" returns false whenever the user logs in on to the other site. It works fine as long as user is working on one of the site.
Please help me out, I cant seem to find the reason for this, I mean the session is application specific so why is sessionID from one web app is conflicting with the other.
Thanks
They are running in the same application pool. Just separate the application pools.
Problem is your browser is treating these applications the same. Session in ASP.NET is implemented by the session cookie. These need to have different website names so that they do not share the same session.
UPDATE
This is how session cookie works.
But one solution is to access them as mysite.com/1 and mysite.com/2. That I believe should also work.
Did you checked application pools, if you want to isolate web application you should define different application pools.
Is each application running in a separate IIS Application? If they are, then the session will be separate, as Session is scoped to the AppDomain. If they are in the same IIS application, they are loaded in the same AppDomain, and will share Session.
In the same browser session (regardless of using tabs), the same Session cookie will be sent.
Related
I have a few ASP.NET sites running on one IIS server, of course using different ports. The sites allow for logging in via forms authentication. Session state is stored on a local state server. My problem is that when a user logs into one sites and then navigates to another, they get an exception from the second site and have to close/reopen their web browser to be able to access it. My guess is that the cookie from the first site is making it appear that they're logged in on the second one as well (though I could be completely wrong about this).
I've tried a few things to fix it (which are probably dumb and have nothing to do with the problem, but I'm far from an ASP.NET expert) including:
1) giving the sites different cookie names in Web.config's sessionState tag, and
2) Moving the sites to different app pools, but the problem persists. Any help would be appreciated.
I'd recommend setting up different domains for each site. If this is local, use the host file to route local.site1.com and local.site2.com to the correct place. Obviously you'll have to keep the port. Then you should be setting cookie with a different domain for each site and not causing the confusion.
I am running ASP.NET 4.0 website (not a web project) , which is frequently modifying. Pages updates smoothly ,but some key file ,like web.config or resource files updates causes web site restarting and throws users from site, make them log in again and lose their sessions.
What are the possible ways of solving the problem.Ideal scenario is to allow existed users to work with old version and newly logged to work with new one.
You could use a different session storage mode such as StateServer or SQLServer. Read more about the state modes http://msdn.microsoft.com/en-us/library/ms178586(v=vs.100).aspx. By default ASP.NET uses InProc session storage, which are lost whenever the application pool refreshes (such as when the web.config file is changed).
Here is another article on MSDN that walks you through how to set up SQLServer sessions: http://support.microsoft.com/kb/317604
I am trying to get a grasp on how to handle updates to a live, functioning ASP.NET (2.0 or greater) Application while there are users on the site.
For example, suppose SO is an ASP.NET Web Application project. The project code compiles down to the single .DLL in the BIN folder. Now, there are constantly users on SO, so what would happen to users' actions/sessions if you would use the Visual Studio .NET "Publish" feature (or just FTP everything again manually) while they are using the site?
Would creating an ASP.NET Web Site, instead, alleviate any problems that may or may not exist with the scenario above? I am beginning to develop a web site as a user-driven Web Application, and I want to make sure that my inexperience with this would not potentially annoy the [potentially] many users that I [want to] have 24/7.
EDIT: Sorry, I should have put this in a more exact context. Assume that this site is being hosted by a web hosting service with monthly fees. I won't be managing the server itself, just what the web host allows as a user of their services.
I create two Web sites in IIS. One is the production Web site, and the other is a static Web site with an HttpHandler that sends all requests to a single static "We're updating" HTML page served with an HTTP 503 Service Unavailable. Typically the update Web site is turned off. When it's time to update, we stop the production Web site, start the update Web site, and now we can fiddle with the production Web site all we want without worrying about DLLs being locked or worker processes needing to be spun down.
I started doing this because
App_Offline.htm really does not work well in Web Gardens, which we use.
App_Offline.htm serves its page as 404, which is bad if you're down for a meaningful period of time.
We can start the upgraded production Web site with modified settings (only listening on localhost), where we can do a last-minute acceptance/verification that everything is working before we flip the switch, turning off the update Web site and re-enabling the production Web site.
Things this does not solve include
Any maintenance that requires a restart of the server--you still have downtime where no page is served.
Any maintenance that diddles with the .NET runtime, like upgrading to the latest service pack.
Other approaches I've seen include
Having two servers. Send all load balancing requests to one server, upgrade the other one; then rinse and repeat. Most of us don't have this luxury.
Creating multiple bin directories, like bin-1.0.0.0 and bin-1.1.0.0 and telling ASP.NET which bin directory to use in the web.config file. (One advantage of this is that reverting to a previous binary is just editing a config file. A disadvantage is that it's harder to revert resources that don't end up in your binaries, like templates and images and such.) I don't remember how this actually worked--I think the application did some late assembly loading in its Global.asax based on its own web.config section (since you touched the web.config, the app had restarted, so it was okay).
If you find a better way, let me know!
Changing to the asp.net web site model won't have any effect, as the recycle will also happen, some of changes that trigger it for sure: web.config, global.asax, app_code.
After the recycle, user will still be logged in because asp.net will just validate the syntax. That is given you use a fixed machine key, otherwise it will change on each recycle. This is something you want to do anyway as other stuff can break if the key change across requests i.e. viewstate validation, embedded resources (decryption of the url fails).
If you can put the session out of process, like in sql server, you will avoid loosing the session. If you can't, your code will have to consider that. There are plenty of scenarios where you can avoid using session, and others were you can wrap it and re-retrieve the info if the session was cleaned. This should leave you with a handful specific cases that you know can give trouble to the users, so for those you do some of the suggestions others have already made.
One solution could be to deploy your application into a load balanced environment (web farm).
When deploying a new version you would use the load balancer to redirect requests to the server you are not deploying to.
App_offline.htm is great solution for this I think.
in SO we see application currently unavailable page when a deployment begins.
I am not sure how SO handles it.. But we usually put a holding page. So what ever the user has done (adding question or answering questions) does not get updated. As soon as he updates something he will see a holding page asking him to try after sometime.
And if I am the user I usually press the back button to make sure what I entered is saved in the browser history so that I can post later.
Some site use use are in clustered environment so I take one server offline and inform the load balancer that she will not be available and once I make sure that the new version is working fine I make it live.. I do the same thing for the next server.
Do we have any other option?
It is not a technical solution, but set up a scheduled maintenance window. You can annoucement in advance giving your user base fair warning that there is a possiblity that the application will not be available during that time frame.
Following recent hardware problems, I attempted to switch a couple of our websites to use new, individual application pools. A test run on our staging server worked fine, and has had no visible negative consequences.
Unfortunately, trying the same operation on our live machine left one of our key applications struggling - my best guess is with some kind of mismatch in Session state. I could log in fine, but a few clicks later would be presented with a screen that was part login screen, but with all menus visible. This indicates to me that part of the system thinks the session had been lost (redirect to login page), but IIS itself had not lost the session (hence the menus showing on the master page).
I tried recycling all the Application Pools (new and old), and each website using IIS Manager. I also tried a single-space change to the web.config file, and a full release of the dll's. Still, I could intermittently use the system for a few clicks, do some useful stuff, then maybe find myself at a login screen again or similar. We have some logging and on some occasions I could see that the session was being timed-out after a couple of seconds, substantially less than the settings on the App-pool (default 20mins).
As soon as I switched the web site's app-pool back to the default, everything was ok again.
What have I missed? Any suggestions gratefully received!
EDIT:
Just thought... on the staging environment I did name the App-pool differently from the website name (e.g. Xxxx_Dev, Xxx_Test etc) but on live I just called it the same name as the website. Could this cause an issue?
do your various applications all use Forms Authentication? Have you specified unique path attributes in each form tag in the web.config under the Authentication tag?
OK. I think I've found the problem.
I was actually using an Application Pool that had been set up by someone else - of the expected name - but they had set it up with the Properties, Performance tab | Web Garden option to use 4 worker processes. I have now changed that to 1.
As the session state was being stored 'In Process' (the default), each time the connection hit a new thread it also essentially lost any stored session variables, as I now understand things.
Its early days, but a simple switch to the newly altered Application Pool (no restarts or web.config saves necessary thus far) and everything appears to be behaving normally.
I dislike it when I lose the session state of my ASP.NET web app when changing code.
Losing the session state means I have to log in over and over again. It's annoying.
Is there anyway I can reconfigure my app so that I can make changes to code and not have to re-authenticate to view those changes?
(I know that changing .ASPX files does this fine. My concern is over App_Code and Bin compiled code.)
Unfortunately changes in the web.config or in dll's in the bin folder will cause an application reload and there is nothing you can do about it, AFAIK.
I wonder what will happen if you will store session state in StateServer. Maybe it will work ( I will be surprised if it does).
If you are in a developer environment you can try disabling logging into the site, or when the site checks for authentication just return your default authentication. For production, a StateServer will help as Igal pointed out.
One last option, store the login information in Session, but as a backup to that use a login table in your database to be able to restore a user's authentication status from a cookie. Obviously, consider security implications.
By changing your StateServer to use your machine (enabling the ASP.NET State Service), you won't lose your login.