Impossible de définir FormsAuthenicationTicket.UserData en mode sans cookie

Question

J'essaie d'implémenter le " Écriture d'informations dans UserData " section de cet article , mais il ne fonctionne pas correctement lorsque le cookie fait partie de l'URI.

Mon code:

// Create the cookie that contains the forms authentication ticket
HttpCookie authCookie = FormsAuthentication.GetAuthCookie( userName, createPersistantCookie );

// Get the FormsAuthenticationTicket out of the encrypted cookie
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt( authCookie.Value );

// Create a new FormsAuthenticationTicket that includes our custom User Data
FormsAuthenticationTicket newTicket = new FormsAuthenticationTicket( ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, "foo");

// Update the authCookie's Value to use the encrypted version of newTicket
authCookie.Value = FormsAuthentication.Encrypt( newTicket );

// Manually add the authCookie to the Cookies collection
HttpContext.Current.Response.Cookies.Add( authCookie );

// Determine redirect URL and send user there
string redirUrl = FormsAuthentication.GetRedirectUrl( userName, createPersistantCookie );

HttpContext.Current.Response.Redirect( redirUrl, false );

Lorsque cookieless est utilisé, la page redirige mais ne récupère pas l'URI correct contenant les informations de cookie. Elle revient donc à la page de connexion où Request.IsAuthenticated renvoie false. Une boucle sans fin s'ensuit.

Comment puis-je rediriger vers l'URI approprié?

Answer 1

J’ai trouvé le problème intéressant, j’ai donc commencé à creuser, à tester et à déboguer un peu dans la source du framework .net.

En gros, ce que vous essayez de faire ne fonctionnera pas. Tout ce que vous mettez dans la collection Response.Cookies sera simplement ignoré si le navigateur ne prend pas en charge les cookies. Vous pouvez consulter Request.Browser.Cookies pour savoir si les cookies sont pris en charge.

Dans asp.net, l’état de la session et l’authentification prennent en charge le mode sans cookie, mais cela ne s’étend pas aux autres cookies. En fait, il semble que la session et l’authentification puissent être réglés sur différents modes de fonctionnement eux-mêmes.

Le système d'authentification peut stocker ses propres données dans l'URI, mais il le fait en manipulant directement l'URI lui-même. Malheureusement, Microsoft ne semble pas avoir exposé ces capacités à du code en dehors du module d'authentification.

En gros, si vous utilisez des méthodes telles que FormsAuthentication.GetAuthCookie () et FormsAuthentication.SetAuthCookie (), le système d'authentification se chargera de mettre ces informations dans l'URI pour vous automatiquement ... mais il ne vous le permet pas. fournissez un ticket d'authentification personnalisé à ces méthodes ... afin que vous soyez bloqué avec le ticket d'authentification par défaut. Dans ce cas, vous êtes le seul à pouvoir stocker les données personnalisées.

Quoi qu'il en soit ...

Il n’ya vraiment aucun avantage à stocker des données personnalisées directement dans un ticket d’authentification si le système d’authentification est devenu sans cookie ... en mode sans cookie, par exemple, "cookie persistant". de toute façon, vous régénérerez les données au moins une fois par session.

La suggestion la plus courante dans les cas où vous êtes sans cookie mais avez toujours besoin de données personnalisées, comme ceci, consiste à activer les sessions sans cookie et simplement stocker vos données personnalisées en tant que variable de session. L'ID de session sera placé dans l'URI, mais les données personnalisées resteront en mémoire sur le serveur. Le modèle d'utilisation est identique, que vos sessions soient sans cookie ou non.

Si vous le souhaitez vraiment, vous pouvez créer un système de stockage manuel des données personnalisées dans l’URI. La solution la plus simple consiste à placer les données personnalisées dans des chaînes de requête ou à utiliser pathdata. Je ne vois aucun avantage réel à cela par rapport aux variables de session, à moins que vous ne souhaitiez simplement pas utiliser la mémoire du serveur (ajouter un peu de mémoire à un serveur est une URL peu chère et mignonne et écrire manuellement du code pour y faire face ne coûte pas cher).

Answer 2

Merci pour cette excellente explication, Stephen. Dans les cas où l'utilisateur n'autorise pas les cookies, je vais simplement devoir éviter UserData et charger les données de la base de données.

Avant le code répertorié ci-dessus, je ferai:

if( !HttpContext.Current.Request.Browser.Cookies || !FormsAuthentication.CookiesSupported )
{
    FormsAuthentication.RedirectFromLoginPage( userName, false);
    return;
}