When you have forms authentication setup to redirect to login.aspx when accessing a protected page, what's a good way to detect in login.aspx whether the user was sent there because they haven't logged on yet, or because their forms auth ticket is expired? I'd like to display a "you've timed out" message.
(I do not mention the word session in this question, because ASP.NET treats them so distinctly, however, if there is a good solution that involves session, I'm all ears)
I've solved this in the past by having another cooke "hasloggedin" set when a user logs in and then checks to see if that exists to determine if it's a timeout and then display an appropriate message. But, this has to be a common problem?
Forms authentication will automatically append a URL parameter 'ReturnURL', indicating what page (if any) triggered the redirection to the login page. Most websites have a 'Default.aspx' or 'index.html' etc as the default page. You can check the ReturnURL to see if it contains the default page, or some other page in your application.
EXAMPLE:
string refererURL;
if (page.Request.QueryString["ReturnURL"] != null)
{
refererURL = page.Request.QueryString["ReturnURL"].ToString();
}
//Check to see if user was redirected because of Timeout or initial login
//Where "Default.aspx" is the default page for your application
if (refererURL != "" && refererURL != (ResolveUrl("~") + "Default.aspx"))
{
//Show HTML etc showing session timeout message
}
else // User redirected here to to initial login
{
//Show HTML showing initial login HTML message etc
}
Related
We have an internal system where users can authenticate using Windows authentication but we want to include some custom content in the 401 repsonse that takes the user to a custom username/password authentication page if the cancel off the Windows authentication dialog.
When an unauthenticated user accesses a page, Windows authentication responds with a 401 Unauthorized response, with the headers
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
This prompts the browser to show a dialog asking for Windows credentials. If the user enters their credentials, there is another handshake request-response, and then the user is authenticated and the requested page is shown.
If the user cancels the dialog, the browser displays the content of the original 401 Unauthorized reponse.
We use Application_EndRequest in the Global.asax to return some custom content here which takes the user to our custom login system.
/// <summary>
/// If we are about to send the NTLM authenticate headers, include this content. Then, if the user cancels off the
/// windows auth dialog, they will be presented with this page and redirected to the username / password login screen
/// </summary>
void Application_EndRequest(object sender, EventArgs e)
{
Logger.DebugFormat("in Application_EndRequest. Response.StatusCode: {0}", Response.StatusCode);
if (Response.StatusCode == 401)
{
Response.ContentType = "text/html";
var redirectUrl = string.Format("https://mycompany.com/SSO/Login?encryptedSessionRequestId={1}",
HttpUtility.UrlEncode(Request.QueryString["encryptedSessionRequestId"]));
var text = File.ReadAllText(Server.MapPath("~/UnauthorizedError.html"));
text = text.Replace("[USERNAME_PASSWORD_LOGON_REDIRECT]", redirectUrl);
Response.Write(text);
Logger.Debug("Done writing response");
Response.End();
}
}
UnauthorizedError.html contains the following script which forwards the user on
<script language="javascript" type="text/javascript">
window.location = "[USERNAME_PASSWORD_LOGON_REDIRECT]";
</script>
When running locally in (Win7/IIS7.5), this works great, we use Response.Write() to send our content and the user is able to see it when they cancel the dialog.
But when accessing the site remotely, e.g. when it running in our development environment, although we can see from the logs that Application_EndRequest is being called and our content written to the response, it is overridden at some point and all that reaches the browser is the authentication headers and the text You do not have permission to view this directory or page.
1) How can we prevent this content being overwritten?
2) Where in the pipeline might this be happening?
3) Does anyone have any suggestions of another way to implement this behaviour, e.g. with an HTTP module?
Thanks!
I wasted a lot to solve this problem but there isn't direct solution.
It because win auth works on iis not site level and you can't control how to auth current request.
There is several hacky ways to use redirection on different login pages depending on ip.
I know this is an old post but I would like to share a solution to this problem.
When altering the response message for remote requests (read: non-localhost) you will need to add the following to your config file:
<system.webServer>
<httpErrors existingResponse="PassThrough"></httpErrors>
</system.webServer>
If you do not allow the response to "pass through" remote clients will get the default "You do not have permission to view this directory or page".
I got this info from: https://stackoverflow.com/a/17324195/3310441
I am the administrator and I need to delete a user.
If the user is authenticated at the moment I delete it, what is the best strategy to force the deleted user to logout at the next request?
Must I handle this operation in the Application_AuthenticateRequest event?
In other words, can be an idea to verify in the AuthenticateRequest event if the user still exists and, if not, to delete all the cookies and redirect to logon page?
After some research and evaluation, finally I have found a strategy to handle this scenario, so, in Global.asax:
protected void Application_AuthenticateRequest()
{
var user = HttpContext.Current.User;
if (user != null)
{
if (Membership.GetUser(user.Identity.Name, true) == null)
{
CookieHelper.Clear();
Response.RedirectToRoute("Login");
}
}
}
When the request is authenticated, we verify that the user still exists in the system, if not all the cookies will be deleted and the request will be redirected to the login page.
If you delete them, then I'm assuming their next request would most likely error out for them.
Even if they have the authentication cookie, any page that checks the database against their UserID would obviously throw an exception.
You can most likely just disable the user instead of having to delete them.
Is it possible in Asp.NET MVC to proframmatically logout a user? I am aware that you can use:
FormsService.SignOut();
But this refers to the context of the webpage making the request. I'm trying to prevent a user logging in twice. So if I call:
MembershipUser membershipUser = Membership.GetUser(userName);
if (membershipUser.IsOnline == true)
{
// log this user out so we can log them in again
FormsService.SignOut();
}
Calling FormsService.SignOut(); has no bearing on the context of the user say, with another webbrowser who is logged in already?
One common method to accomplish this goal is to, on each page load, check whether the current user needs to be signed out.
if (User.Identity.IsAuthenticated && UserNeedsToSignOut())
{
FormsAuthentication.SignOut(); // kill the authentication cookie:
Response.Redirect("~/default.aspx"); // make sure you redirect in order for the cookie to not be sent on subsequent request
}
You may be concerned that this method will be too slow,
"Why do I have to call this damned function each page load? It probably hits the database each time!"
It doesn't need to be slow. You may cache a list of users that should not be signed in at any given time. If their username is in that cache, then the sign out code will be triggered next time they access a page.
Take a look at this blog How to allow only one user per account in ASP.Net
I have multiple asp.net sites. When a user logs unto one of the sites, I want to store a cookie telling me that a user has logged on. When the user later visits one of the other sites I have, I would like to read the cookie from that site.
AFAIK you neither can read cookies from or write cookies to other sites, so what could a workaround be?
Perhaps making a redirect to http://www.othersite.com/SaveCookie.aspx ?
Give me some ideas :-)
One of our clients has exactly the same requirement (logging into multiple sites on different domains), complicated by the fact that one of the sites requires that the user is logged in to a classic ASP application, a .NET 1.1 application and a .NET 3.5 application running on different hardware, but under the same domain...
We've basically implemented a system of round-robin style redirects, where each domain logs the user in, then bounces them on to the next domain until they return to the original domain at which point they are redirected to their original request.
So (pages and domains changed to protect the innocent):
User requests www.example1.com/page1.aspx
A cookie is set that tells us the user was attempting to access page1.aspx, and the user is sent to the www.example1.com/login.aspx
The user logs in, and is then redirected to www.example2.com/processlogin.aspx?token=EncryptedToken
ProcessLogin.aspx checks for a cookie telling it where to direct the user, if it can't find one, it decrypts the token, logs the user in on example2.com, and then redirects them to www.example1.com/processlogin.aspx?token=EncryptedToken (or example3.com - repeat as required)
As in 4, ProcessLogin.aspx checks for the cookie, finds it, deletes it and redirects the user to /page1.aspx.
If the user later on visits a page on www.example2.com, before the authentication ticket timeout, they will still be logged in on that site as well.
Edit to respond to comment
That depends on how you are making the "request to the other pages". If you make the request from your code behind, what you're doing is effectively setting the cookie on the server, rather than on the users browser.
Cookies need to be issued by the server to the client browser, and that is done in the headers of the page response - so you need to direct the users browser to a page on the other site to issue the cookie from that domain.
You could generate a request to the other page in an IFrame, or try and do it in a self closing pop-up window - but that has other issues like pop-up blockers, flickering windows, etc.
After some investigation we found that a round-robin set of redirects like this was the simplest and most reliable solution.
A very basic code setup:
An .aspx page, containing a Login control, with a method "OnLoggedIn" attached to the LoggedIn event of the control:
void OnLoggedIn(object sender, EventArgs e){
string returnUrl = Request.QueryString["returnUrl"];
// Create new cookie, store value, and add to cookie collection
HttpCookie myCookie = new HttpCookie("WhereTo");
myCookie["ReturnUrl"] = ReturnUrl;
Response.Cookies.Add(myCookie);
// Redirect user to roundtrip login processor on next domain.
// Work out domain as required.
string redirect = GetNextDomain();
// Add encoded user token
redirect += "?token=" + EncodeUserToken();
// Redirect the user, and end further processing on this thread
Response.Redirect(redirect, true);
}
Then on both servers you have ProcessLogin.aspx, that has something like this in it:
protected void Page_Load(object sender, EventArgs e){
// Look for redirect cookie
if (Request.Cookies["WhereTo"]["ReturnUrl"] != null){
// Save value from cookie
string redirect = Request.Cookies["WhereTo"]["ReturnUrl"];
// Delete original cookie by creating an empty one, and setting it
// to expire yesterday, and add it to the response.
HttpCookie myCookie = new HttpCookie("WhereTo");
myCookie.Expires = DateTime.Now.AddDays(-1d);
Response.Cookies.Add(myCookie);
// Redirect the user, and stop processing
Response.Redirect(redirect, true);
}
// Still here, so log in and redirect
string encryptedToken = Request.QueryString["token"];
if (!string.IsNullOrEmpty(encryptedToken)){
// Decrypt token, and log user in
// This will vary depending on your authentication mechanism
PerformLogin(encryptedToken);
}
// Redirect user to roundtrip login processor on next domain.
// Work out domain as required.
string redirect = GetNextDomain();
// Add encoded user token - no need to recalculate, it will be the same
redirect += "?token=" + encryptedToken;
// Redirect the user, and end further processing on this thread
Response.Redirect(redirect, true);
}
You're looking for a Single Sign-On (SSO) solution.
If it's possible for you to host your sites at different subdomains below the same domain, you can save cookies that are shared for the whole domain, e.g.:
"site1.yourdomain.com" and
"site2.yourdomain.com"
can both read cookies saved to the domain "yourdomain.com"
Another alternative is to tell the other site about the login via a request to it, as in your redirect suggestion. You could do this in several ways, e.g. by loading the page in an iframe, sending the data directly from one server to another, and so on. None of these are particularly elegant, though, and in the case of login, as Tomas Lycken says, you should really be going for a proper SSO implementation.
We have an ASP.NET app protected by forms authentication. The app uses MS AJAX heavily to call its web-services.
When the forms authentication times out, and a GET-request happens - all is fine (the user is redirected to a login page).
BUT when the forms authentication times out and a POST-request happens (ajax) - no redirect happens, instead the app returns "401 unathorized" and the browser prompts for username and password (not a login form, but a browsers built-in dialog). Of course entering ANY username/password never helps.
How do I handle this?
UPDATE: After looking with firebug, I just found out that regular POST requests redirect to login fine, it's only web-service calls that throw "401 Unauthorizes".
The difference between a regular request and web-service is URL. Which is "page.aspx" for a regular post-request and "service.asmx/MethodName" for webservices...
Ok, answering my own questin.
After looking into this issue and researching a bit more I found that when a web-app is protected by Forms-Authentication and the user is not authenticated, this is what happens:
If it's a GET-request - the user is
redirected to the login page.
If it's a POST-request to a page - the user is
redirected to the login page.
If it's a POST-request to a web-service - the
user gets 401-unauthorized
Thats how ASP.NET works
And if a web-service is called by AJAX (xmlHttpRequest object) and returns 401 - of course the browser shows a pop-up login box.
Now, what should you do is add some code to Application_PostAuthenticateRequest that will prevent throwing 401 for webservices.
protected void Application_PostAuthenticateRequest(Object sender, EventArgs e)
{
if (Request.RequestType == "POST" //if its POST
&& !User.Identity.IsAuthenticated //if user NOT authed
&& !HasAnonymousAccess(Context) //if it's not the login page
)
{
//lets get the auth type
Configuration config = WebConfigurationManager.OpenWebConfiguration("~");
SystemWebSectionGroup grp = (SystemWebSectionGroup)config.GetSectionGroup("system.web");
AuthenticationSection auth = grp.Authentication;
//if it FORMS auth
if(auth.Mode== AuthenticationMode.Forms)
{
//then redirect... this redirect won't work for AJAX cause xmlHttpRequest can't handle redirects, but anyway...
Response.Redirect(FormsAuthentication.LoginUrl, true);
Response.End();
}
}
}
public static bool HasAnonymousAccess(HttpContext context)
{
return UrlAuthorizationModule.CheckUrlAccessForPrincipal(
context.Request.Path,
new GenericPrincipal(new GenericIdentity(string.Empty), null),
context.Request.HttpMethod);
}
I see two solutions:
(1) "Heart beat" mechanism. On each page include a script that will "ping" the server by some dummy ajax request, like:
<script>
setInterval(ping, 60000); // based on comment by John
function ping()
{
$.get('/do/nothing');
}
</script>
This way the session shouldn't expire as long as the browser window is open.
(2) On each ajax request check the status of the response. If the response has "401 unauthorized" code (or any other code different that 200), that means that the session expired and instead of loading the response into some dialog box in the page redirect the user to login page.
Conclusion based on comments:
The best solution would be to combine the two above mechanisms. Heartbeat mechanism will help to keep the session alive as long as the page is displayed in the browser. But in doesn't guarantee that for sure. The connection to the server can be broke and reopened when the session is expired. So you should check the response status anyway.