login problems after upgrade

after upgrade from episerver 4.41 to 4.61. Normal user account with read access to pages cant login. I have custome login code which works without any problems. user gets authenticated and do have UnifiedPricipal set from login page. but problem appear when user is redirected from login page to portal page after authentication. it seems like all http context is cleared after redirect and user is not reconized as authenticated anymore. And therefor gets redirected to ordinary episerver login page instead of portal page. i also tried to redirect to a simple page which only outputs EPiServer.Security.UnifiedPrincipal.Current property, and it returned AnonymousUser. I compared access right on all pages against the old episerver and its exactly the same. i also tried to give "everyone" user group full access right to all pages but it didnt help. Im using a webservice for authentication which is still on old episerver platform on different machine, but this webservice is only used to authenticate user from login page. And since i do get autheticated on login page, i dont think this have anything to say. Im totaly stucked, can anyone plzz help me solve this (PIIIIIPP) problem. We do not have multi spiserver enviroment in our office, episerver is installed on one local machine with local sql server. NB ! Everything works fine on my old episerver 4.41
Mar 25, 2008 18:35
I don't think I've got the solution for you, but I'll try to give you some trouble shooting tips and some background information about the process. Login in EPiServer using FORMS authentication uses a cookie to store information about the logged in user. When you log in using the /util/login.aspx page, EPiServer will authenticate the user by invoking the authentication handler chain (by calling AuthenticationProvider.Authenticate). This is done in the EPiServer.Util.LoginBase.HandleLogin() method. Now, if the user was recognized, the authentication cookie (called a ticket) will be written to the response, along with a redirect request. At this time, in the log in button click, the user has been authenticated, but not the request. An authenticated request is indicated by the HttpContext.Current.User beeing set to an authenticated user. This is the same as the user you'll get in the Page.User property, or UnifiedPrincipal.Current (also exposed by PageBase.CurrentUser). I've seen lots of cases where people get confused when the authentication succeeds in their custom "on-page" login controls. This is of course because the click event of a log in button happens very late in the page event cycle, while the authentication and authorization is done very early. In fact, all menus and lists will have already been fetched in the context of the anonymous user. The next request will be in the context of the authenticated user, which is why a log in should always be followed by a redirect. As you wrote, the user is beeing authenticated on the login page, so the error must be somewhere after that phase. The HttpContext is cleared after each request, which is the general point of having it there. And a new one is created at each new request. In the Authenticate event of the request EPiServer will check for that cookie I mentioned earlier (the ticket), and re-authenticate the user, setting the HttpContext.Current.User to be an authenticated user in a UnifiedPrincipal object. So, if the authenticaton succeeds, but the next request is still anonymous we're left with to probable scenarios: 1. The client has not accepted the authentication cookie (the ticket). This could happen if you change the host (the complete web address is used, not just the domain part) in the redirect, or the client does not accept cookies at all. A little known issue about IE is that it will not accept cookies if your host name includes an underscore character. 2. The authenticaton event handler has failed to register. This can happen if you get an exception during application start-up (which is when EPiServer registers this and lots of other stuff). You should not be able to log in at all on your site if this happens. I've seen this with invalid enterprise lisence files. Also make sure you have a global.asax in your root directory. You could also try to use Fiddler ( www.fiddlertool.com ) to see if the server actually sends the cookie back to the browser - it is called .EPiServerLogin - with a long seemingly base64 encoded string. If that cookie is not present, you have a problem on the server, not the client. Other things you can do to pinpoint the problem is to test the following: * Log in using another browser than IE * Verify that you can log in to admin/edit. This indicates that you have an authorization issue, not an authentication issue. * Enable log4net with DEBUG level to see if you get any errors during start-up and/or during authentication. * Read the Configurable Authentication Chain tech note, and disable the authentication handlers that you know should not be used, to make sure the problem is not somewhere else. If you find the problem, please share the solution with the rest of us :-) Happy hunting! /Steve
Mar 25, 2008 18:46
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.