Having a bit of a problem. Using the ASP:Login control and a custom provider to authenticate against corp data. Problem is if the user selects to be remembered and returns to the site some time later there is no authentication or even validation in any way. What if that user has been deleted , disabled , or changed their password ? I can't believe this is an oversight in the Platform. Anyone have any clues what I'm missing ?

 Is there a way to force the control to authenticate ? or Detect an "Remebered Login" ?

 My other problem which is directly related to this is that at login I load a considerable amount of data about the users enviroment and settings ( I cannot use the ProfileProvider methodology since a user can have many profiles and select the desired one which is surprisingly missed in the framework )

Any assitance or advice would be greatly appreciated.

search on the web for SSO - single sign on ...

other option is that you keep information within clients cookie.

SSO is not appropriate for the solution.

 So this is an over sight in the ASP.NET infrastructure that you can still log on to a web site after your accont has been deleted ? Amazing.

 You could just read the cookies on the client and force a log out if you find the coookie that the provider uses to store the login information.

Thanks for your reply 

Not sure how that would alleviate the situation , we'd like to support the "remember me" paridigm and turn it on and off easily on a per client basis using the IDE ( this product currently needs to support over 100 clients each with customized versions which have become unwieldy ). 

I could do the entire login control and it's methdology in a day and not use the rich framework , but the point in using this rich set of tools is to get away from the grind of doing these type of things and focus on other busisness logic. The more we have commited to the framework the more work it seems we need to do to work around it's limitations and this one is particularly surprising as it poses a security risk to anyone using the control.

I'm still holding out that someone knows how to make this work correctly as I cannot believe such an oversite would make the framework at it's current age.

Is this what you are looking for?

Sub Load_login(ByVal sender As Object, ByVal e As System.EventArgs) Handles Login1.Load
'here you can read cookies and do other stuff for remembermefunctions..
End sub

Sub LoggedIn_login(ByVal sender As Object, ByVal e As System.EventArgs) Handles Login1.LoggedIn
'here you can set userprops after sucessful login
End sub

Sub Authenticate_LoggedIn(ByVal sender As Object, ByVal e As System.EventArgs) Handles Login1.Authenticate
'here you can do things on authentication
End sub


Sub LoginError_login(ByVal sender As Object, ByVal e As System.EventArgs) Handles Login1.LoginError
'here you can set errormessage or redirects to createpage and so on
End sub

evon:

Problem is if the user selects to be remembered and returns to the site some time later there is no authentication or even validation in any way. What if that user has been deleted , disabled , or changed their password ? I can't believe this is an oversight in the Platform. Anyone have any clues what I'm missing ?

Hi

You can check user information at Application_AuthenticateRequest event when he/she returns to your website and delete auth cookie use the following code

-----------------Global.asax---------------- 

      protected void Application_AuthenticateRequest(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;  

        HttpContext ctx = app.Context;
        if (ctx.User != null)
        {
            if (ctx.Request.IsAuthenticated == true)
            {
                System.Web.Security.FormsIdentity fi = (System.Web.Security.FormsIdentity)ctx.User.Identity;
                if (CheckUser_deleted_disabled_passwordChanged_otherCondition(fi.Name))
                {
                    System.Web.Security.FormsAuthentication.SignOut();  //sign out user
                    Response.Redirect("login.aspx");
                }
              
            }
        }
    }
    private Boolean CheckUser_deleted_disabled_passwordChanged_otherCondition(string username)
    {
        return true;  //please add customize logic

    }

Excellent exactly what I was looking for to work around this issue. 

Thanks Tons!!

Ok , perhaps I spoke to soon. Seems that the event is constantly called at every request ( sometimes many times per page request ) . To verify the user at every click would tax the system too much and I cannot access session state from this context to prevent it.

 Any ideas ?

Nevermind I found a solution. Just move the logic to the Session_Start. Methodology below in case it might help anyone or someone sees a reason why this would not work.

   if (Context.Request.IsAuthenticated == true)

       {

           VerifyUser(fi.Name)

      }