2013-02-19 14 views
5

Sto scrivendo un servizio di verifica password utilizzando ASP.NET Web Api.RESTful Verifica servizio password

Il servizio accetta una password per l'utente attualmente connesso, lo verifica e restituisce un valore codificato. Questo succede tutto su SSL.

La chiamata a questo metodo non modifica lo stato.

Inizialmente sembra che dovrebbe essere una richiesta GET tuttavia su un'ulteriore ispezione sono preoccupato per il server Web che registra le password di testo normale.

Potremmo implementarlo come POST ma sembra che il verbo sbagliato abbia dato l'azione.

Si tratta semplicemente di un caso di pragmatismo sulla procedura o c'è altro che possiamo fare per soddisfare entrambi i casi pragmatici e RESTful?

risposta

1

È necessario utilizzare Basic Authentication dove si passa il nome utente/password come intestazioni. Anche questo si adatta meglio come lo standard già definito.

Esiste già un codice javascript per eseguire la codifica in base64, se è necessario farlo sul browser.


se si sta facendo questo per autenticare e il valore codificato è il token di accesso (cookie), è meglio utilizzare OAuth 2.0.

+0

Grazie Aliostad. Guardando i dettagli di base di Auth non è proprio quello di cui abbiamo bisogno (la lista degli svantaggi in particolare). In realtà non stiamo firmando l'utente, stiamo semplicemente controllando se l'utente che ha effettuato l'accesso conosce la propria password (una barriera per la password quando si modificano alcune impostazioni). –

0

Se la chiamata API invia una risposta che non è una risorsa di per sé (non implica una risorsa restituita da un archivio dati), è necessario utilizzare verbi e non nomi.

Si può avere un controller UserPasswordsController che espone un metodo di azione in questo modo:

[HttpPost()] 
public HttpResponseMessage Validate() 
{ 
    if (!this.Request.Content.IsFormUrlEncodedContent()) 
    { 
     return this.Request.CreateErrorResponse(
      HttpStatusCode.BadRequest, 
      "Body of request must be form URL encoded." 
     ); 
    } 

    var parameters = this.Request.Content.ReadAsFormDataAsync().Result; 

    var userName = parameters["userName"]; 
    var password = parameters["password"]; 

    // TODO: Validate user name and password 
    var isValid = true; 

    if(!isValid) 
    { 
     return this.Request.CreateErrorResponse(
      HttpStatusCode.Forbidden, 
      String.Format(null, "The password provided for {0} is not valid.", userName) 
     ); 
    } 

    return this.Request.CreateResponse(HttpStatusCode.OK); 
} 

E hanno un percorso registrato come questo:

routes.MapHttpRoute(
    name:   "UserPasswords", 
    routeTemplate: "api/v1/validate", 
    defaults:  new { controller = "userpasswords" } 
); 

Si potrebbe POST forme dati al punto finale di convalida che contiene il nome utente e la password che si desidera convalidare. Uno stato di stato Proibito indica che la password non è valida, mentre lo stato di OK viene restituito se la password è valida.

Se siete nuovi a lavorare sulle interfacce REST e volete adottare un approccio pragmatico, consiglio vivamente di dare un'occhiata a Web API Design - Crafting Interfaces that Developers Love.

Problemi correlati