I have an ASP.NET login control on a page, with the "Remember Me" checkbox displayed. I have checked in trace and the authentication cookie is being created, I have sliding expiration set and a timeout of 60000, yet when I return to the website the login is not being remembered.
Any ideas where else I can check?
Thanks,
Darryl
Correct! The Remember Me checkbox doesn't do anything for you and why should it?
After succesful login; you could create the cookie from code and (when entering the page or masterpage or whatever) attempt to read the previously made cookie to get your credentials.
Or you could use the SetAuthCookie when using FormsAuthentication; reference: http://msdn.microsoft.com/en-us/library/sxb3b282(vs.71).aspx
I've found that whenever any problems are potentially related to cookies, that Firecookie is an invaluable tool for finding out what is actually going on...
Related
I'm having some troubles on ASP authentication:
Users can connect via an ordinary Login view.
I want those who know to be able to connect as someone else. To do so, if they type
username**_as**, an other textbox appears and they can type the user they want to connect as.
My problem is that I let default behavior of ASP(and web.config) handles everything so far.
So when the user click on login, the username is username_as (and is obviously not recognized ;))
What I want is to send username (without the suffix) but I don't know where I can split the textbox value.
(I've started to do dirty stuff but I guess there is a proper way of doing it right? :))
Thank you very much!
What I've done to solve my problem was adding a OnClientClick event on the Sign In button.
In this function I just modify the value of LoginUser_UserName.
It works for the click but also on the Enter validation.
Not super clean but it works. (And I didn't have to implement in the code behind the AD authentication)
ViewStateUserKey seems like a very useful feature to prevent some CSRF attacks. Why is it not enabled by default in asp.net applications?
I tell some thoughts about:
The ViewStateUserKey can break the viewstate in a valid user and as result a valid user see an error. So its better to let it out, and only advanced programmers use it and know why the view state is break and handle it if possible.
Lets give you some examples.
If you use it as it is:
void Page_Init (Object sender, EventArgs e)
{
if (User.Identity.IsAuthenticated)
ViewStateUserKey = User.Identity.Name;
}
and see this steps.
a valid logged in user see a GridView on a page that is not require
logging.
this user have left the page some time, and the logging is
expired
now is try to paging the gridview, and gets a viewstate break
Why, because is start the page using the ViewStateUserKey, but after is expired the ViewStateUserKey is now different (null because the user is not logged in now) and break the viewstate and at the same time this page is not required to be logged in, and not redirection is happens to ask for logging again.
With this simple example, that is really happened to me, I say that this parameter can break the view state and if this set by default is may lead to some issues like that.
relative:
ViewStateUserKey + shared hosting + ViewStateMac validation failure
http://www.hanselman.com/blog/ViewStateUserKeyMakesViewStateMoreTamperresistant.aspx
http://msdn.microsoft.com/en-us/library/ms972969.aspx
Conclusion from experience.
If you use this key for any page that is not request login, and you are just in other pages logged in, this can easy create viewstate error on post back and break the page, and the post back. So you can not have it enable by default - and the one that use it must know this case I describe above.
When the user uses the "remember Me" option in the login control, it obviously stores a cookie somewhere and the log in gets automated.
Unfortunately I use the login controls "Logged In" event to set up other objects. When the user goes in with the Remember Me function they can bypass this event.
Is there another event i cat catch?
Failing that, is there a safe way to query the membership system to see who is logged in at any time? then i can test myself.
Thanks
You can work with User.Identity.Name
if (Request.Cookies["myCookie"] != null)
{
HttpCookie cookie = Request.Cookies.Get("myCookie");
String UserName = cookie.Values["username"];
this.Login1.RememberMeSet = !(String.IsNullOrEmpty(UserName));
}
I think you can create an HTTP Handler or use Application Events to check if user is authenticated and set up other objects
I don't think you can find any other membership event after LoggedIn , however you can get events from Page Life Cycle.
I suppose you must be redirecting to some default page after successful log in. You can try following code to get the loggedin user name if login was success.
User.Identity.Name
I have a form that sits behind ASP.NET forms authentication. So far, the implementation follows a typical "out of the box" type configuration.
One page allows users to post messages. If the user sits on that page for a long time to compose the message, it may run past the auth session expiration. In that case, the post does not get recorded... they are just redirected to the login page.
What approach should I take to prevent the frustrating event of a long message being lost?
Obviously I could just make the auth session really long, but there are other factors in the system which discourage that approach. Is there a way I could make an exception for this particular page so that it will never redirect to the Login so long as its a postback?
My coworker came up with a general solution to this kind of problem using an HttpModule.
Keep in mind he decided to to handle his own authentication in this particular application.
Here goes:
He created an HttpModule that detected when a user was no longer logged in. If the user was no longer logged in he took the ViewState of that page along with all the form variables and stored it into a collection. After that the user gets redirected to the login page with the form variables of the previous page and the ViewState information encoded in a hidden field.
After the user successfully reauthenticates, there is a check for the hidden field. If that hidden field is available, a HTML form is populated with the old post's form variables and viewstate. Javascript was then used auto submit this form to the server.
See this related question, where the answers are all pretty much themes on the same concept of keeping values around after login:
Login page POSTS username, password, and previous POST variables to referring page. Referring page logs in user and performs action.
Login page writes out the form variables and Javascript submits to the referring page after successful login
AJAX login
If you don't care if they're logged in or not when they POST (seems a little iffy security-wise to me...) then hooking HttpContext.PostAuthenticateRequest in an IHttpModule would give you a chance to relogin using FormsAuthentication.SetAuthCookie. The FormsAuthenticationModule.Authenticate event could be used similarly by setting an HttpContext.User:
// Global.asax
void FormsAuthentication_OnAuthenticate(object sender, FormsAuthenticationEventArgs e) {
// check for postback somehow
if (Request.Url == "MyPage.aspx" && Request.Form["MySuperSecret"] == "123") {
e.User = new GenericPrincipal(new GenericIdentity(), new string[] { });
}
}
When the session timeout happens the user's session (and page information) get disposed, which would mean the eventual postback would fail. As the others have suggested there are some work arounds, but they all assume you don't care about authentication and security on that particular page.
I would recommend using Ajax to post back silently every 10 mins or so to keep it alive, or increase the timeout of the session as you suggest. You could try to make a page specific section in your web config and include in there a longer timeout.
I handled this once by adding the form value to the database, identified by the remote IP instead of user ID.
( HttpContext.Request.UserHostAddress )
Then, after login, you can check to see if the current user's IP address has a row in the database, and perform the required action.
Michael
I have a requirement for an explicit logout button for users in a ASP.NET web app. I am using IIS6 with Basic Authentication (SSL). I can redirect to another web page but the browser keeps the session alive. I have googled around and found a way to do it by enabling an active x control to communicate with IIS and kill the session. I am in a restricted environment that does not allow forms authentication and active x controls are not forbidden as well. Has anyone else had this requirement and how have you handled it?
Okay that is what I was afraid of. I have seen similar answers on the net and I was hoping someone would have a way of doing it. Thanks for your time though. I guess I can use javascript to prevent the back button like the history.back()
I was struggling with this myself for a few days.
Using the IE specific 'document.execCommand('ClearAuthenticationCache');' is not for everyone a good option:
1) it flushes all credentials, meaning that the user will for example also get logged out from his gmail or any other website where he's currently authenticated
2) it's IE only ;)
I tried using Session.Abandon() and then redirecting to my Default.aspx. This alone is not sufficient.
You need to explicitly tell the browser that the request which was made is not authorized. You can do this by using something like:
response.StatusCode = 401;
response.Status = "401 Unauthorized";
response.AddHeader("WWW-Authenticate", "BASIC Realm=my application name");
resp.End();
This will result in the following: the user clicks the logout button ==> he will get the basic login window. HOWEVER: if he presses escape (the login dialog disappears) and hits refresh, the browser automagically sends the credentials again, causing the user to get logged in, although he might think he's logged out.
The trick to solve this is to always spit out a unique 'realm'. Then the browser does NOT resend the credentials in the case described above. I chose to spit out the current date and time.
response.StatusCode = 401;
response.Status = "401 Unauthorized";
string realm = "my application name";
response.AddHeader("WWW-Authenticate", string.Format(#"BASIC Realm={0} ({1})", realm, DateTimeUtils.ConvertToUIDateTime(DateTime.Now)));
resp.End();
Another thing that you need to do is tell the browser not to cache the page:
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(DateTime.MinValue);
Response.Cache.SetNoStore();
With all these things in place it works (for me) in IE, but until now I still wasn't able to prevent firefox from logging in the user when the user first presses escape (hides the basic login dialog) and then refresh (F5) or the browsers back button.
The Session.Abandon method destroys all the objects stored in a Session object and releases their resources. If you do not call the Abandon method explicitly, the server destroys these objects when the session times out.
Have you tried calling Session.Abandon in response to the button click?
Edit:
It would seem this is a classic back button issue.
There is very little you can do about the back button. Imagine the user has just opened the current page in a new window then clicked the logOut button, that page appears to log out but it will not immediately affect the content of the other window.
Only when they attempt to navigate somewhere in that window will it become apparent that their session is gone.
Many browsers implement the back button in a similar (although not identical) way. Going back to the previous page is not necessarily a navigation for a HTML/HTTP point of view.
This is a solution for this problem that works in IE6 and higher.
<asp:LinkButton ID="LinkButton1" runat="server" OnClientClick="logout();">LinkButton</asp:LinkButton>
<script>
function logout()
{
document.execCommand("ClearAuthenticationCache",false);
}
</script>
Found this from
http://msdn.microsoft.com/en-us/library/bb250510%28VS.85%29.aspx
Web Team in Short
Your Credentials, Please
Q: Jerry B. writes, "After the user has validated and processed his request, I now want to invalidate him. Assuming this machine is in an open environment where anyone could walk up and us it, I want to throw a new challenge each time a user accesses a particular module on the Web."
A: This is a frequently requested feature of the Internet Explorer team and the good people over there have given us a way to do it in Internet Explorer 6.0 SP1. All you need to do is call the execCommand method on the document, passing in ClearAuthenticationCache as the command parameter, like this:
document.execCommand("ClearAuthenticationCache");
This command flushes all credentials in the cache, such that if the user requests a resource that needs authentication, the prompt for authentication occurs again.
I put this on my logout link button and it works in IE6 sp1 and higher:
OnClientClick="document.execCommand('ClearAuthenticationCache');"