I have an issue with Identity 2.0 on Asp.NET MVC 5 project.
I am not using sessions, just the basic out of the box cookie based features.
My shared server currently recycles the application at a high frequency.
when this happens all the users get logged out.
The ApplicationCookie in the HttpContext.Request.Cookies remains the same but you get redirected to the login page and all identity.user properties are no longer there.
Is this normal and what sort of work rounds are there for maintaining logins after recycling?
Any advice would be really appreciated.
Is this a cache or machinekey issue?
(the website has plesk IIS interface so I don't have full control over it)
Still not sure why the server is restarting the application regularly as none of the settings reflect this. However found the reason for the users being logged out is due to identity 2 using a machine key that gets refreshed everything is resets the app
Related
I have developed an ASP.NET MVC 5 application and it is hosted on shared hosting - IIS 10.
For authentication, I am using identity to check authentication.
I'm logging in and out multiple times in my application. After 6 or 7 attempts, it directs me to the 403 error page.
After clearing the cache from the browser, it works fine again.
Please assist me to find a solution.
I updated the machine key as well. still getting the same issue.
The error initiates from the dynamic compression module when we check the tracing
I got an answer from the Hosting team. They have installed (ModSecurity)WAF to block requests from understanding the behavior of requests. After disabling this works fine now.
It will definitely help someone.
Thanks.
When I'm deploying an ASP.NET Core web application to Azure, I have an issue with the session : they are shared across browsers.
Explanation : I'm going to my deployed site, I log in with my email/password then I'm logged in. If I open the website in an other browser on the same machine or on an other machine, I'm now connected with the credentials I used in the first browser.
I deployed the default template from Visual Studio without any changes.
Is there something to do to resolve this issue or am I missing something ?
Pretty sure this functionality is by design... and it makes a lot of sense - you wouldn't want to have to re-authenticate if you opened another tab to view a document in your on-line banking would you?
If you need to logon without sharing the cookies with existing browser (it will be the cookies that are holding the reference to the session that ensures the server knows who you are) you need to start a new session. For Internet Explorer this is simply File >> New Session.
For Chrome it is a little more complicated but explained here... Separate session for each window
I need to know the best practices for deploying a new version of an ASP.NET MVC application while users are still connected to it
Everytime one deploys the .dll that contains the models and controllers of the application, the application is rebooted. Also deploying the web.config (that references eventually new libraries) results in rebooting the application.
So, the question is: how do I update the application's dll or web.config without disconnecting the users from the site?
You want to use another session state option other than using in-proc so your users survive when the process recycles or system reboots.
InProc: In-Proc mode stores values in the memory of the ASP.NET worker process. Thus, this mode offers the fastest access to these values. However, when the ASP.NET worker process recycles, the state data is lost.
See ASP.NET Session State Options for more ASP.NET options and mentions of other third party session state providers.
This question also deals with possible deployment scenarios to help with the websites under load and slow app times after a pool recycle: How are people solving app pool recycle issues on deployment with large apps?
Ideally you want to be as stateless as you can, and stay away from session. Perhaps you can use a cookie for tracking the current user via forms auth for example. But you must stay away from in-proc by using distributed cache/session provider so users won't lose session state on app pool recycles.
I think the best is to deploy a new site for new sessions, and mantain existing sessions in the old one.
I feel that "The blue green deployment strategy" article linked below can be hacked with a few changes to do that (Disallow New Connections instead of issue a "drain", using sticky sessions).
https://kevinareed.com/2015/11/07/how-to-deploy-anything-in-iis-with-zero-downtime-on-a-single-server/
I've asked similar question here because I thought the problem was in my custom membership provider.
Then I tried this:
I created two NEW asp.net MVC applications. In first one, I registered as new user using default membership provider. I closed this application, opened second one and ran it. In this application I was also logged in as user I created in first application. Logging in as user from other application doesn't work, but caching is remembered on this site. Why is it so? Is it a bug?
I think this can be expected behaviour:
If you open localhost/app1 and localhost/app2 you are on the same domain. So its valid that the same cookie is sent. I am not shure if localhost:5050 localhost:5060 are considered as the same domain. But I guess thats the case.
If the same cookie is sent the Memebershipsystem will evaluate this as the same user. Thats expected behaviour.
If you want to have these 2 webs use different pools of users you have to create a new application in the Mebershipsystem and configure it in web.config.
This will not affect the behaviour of a production system, because the 2 web will be on a different domain. each domain is only allowed to access its own cookies.
I have a pretty simple ASP.NET MVC Site Application. (MVC 1.0)
I have NO authorization sections in my web.config because I use the [Authoize] attribute on my controllers.
The default web.config for the server allows * for forms authentication, as expected.
I have 2 existing Windows 2008 dedicated (hosted) servers. The site works well.
I have a new dedicated server, seems identical except the site just won't work. Every resource, even images/javascript is redirecting to the login page.
I tried adding explicit authorization rules to allow * and location rules, same result. I checked the .NET Trust level, Internal/Full Trust. Everything runs perfectly on two servers, just this one is ignoring all rules for authorization.
Any ideas?
thanks
I found the issue :) Unless something has changed in Windows 2008 I would have expected this to show as an error but as stated above, it was being hidden by Forms Authentication.
The issue was the hosting company now adds data drives to all servers for your websites/storage. There were no permissions set to allow IIS to read the files. The reason I couldn't find it was I already added permission for the application pool user, in my case I just went ahead and added ASPNET, Network Service, IIS Anon User etc to have full permissions.
I needed to allow Everyone to have at least Read to the website folders and then IIS showed the non-secured content. I still think it is odd that forms auth. was kicking in and ignoring all web.config rules but anyway.
I found the error by turning off Forms Auth support in the IIS 7 manager. Then I got the process failure error because of file permissions.