"Gem login" ved Forms Authentication

Jeg synes egentlig at det plejer at fungere fint nok med at blive logget ind automatisk hvis man angiver persistant cookie...
Det er denne her metode du mener ikke ?

FormsAuthentication.RedirectFromLoginPage Method (String, Boolean) 
Platforms: Windows 2000, Windows XP Professional, Windows Server 2003 family
Language C#

public static void RedirectFromLoginPage(
  string userName,
  bool createPersistentCookie
);


Parameters
userName
Name of the user for cookie authentication purposes. This does not need to map to an account name and will be used by URL Authorization.
createPersistentCookie
Specifies whether or not a durable cookie (one that is saved across browser sessions) should be issued.

Remarks
The RedirectFromLoginPage method redirects to the return URL key specified in the query string. For example, in the URL http://www.contoso.com/login.aspx?ReturnUrl=caller.aspx, caller.aspx is the return URL that RedirectFromLoginPage redirects to. If the return key does not exist, RedirectFromLoginPage redirects to Default.aspx. ASP.NET automatically adds the return URL when the browser is redirected to the login page specified in the loginUrl attribute in the <forms> Element configuration directive. The method issues an authentication ticket and does a SetForms with the ticket, using the appropriately configured cookie name for the application as part of the redirect response.

(det var bare et dump fra docs)

Well, her virker det ikke :(
Poster lige lidt kode der måske kan afsløre hvad jeg gør galt.
Det er sådan set bare lavet ud fra en "Patterns and practices" på MSDN...
Som det fremgår er det checkboxen 'chkPersistent' der afgør om login skal gemmes.


// Create the authentication ticket
FormsAuthenticationTicket authTicket =
    new FormsAuthenticationTicket(
    1,                // version
    userID,                // user name
    DateTime.Now,            // creation
    DateTime.Now.AddYears(50),    // Expiration
    chkPersistent.Checked,        // Persistent
    String.Join("|", userRoles));    // User data

// Now encrypt the ticket.
string encryptedTicket = FormsAuthentication.Encrypt(authTicket);

// Create a cookie and add the encrypted ticket to the cookie as data.
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);

// Add the cookie to the outgoing cookies collection.
Response.Cookies.Add(authCookie);

// Save the login information
_Content.Users._Data.SaveLoginInformation(userID);

// Redirect the user to the originally requested page
Response.Redirect(FormsAuthentication.GetRedirectUrl(
    txtEmail.Text,
    chkPersistent.Checked ));

Jeg "plejer" (laver normalt intranetnetpps->windowsauthentication) :

// handler til noget logon-knap-klik-event
if (FormsAuthentication.Authenticate(txtUser.Text, txtPwd.Text))
{
  FormsAuthentication.RedirectFromLoginPage(txtUser.Value, false);
}
else
{
  // en eller anden fejlmeddelelse til brugeren
}

Den fikser det hele i et huk... og denne her :

if (FormsAuthentication.Authenticate(txtUser.Text, txtPwd.Text))

Kan du så udskifte med et kald til noget custom-validering...

du kan f.eks. se denne :
http://aspalliance.com/499

Hov... for persistant cookie er det de så :
FormsAuthentication.RedirectFromLoginPage(txtUser.Value, true);

RedirectFromLoginPage giver bare ikke mulighed for at definere roller så vidt jeg kan se... =\

Prøv at kig denne her igennem (hvis du ikke har set den før) :
http://aspnet.4guysfromrolla.com/articles/082703-1.aspx

som artiklen handler om, så skal du ikke assigne roller på din login-side men i AuthenticateRequest-eventen i din application

jep, tak for hjælpen.
er jeg til gengæld hel gal på den hvis jeg siger at AuthenticateRequest kører for hvert eneste request ?
ikke at det give nogen nævneværdig performance forskel, men det virker umiddelbart overflødigt at spørge databasen om brugerens roller hvad hvert request...

skriv et svar for points, snepnet :o)

det skal du få :o)

og jeg kan godt forstå at du synes det er lidt ineffektivt at der bliver slået op i basen hver gang.
det er heller ikke unormalt, at du sørger for at lægger lidt i session omkring den slags, men da det ikke umiddelbart muligt på det trin i page-lifecyle'n, kan du være nødt til enten at lave andre fiksfakserier, eller acceptere det (sansynligvis vis ikke særlig voldsomme) performancehit....

der er flere muligheder for at gøre noget ved det, så du kan jo lige sige til hvis det bliver et problem.

mvh

det bliver helt sikkert ikke noget problem ... ville bare lige høre om du kendte et enkelt workaround :o)