On Forums someone had issues with Login control, as he had custom authentication scheme in use and in Authenticate event handler, set a value to ViewState. And he had hard time figuring why the value wasn't there on next request when user was logged in (he checked it on the login page, e.g. didn't have a redirect page, right after authentication occurred). Something like:
'Aspx
<asp:Button ID="Button1" runat="server" OnClick="g" Text="Show view state"/><br />
viewstate: <asp:Label ID="v1" runat="server" /><br />
<div>
asp:Login ID="Login1" runat="server" OnAuthenticate="F"/>
'Code
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
'Test if postback occurs
Response.Write(IsPostBack)
End Sub
'Try to read from ViewState
Sub G(ByVal sender As Object, ByVal e As System.EventArgs)
v1.Text = ViewState("a")
End Sub
'Put something to ViewState
Sub F(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.AuthenticateEventArgs)
ViewState("a") = "test"
e.Authenticated = True
End Sub
Reason is that on successful login, Login control does a redirect to the specified target page, even if it's the same page the controls resides on. Postback does occur (Login control handles bubbled Command event coming from the logon Button) but during it in it's own internal AttemptLogin method, the control does a Response.Redirect after it has delegated a call to FormsAuthentication.SetAuthCookie. You can confirm this by checking what IsPostBack returns on Page_Load. It's false when you click ther Log-In button and True if you click Show ViewState button.
This is fine in practise for all scenarios, but might surprise you if you think you need ViewState during the logon process and expect Login control work in postbacking sense, so I thought to mention it here.
P.S when authentication fails, it does redirect only if you have set LoginFailure to RedirectToLoginPage
Share this post: email it! | bookmark it! | digg it! | reddit! | kick it! | live it!