You can create a custom control with two textboxes, one checkbox and one button. In the Click event of the button, do like example below: private void LoginButton_Click(object sender, System.EventArgs e) { // Send login request to EPiServer EPiServer.Util.LoginBase.HandleFormsLogin(Username.Text, Password.Text, this.PersistCookie.Checked); //Todo: Perform redirect or other custom actions } Regards, Micke

Ok I'll try that - what is the login.aspx page all about then? /John

As far is i know there is no actual difference in how login is performed, it's just two ways to solve the same problem. But i might be wrong. In the current solution i'm developing i use the both methods and the both works fine. /Micke

You need the login.aspx for asp.net authorization and authentication. There is a reference to util/login.aspx in web.config. All 401 Access Denied requests are automatically redirected to the login.aspx page by the ASP.NET Forms Authentication HttpModule. When you include your own login dialog in a custom page (or all pages as someone do) you only handle logons initiated by the user (by entering the username and password.) Logon.aspx handles all logons initiated by Access Denied errors, not the user. So, you need login.aspx. As a side note, do not change /util/login.aspx, there is a copy of it in /templates which you can change instead. You need to point to your copy in web.config, but thats it. /Steve

Do I understand you right? 1. Dont touch /Util/login.aspx - web.config points to it - right? 2. /templates/login.aspx - same as Util but not used unless you want to change the standard one to be your own - you would then have to point your web.config at that one instead of /util? I tried changing /templates/login.aspx to a user control but ran into problems... What I really should do is forget /templates/login.aspx and do what was first suggested...right?

Correct. If you do not want to change the UI of the logon dialog, you can forget about login.aspx altogether (it still needs to be there, but not for you custom login control.) The reason you should NOT change /util/login.asxp is not because web.config points to it. The reason is that you are not allowed to change anything inside /util /edit or /admin. Steve

>> Perform redirect or other custom actions Is it right to use if (Page.User.Identity.IsAuthenticated) to decide whether to redirect or not? If I use this line its as if it takes too long and the result is false even if I put the correct user/pass in. On next page reload I am authenticated so the same code will return true. Is there a better way? Same result if I use this code too: UnifiedPrincipal.Current.Identity.IsAuthenticated

Unfortunately, the HandleFormsLogin only returns the redirect-url after a successful login, not the authenticated user object. Page.User will still seem to be unauthenticated - even after a successfull call to HandleFormsLogin. You need to do the redirect, as all the neccessary user objects are set up on page initalization. So, you know the user has been logged on if HandleFormsLogin returns a non-null string, but you do not know who the user is. There are ways to get around this, without redirecting, but it means you have to do another login, and, all lists etc. on the page will not reflect the fact that you are now logged in, and thus might hide information from you. /Steve

Well I've devloped a similar solution where the customer needed to log every login made. Though true the HandleFormsLogin only return the redirect-url it's still simple to get the user: Simply check if HandleFormsLogin != null, and if it is the user is authenticated, this means that the Username textbox control hold's the login name of the authenticated user.. Might be a late answer but maybe someone else may benefit from it. //Joakim