2010-09-30 5 views
2

J'ai un site Web asp.net mvc existant qui utilise l'authentification de base des formulaires. Le site dispose d'une page de connexion qui renvoie à une action de connexion, qui enregistre l'utilisateur via FormsAuthentication.SetAuthCookie(). Je cherche à ajouter une API sur le site, en tant que zone mvc2, où les utilisateurs seraient authentifiés sur la base d'un jeton passé comme un en-tête http. Cette zone ne comportera que des actions json, rediriger l'utilisateur vers une page de connexion n'a donc aucun sens. Au lieu de cela, je veux que les utilisateurs passent juste un jeton avec chaque demande. Ce jeton est mappé à chaque compte d'utilisateur et l'utilisateur serait automatiquement authentifié. Je suis aux prises avec l'endroit où mettre cette logique. À ce stade, le meilleur choix semble être d'ajouter la logique de recherche d'en-tête et l'authentification à Global.asax dans la méthode Application_AuthenticateRequest. Je veux éviter d'avoir besoin de rediriger l'utilisateur après avoir appelé FormsAuthentication.SetAuthCookie(), cependant. Je veux que l'action de connexion soit transparente pour eux.Ajouter par demande, authentification par jeton au site mvc asp.net

Est-ce que je m'approche de la mauvaise façon?

En remarque: il n'est pas possible d'exiger un nom d'utilisateur/mot de passe pour les demandes d'API, car le site compte plusieurs utilisateurs. Certains se sont connectés en utilisant OpenID alors que le reste s'est joint à un nom d'utilisateur/mot de passe.

Répondre

4

Nous sommes allés sur le chemin de l'ajout de la recherche d'en-tête à l'événement Application_AuthenticateRequest dans Global.asax. Le code ressemble à quelque chose comme:

private const string AuthorizationHeader = "Authorization"; 

if (!string.IsNullOrWhiteSpace(request.Headers[AuthorizationHeader])) 
{ 
    try 
    { 
    // Remove Basic from beginning and then decode the string 
    var token = request.Headers[AuthorizationHeader].Substring(6); 
    token = new ASCIIEncoding().GetString(Convert.FromBase64String(token)).Split(':')[0]; 

    return UserService.FetchByApiToken(token); 
    } 
    catch 
    { 
    } 
} 
1
+3

Malheureusement, je n'utilise pas WCF et pour être honnête ... Je ne veux pas. Cela ressemble à un gâchis trop architecturé qui sera probablement remplacé par quelque chose d'autre dans 1-2 ans ... Le site n'est pas une entreprise et ne nécessite pas ce niveau de complexité –

+0

Oh, je te sens à 100% comme je suis dedans la profondeur de l'un de ces projets d'entreprise. Mais l'histoire des services de repos WCF est assez propre. Je regardais la trousse de départ avant de porter un jugement. –

+1

L'API Web est la nouvelle façon de faire des services REST. On dirait que WCF a été dépassé comme prévu. Bien sur-architecturé pour le domaine du problème en effet (pour ne pas dire qu'il n'a pas ses scénarios très valides). :) – Marchy

Questions connexes