Dit is een conceptuele vraag.
Ik heb een (mobiele) clienttoepassing die een inlogactie tegen een RESTful-webservice moet ondersteunen. Omdat de webservice REST is, komt dit erop neer dat de klant een gebruikersnaam/wachtwoord van de gebruiker accepteert, die gebruikersnaam/wachtwoord verifieert met de service en er vervolgens aan denkt om die gebruikersnaam/het wachtwoord te verzenden bij alle volgende verzoeken.
Alle andere reacties in deze webservice worden geleverd in JSON-indeling.
De vraag is of wanneer ik de webservice vraag om erachter te komen of een bepaalde gebruikersnaam/het wachtwoord geldig is, de webservice altijd moet reageren met JSON-gegevens om me te vertellen dat het een succes of niet-succesvol is, of moet HTTP 200 als goed worden geretourneerd inloggegevens en HTTP 401 op slechte inloggegevens.
De reden dat ik het vraag is dat sommige andere RESTful-services 401 gebruiken voor slechte inloggegevens, zelfs als je alleen maar vraagt of de inloggegevens geldig zijn. Ik heb echter begrepen dat 401-antwoorden een bron vertegenwoordigen waartoe u geen toegang zou moeten hebben zonder geldige inloggegevens. Maar de aanmeldingsbron MOET voor iedereen toegankelijk zijn, omdat het hele doel van de aanmeldingsbron is om u te vertellen of uw inloggegevens geldig zijn.
Anders gezegd, het lijkt mij dat een verzoek als:
myservice.com/this/is/a/user/action
moet 401 retourneren als er slechte referenties worden opgegeven. Maar een verzoek als:
myservice.com/are/these/credentials/valid
mag nooit 401 retourneren omdat die specifieke URL (verzoek) is geautoriseerd met of zonder geldige inloggegevens.
Ik zou hier op de een of andere manier graag een aantal gerechtvaardigde meningen over willen horen. Wat is de standaardmanier om hiermee om te gaan, en is de standaardmanier om dit logischerwijs passend te maken?
Antwoord 1, autoriteit 100%
Als eerste. 401 is de juiste antwoordcode om te verzenden wanneer een mislukte login heeft plaatsgevonden.
401 Ongeautoriseerd
Vergelijkbaar met 403 Forbidden, maar specifiek voor gebruik wanneer authenticatie vereist is en is mislukt of nog niet is verstrekt. Het antwoord moet een WWW-Authenticate header-veld bevatten dat een uitdaging bevat die van toepassing is op de gevraagde resource.
Uw verwarring over het feit dat myservice.com/are/these/credentials/valid401 terugstuurt wanneer u een controle uitvoert, is volgens mij gebaseerd op het feit dat het doen van booleaanse verzoeken in REST vaak is verkeerd door de RESTful-beperkingen. Elk verzoek moet een bron retourneren. Booleaanse vragen stellen in een RESTful-service is een gladde sloep naar RPC.
Nu weet ik niet hoe de diensten waar u naar keek zich gedragen. Maar een goede manier om dit op te lossen is om zoiets als een Account-object te hebben, dat je probeert te KRIJGEN. Als uw inloggegevens correct zijn, krijgt u het Account-object. Als u geen bandbreedte wilt verspillen om alleen maar een “controle” uit te voeren, kunt u een HEAD uitvoeren op dezelfde bron.
Een accountobject is ook een goede plek om al die vervelende booleaanse waarden op te slaan die anders lastig zouden zijn om afzonderlijke bronnen voor te maken.
Antwoord 2, autoriteit 22%
401 mag alleen worden verzonden als het verzoek een autorisatieheaderveld vereist en autorisatie mislukt. Aangezien de Login API geen autorisatie vereist, is 401 naar mijn mening de verkeerde foutcode
Volgens de standaard hier https://www.w3.org/Protocols /rfc2616/rfc2616-sec10.html
*10.4.2 401 Ongeautoriseerd
Het verzoek vereist gebruikersauthenticatie. Het antwoord moet een www-authenticate header veld bevatten (sectie 14.47) met een uitdaging die van toepassing is op de gevraagde hulpbron. De klant kan het verzoek met een geschikt autorisatiekopveld herhalen (sectie 14.8). Als het verzoek reeds autorisatie-inloggegevens omvat, geeft de 401-reactie aan dat de vergunning voor die inloggegevens is geweigerd. Indien de 401-respons dezelfde uitdaging bevat als voorafgaande respons, en de gebruikersagent al minstens één keer heeft geprobeerd, moet de gebruiker de entiteit worden gepresenteerd die in het antwoord is gegeven, aangezien die entiteit relevante diagnostische informatie kan omvatten. HTTP-toegangsverificatie wordt uitgelegd in “HTTP-authenticatie: Basic en Digest Access Authentication” [43]. *
Antwoord 3
Als de 401-responscode misleidend is voor gebruikersauthenticatie, kan de API de HTTP-statuscode 200 OK verzenden voor zowel succesvolle als mislukte authenticatie, maar stel een aangepaste koptekst in op het succesvolle reactie van de authenticatie en laat deze header op mislukte aanmeldingen weg.
De client kan controleren of de koptekst of niet bestaat en beslist de actie.
Voorbeeld: SpringBoot API-reactie
De oproep naar OK wanneer aanmelding succesvol is, stelt de kop “GOTYOUIN” in met een waarde (alles). Oproep tot mislukt voegt de koptekst niet toe en de client kan dit behandelen als een mislukte inlogpoging.
public class LoginResponseEntityHelper {
public static ResponseEntity<?> ok(String token) {
return ResponseEntity.status(HttpStatus.OK).header("gotyouin", token).body(null);
}
public static ResponseEntity<?> failed() {
return ResponseEntity.status(HttpStatus.OK).body(null);
}}
Antwoord 4
Retourneer 409 met een goed foutmelding.