FormsAuthentication.RedirectFromLoginPage Method (String, Boolean)
Redirects an authenticated user back to the originally requested URL or the default URL.
Assembly: System.Web (in System.Web.dll)
public static void RedirectFromLoginPage( string userName, bool createPersistentCookie )
Parameters
- userName
- Type: System.String
The authenticated user name.
- createPersistentCookie
- Type: System.Boolean
true to create a durable cookie (one that is saved across browser sessions); otherwise, false.
| Exception | Condition |
|---|---|
| HttpException |
The return URL specified in the query string contains a protocol other than HTTP: or HTTPS:. |
The RedirectFromLoginPage method redirects to the URL specified in the query string using the ReturnURL variable name. For example, in the URL http://www.contoso.com/login.aspx?ReturnUrl=caller.aspx, the RedirectFromLoginPage method redirects tothe return URL caller.aspx. If the ReturnURL variable does not exist, the RedirectFromLoginPage method redirects to the URL in the DefaultUrl property.
ASP.NET automatically adds the return URL when the browser is redirected to the login page.
By default, the ReturnUrl variable must refer to a page within the current application. If ReturnUrl refers to a page in a different application or on a different server, the RedirectFromLoginPage methods redirects to the URL in the DefaultUrl property. If you want to allow redirects to a page outside the current application, you must set the EnableCrossAppRedirects property to true using the enableCrossAppRedirects attribute of the forms configuration element.
Security Note
|
|---|
|
Setting the EnableCrossAppRedirects property to true to allow cross-application redirects is a potential security threat. For more information, see the EnableCrossAppRedirects property. |
If the CookiesSupported property is true, and either the ReturnUrl variable is within the current application or the EnableCrossAppRedirects property is true, then the RedirectFromLoginPage method issues an authentication ticket and places it in the default cookie using the SetAuthCookie method.
If CookiesSupported is false and the redirect path is to a URL in the current application, the ticket is issued as part of the redirect URL. If CookiesSupported is false, EnableCrossAppRedirects is true, and the redirect URL does not refer to a page within the current application, the RedirectFromLoginPage method issues an authentication ticket and places it in the QueryString property.
The following code example redirects validated users to either the originally requested URL or the DefaultUrl. The code example uses ASP.NET membership to validate users. For more information about ASP.NET membership, see Managing Users by Using Membership.
Security Note
|
|---|
|
This example contains a text box that accepts user input, which is a potential security threat. By default, ASP.NET Web pages validate that user input does not include script or HTML elements. For more information, see Script Exploits Overview. |
<%@ Page Language="C#" %> <%@ Import Namespace="System.Web.Security" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <script runat="server"> public void Login_OnClick(object sender, EventArgs args) { if (Membership.ValidateUser(UsernameTextbox.Text, PasswordTextbox.Text)) FormsAuthentication.RedirectFromLoginPage(UsernameTextbox.Text, NotPublicCheckBox.Checked); else Msg.Text = "Login failed. Please check your user name and password and try again."; } </script> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <title>Login</title> </head> <body> <form id="form1" runat="server"> <h3>Login</h3> <asp:Label id="Msg" ForeColor="maroon" runat="server" /><br /> Username: <asp:Textbox id="UsernameTextbox" runat="server" /><br /> Password: <asp:Textbox id="PasswordTextbox" runat="server" TextMode="Password" /><br /> <asp:Button id="LoginButton" Text="Login" OnClick="Login_OnClick" runat="server" /> <asp:CheckBox id="NotPublicCheckBox" runat="server" /> Check here if this is <span style="text-decoration:underline">not</span> a public computer. </form> </body> </html>
Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core not supported), Windows Server 2008 R2 (Server Core supported with SP1 or later), Windows Server 2003 SP2
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.
This is a complicated matter.
You need to set the timeout variable on both Forms Authentication AND Session to a greater value than normally.
<authentication Mode="Forms">
<forms timeout="120" slidingExpiration="true" />
</authentication>
Note that the timeout variable will affect only the persistent cookie (= Remember me checked). So, in this example, the site will remember you for 2 hours (120 minutes). A non-persistent cookie, on the other hand, will time out when you close the browser. If you want the site to remember you for, let's say, 2 weeks, set this value to 20160. This, of course, does not affect your session, which is lost, and the site needs to regenerate your session, when you come back. This affects only the FormsAuthentication cookie, which determine if you are logged in or not.
<sessionState timeout="120" mode="StateServer" stateConnectionString="tcpip=loopback:42424" cookieless="false" />
The session timeout is for your session. The session expires in this example after 120 minutes of sliding expiration (i.e. 120 minutes of inactivity). When the session is lost, you can be logged in, it does not matter. These are two different things. So, to remember the session, you need to increase this value as well. If you want the session to stay for, let's say 2 weeks, increase this value to 20160. This can be a security risk, though.
Finally, you need to know that IIS (Internet Information Services) recycles the application pool, by default, if there is 20 minutes of idle time (see Application Pool's advanced settings). This means that the session that is stored InProc (default) is lost as well, and a new MachineKey is generated as well. Because of this, you might see errors like "ViewStateMac failed", because the MachineKey has changed. To prevent the session from being lost when the application pool recycles, you can use the StateServer (as above I did) and also set the MachineKey to a non-autogenerated value. These are security risks, though, as well. You can also increase the idle time and the recycle time of the application pool to prevent the recycling of application pools that have little traffic.
I hope this helps
- 11/23/2011
- Tommi Gustafsson
- 11/23/2011
- Tommi Gustafsson
.net 4.0 these examples do not remember.
Using membership,roles and personalization.
Login control remember me will set the cookie but not use it for a session.
There are thousands of people out there with the issue, examples all over the place which are essentially the same.
None work. My assumption is there is a config issue or bug.
Please advise,
DRE
- 8/18/2011
- ACdreos
Security Note