I have 3 applications running at my end.
RootSite
RootSite/VirtualDirectory1
RootSite/VirtualDirectory2
I have a login page in three of these applications. When I login in either of these applications the .ASPXAUTH cookie is set but I am seeing that all of the three applications are updating the same .ASPXAUTH cookie instead of creating individual one. For example a user login on "RootSite", .ASPXAUTH cookie is created, now the user comes and login in the application "RootSite/VirtualDirectory1" and this time I am seeing the same .ASPXAUTH cookie is updating. I am confirming this because the created date of this cookie has been changed. So this means instead of creating a new cookie it is using the same cookie. How can I resolve this ? I don't want to interfere the logged-in logged-out status of one application with the other ?
Add\Change the name attribute in your Forms Authentication web config entry - See this article
Related
Is there a way to remove the authentication cookie, or sign a user out once they are removed from the asp.net membership database? By default if a user is removed from the database, the user can still browse the website since they still have a valid authentication cookie.
I've tried different things within global.asax but nothing seems to work. Is something like this even possible?
See here: FormsAuthentication.SignOut Method. Although this refers to users not being logged out server side, a similar approach can be used for managing deleted users.
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie. To improve security when using a forms authentication cookie, you should do the following:
Use absolute expiration for forms authentication cookies by setting the SlidingExpiration property to false. This limits the window in which a hijacked cookie can be replayed.
Only issue and accept authentication cookies over Secure Sockets Layer (SSL), by setting the RequireSSL property to true and by running the entire Web site under SSL. Setting the RequireSSL property to true ensures that ASP.NET will never send an authentication cookie to the browser over a non-SSL connection; however, the client might not honor the secure setting on the cookie. This means the client might send the forms authentication cookie over a non-SSL connection, thus leaving it vulnerable to hijack. You can prevent a client from sending the forms authentication cookie in the clear by running the entire Web site under SSL.
Use persistent storage on the server to record when a user logs out of the Web site, and then use an application event such as PostAuthenticateRequest event to determine whether the current user was authenticated with forms authentication. If the user was authenticated with forms authentication, and if the information in persistent storage indicates the user is logged out, immediately clear the authentication cookie and redirect the browser back to the login page. After a successful login, update storage to reflect that the user is logged in. When you use this method, your application must track the logged-in status of the user, and must force idle users to log out.
The third option is the most secure but requires the most effort. IMO, the first two do not resolve the issue adequately.
It is also possible to store custom information in the Forms Authentication Ticket. You could store the last explicit logout time in this ticket, and check it against your server side database record. Please note that if this record is at user level instead of session, then all logins under that account would be logged out at the same time.
In your case, if you are deleting server side user and session records, as the record does not exist you will be able to also fail the authentication request.
I'd advise also storing and checking the last date/time the password was changed - that way if a user updates their password then all existing sessions are logged out.
It is a Plain ASP.NET application using SQL Membership Provider for authentication. While application runs good most of the time. We have recently seeing complains from users saying they are seeing other users account.
I am pretty sure & confirmed again I directly consume HttpContext.Current.User.Identity.Name in the code to get user information. So under heavy load I get different user name returned.
Has anyone faced similar issue ? Have possible cause ?
Application Runs in ASP.NET 4.0, Web Forms , No caching ,Not handled any cookies in code, no Javascripts that is sniffing cookies.
I see these two links taking about same but no answers posted.
http://bytes.com/topic/asp-net/answers/324385-serious-issue-httpcontext-current-user-identity-name
http://www.experts-exchange.com/Web_Development/Miscellaneous/Q_21105924.html
Forms Authentication shouldn't be related to Membership provider too much.
FormsAuthentication saves signed user information into .ASPXAUTH cookie. And when next request comes to server, it decrypts cookie value and set it back to HttpContext.Current.User.Identity.Name. It uses MachineKey for encryption\decription. Then it creates FormsIdentity object based on FormsAuthenticationTicket object that holds username. So, your userName is stored on client. And whole this process doesn't include usage of Membership provider.
Forms Authentication uses Membership only when you do login for user, and then based on logged in user FormsAuthentication creates a cookie with UserName.
About your problem, you need to check .ASPXAUTH cookie value for those requests who has invalid UserName. You can try to log cookie information for these bad requests, and then you can decrypt them to get userName info from request. Or if you can reproduce it locally you can disable Forms cookie encryption (protection element), and then check it's value for bad requests
I'm building web portal in ASP.NET MVC 3 that uses distant web service as only way to communicate with database. Web service has requirement to always have Username/Password passed in request header, otherwise it rejects the call.
I have overridden ASP.NET Membership so that my ValidateUser method sends Username/Password to web service Login method, and returns true/false if authentication is successful. It works quite nice with AcountController provided with MVC 3 Empty internet template. Since I have to pass Username/Password on every web service call, I'm saving them in Session.
My problem is:
If I close browser and reopen it... I remain logged to website, but my Session variables are expired, so none of my requests to web service are being accepted, even though I'm still logged with credentials.
I'm looking for nice suggestion how to sync user logged in state with session state. Either to keep them both persistent until log off is used or to have them both dispose on browser being closed.
Thanks for all suggestions :)
When the user signs in using your AccountController, try setting the auth cookie like this:
FormsAuthentication.SetAuthCookie(model.UserName, false);
This should tell ASP.NET to delete the cookie when the browser window is closed. Then, when user opens up a new browser, both the session and the auth cookie should both be destroyed.
Sessions are cookies on the client side. Forms Authentication (which uses your membership provider) also uses cookies.
They are different.
Is your auth ticket or cookie persistent? This MS KB will explain things and scenarios in more detail than I would here...
Hth.
Hi,
I need to determind how my site uses Cookies to inform the user in proper way.
The solutio is a ASP.NET MVC website using .NET Membership. Im storing data in sessions on server but nothing is saved manual to cookies on the client. I Supose however that the ASP.NET Membership is using cookies (for autologin) but im not sure witch data it really stores on the client?
Could you pleas explain or give me a link for this?
BestRegards
The forms authentication ticket (the cookie on the client) stores values such as the username and cookie expiration time along with some other boolean fields related to the remember me checkbox and sliding expiration. This is if you use cookie-based forms authentication which is the default and a typical choice. More information can be found at the following site:
Forms Authentication Explained
It is important to note that sessions and the forms authentication ticket (cookie) are not related in any way. You can have a session without being logged in and you can login and never touch the session object. This is an important difference.
EDIT
This cookie is not used for 'auto login'. After authentication, putting in a username and password, the cookie is created and is used for authorization - can you access these resources - throughout your site.
ASP.NET Membership enabled sites will have up to 3 cookies:
Session token
Authentication token
Roles cache (if enabled in
web.config)
To see them, open your site in the browser of your choice, login, and inspect the cookies. In IE its Tools -> Internet Options -> Settings (next to Browsing History) -> View Files
Suppose I have logged into an web application. I'm on the page Default.aspx. If iis restarts then I need to re-login to use the application.
Is it possible to go back to the same page if IIS restarts?
How are you authenticating your users? Using forms authentication stores a client side cookie which can survive IIS resetting. Are you storing any authentication information in session state perhaps?
Edit
Just to add you can also redirect a user to a different page from the login page. Take the following url http://example.com/Login.aspx?ReturnUrl=%2fDefault.aspx.
This URL can be used to redirect the user to the Default.aspx page after they login. Assuming your using Forms authentication you can then redirect them using FormsAuthentication.RedirectFromLoginPage(userName, false); The false parameter prevents a persistant cookie from being created.
If you mean the ASP.Net application domain recycles, you're issue is that you're losing session state data, right? If that's the case, then how about storing session data in the StateServer or inside SQL Server? The default is "in process", so it's wiped clean when the app domain recycles.
If you set a cookie on each page the user vists stating which page they were on, then in your OnLoggedIn event you can check for the existance of this cookie, and redirect the user to the page - we use a similar mechanism for round-robin logins to multiple domains at once.