We have an asp.net Core application (that is running under .net Framework 4.8) which is deployed withing IIS on a Windows Server 2016 box. This application uses asp.net Core identity framework for roles based access.
Everything works great but when we update the "Site Bindings" (by way of an example config change) within IIS all the connected users get logged out upin the next page request, perhaps the cookie/sessions being reset?!
Whilst this might be the behaviour you expect this was not the behavious we had on a previous "identical" installation which was lost (all data was backed up etc etc but the server host died and we lost the exact settings).
I remember reading a while back (but can't find it now) that the session should actually persist as this allows for load-balancing (which we don't need).
Nothing has changed in the code base for this to now not work so this suggests it's an IIS setting.
Does anyone have a magic change we can make for the connections to persists and our users not to be sent back to the logon page on the asp.net core app?
Thanks.
Jim.
*** update ***
Changing the "Identity" property of the Appl pool entry to System Account seems to allow me to change bindings without the (app pool?) reset.
Somewhat annoyingly, this appears to be the only setting that doesnt reset the user sesions when changing the binding. The obv downside of using this are the security considerations which rule it out!
Anyone with a plan c?
Related
I have a web app that executes in different servers with very different specifications, it depends on demand and on clients budget sometimes. Users are made aware of the downgraded experience of running the app on a server with very low RAM for example.
This year we updated our code from a ASP.Net 4.6 monolithic MVC5 code base to ASP.Net Core 3.1 Razor Pages using a Clean Architecture, and more recently to .Net 5. We have everything running smooth and as expected we experienced a huge performance boost.
The only problem we're facing is in scenarios with very low RAM shared hosting were the app has to be executed "out of process" and the app pool keeps restarting after very little time, active users get logged out on every app pool recycling. This didn't happened on the old version of the app, user would experience a delay on their request (sometime a rather long one but users working under this scenarios were aware of their server limitations), but after the app was up they could continue working without having to log in again. Now, after every app pool recycling all users sessions expire and they are asked to log in again, this is understandably unacceptable from their part. I didn't expect this to happen because we're using default identity, authentication and authorization which as far as I understand is cookie based.
One thing that I find odd is that on the site that keeps logging users out there are only two Cookies after users log in.
While on other sites where normal behavior is shown there are four cookies.
I am aware that this is not the best scenario to run a web server, but sometimes that's all there is.
Is there any way I can persist user sessions (maybe in SQL Server) so I can achieve something similar to what we had before? Or am I barking at the wrong tree here?
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 :
Add Session["init"] = 0 in Global.asax
Change cookieless=true in web.config
Change sessionState's mode to "StateServer"
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:
.NetFramework 4.8
Uses WCF service
Current session state info is sessionState mode="InProc" cookieless="false" timeout="60"
Configured c:\Windows\System32\Drivers\etc\hosts to add 127.0.0.1 testing.com
Tested using IE 11
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.
HttpContext.Current.Session["myvariable"]
I have thousand of SQL Server databases (one for each client). When we decide to push on production, we have most of the time changes in databases, the web API and the web application.
The problem is the time it takes to deploy everything, especially the databases. We are using Code First migration and MVC .NET and SQL Server, all with the latest version. It is a SaaS. And the code first migration process is able to update the database one-by-one.
The API and the web application are deployed very quickly within a few seconds. However, the databases are all updated within about 30 minutes. During that time some users got errors and cannot use the software because the API tries to target non-updated database. And worse, if during the databases update, something fails and stop, the non-updated users are stuck until we fix the issue and update the rest of the databases.
Any idea how to solve this problem and make clients happy?
PS: The web application doesn't access to the database, but only the API.
This question is somewhat opinion-based. The maintenance window approach is the easiest. If you want to do live-updating, another way would be:
Keep a version number in the database
Allow running multiple versions of the Web API side-by-side
Choose which version of the API to use by looking at the version in the database
Determine if the Web API's public interface is stable. If it is not, also find a way to allow running multiple web sites side-by-side and choose which one based on the version in the database
The most maintainable way to accomplish this would probably be to have at least 3 servers:
One backend server which hosts the old version
One backend server which hosts the new version
The frontend server which routes users to the proper backend server based on the current version.
The routing could take place only at login, or you could do something more fancy such as redirecting the logged-in user when an upgrade is detected. Obviously none of this deals with what happens to one particular client during the actual upgrade of that client's database. You'll still need to address that separately.
I am completely lost trying to figure this out. It has been going on for months. Session values just get lost. I check for Session["uid"] on master page to force user to login page.
System : Windows Server 2008 R2 Enterprise
IIS 7.5
.Net Framework 4.5 specified in web config
Application pool .Net Framework V4.0
Application pool Timeout set to standard 1740
Not a Web Farm.
Session In web config:
<sessionState timeout="60" mode="StateServer"></sessionState>
I changed the mode to StateServer thinking it is App pool random recycling causing it loose session
I check this post:
Losing Session State
I tested it myself. On a page where is loads countries and then cities based on country selection (updatepanel)... randomly it would just route me to login page on country change. And this is no delay in between change. Change, change, change... and then session["uid"] lost.
I read up on how IIS manages sessions:
https://abhijitjana.net/2010/03/14/beginner%E2%80%99s-guide-how-iis-process-asp-net-request/
can't seem to find answer there.
then i started getting errors like application pool max reached.
Then i set worker processes to 25, and it says it now a Web Garden.
Then i thought let me read up on Web Garden. According to this post it is a bad thing and should not be used ?
https://serverfault.com/questions/81689/web-gardens-are-they-good-or-bad-or-what
I just did the worker process increase today so i can't say if that will help, but i also dont want to leave that in place if it going to cause me other headaches.
My web site is non MVC, but i added an API controller to it. Not sure if this would be the issue for the session lost or app pool maxing out.
API not my biggest concern as we plan to move it to it's own MVC project.
But for now , my concern is the random session being lost.
I'm not sure it being lost. My code simply check if (Session["uid"] == null) go to login page.
I come from PHP / Apache history and never had any issues with Sessions.
Basic structure the same between c# masterpages and PHP template
I don't have any issues on localhost or dev server enviroment.
It's just when on live server that has a couple of other sites on this happens.
I don't think the other site will influence my site? THis is what application pooling prevents?
First of all, I'm not familiar with Web development so I might be missing something basic here. Do excuse me if that's really the case.
I'm currently working on a web application (not created by me), which is based on another web app.
Both applications share similar user log in code, but user account info are stored in different databases.
However, after logging in to 1 of the app, the WebSecurity.IsAuthenticated flag is also true on the other app (detected as logged on). Is this behaviour expected?
In case this information is of any use..
1 of the app uses ASP.NET development server while the other uses ISS express.
This is not exactly an answer to my initial question.
That has been answered by #Esa in the comment above --> Setting machine key to Web.Config.
The following is an answer to the problem I mentioned in the comment.
(Should I have posted this in comment instead?)
Both applications were overwriting the same __RequestVerificationToken cookie, which caused error "The anti-forgery token could not be decrypted..." when navigating.
This is because both applications were at the same path of "localhost:xxxxx" and hence detected as the same site. The error can be avoided by changing the virtual path of either application.
For VS, Project properties -> Web (tab) -> Virtual path