L'ID dovrebbe essere indicato nell'URL se già protetto con ID JWT?

Question

L'ID dovrebbe essere indicato nell'URL se già protetto con ID JWT?

#1 da (4 voti)
#2 da (3 voti)

3

Dire che ho gli endpoint:

/users

e

/users/<id>

Se volevo CANCELLARE un utente autenticato con un token JWT che contiene l'oggetto utente, se questo ELIMINA gestito dovesse andare sotto /users o /users/<id> ?

È ragionevole avere sotto l'endpoint /users/<id> mentre stai eliminando quell'elemento specifico.

Ma ha anche senso averlo sotto /users come allora non hai dati ridondanti e non devi inserire <id> ogni volta che vuoi eseguire una funzione sul tuo utente quando hai già l'autenticazione JWT.

Questa idea ricade anche su oggetti molti-a-molti, dire che volevo accedere a /users/<id>/games/<id>/move stripping ' /users/<id> ' fa sembrare che non ci sia una risorsa 'utente' ma rende meno grossa e di nuovo meno ridondanza dei dati .

Quale è più "accettato" o "giusto"? Grazie:)

rest resources jwt url

posta Skidushe 08.12.2017 - 17:40

fonte

2 risposte

3

Penso che tu stia confondendo il concetto dell'id dell'utente che è autenticato e l'id dell'utente che vuoi eliminare. Potrei sbagliarmi ma è un po 'oscuro quando un utente si cancellerebbe e cosa significherebbe. Penso che l'utente venga eliminato e l'utente autenticato in genere sarebbe diverso.

Per la seconda parte della domanda, non penso che abbia senso rendere i giochi una risorsa secondaria per l'utente. I giochi sono una risorsa in cui ognuno ha il proprio ID. Quale utente (o utente) possiede il gioco o ha accesso ad esso è un attributo di quella risorsa di gioco. Puoi utilizzare l'utente autenticato e il loro ruolo per determinare se hanno accesso a un determinato gioco. Dovresti fare qualcosa del genere: /users/<id>/games per fornire un elenco di URL per i giochi a cui l'utente è associato.

risposta data 08.12.2017 - 18:13

fonte

Leggi altre domande sui tag rest resources jwt url

Esiste un motivo valido per separare le aspettative dai test? Il livello del dominio dovrebbe dipendere da NHibernate?

score 4 · Accepted Answer

Se lo scopo di questo endpoint è eseguire un'operazione su "utente corrente" come definito dall'utente nel token JWT, allora non vuoi l'utente ID nell'URL.

Non vuoi che qualcuno modifichi maliziosamente l'URL per eseguire un'azione su un utente diverso dal proprio, e usare implicitamente il token JWT affinché l'utente possa operare è un ottimo modo per assicurarsi che nessuno stia tentando di il tuo sistema per fare qualcosa che non dovrebbero essere in grado di fare.

Laiv mostra un buon punto nel suo commento sulla domanda:

For refering the user authenticated /me. Looks to me less complicated. It's a very common alias and more intuitive than the cannonical uri (/users/id/). The action would be DELETE /me HTTP/1.1

Assegna un nome al tuo endpoint in modo che i client del tuo servizio sappiano che stanno eseguendo un'operazione sul proprio utente:

HTTP/1.1 DELETE /users/me

Questo dice ai clienti "hey, sto facendo qualcosa a me stesso" e li impedisco di fare accidentalmente qualcosa che non dovrebbero, attraverso l'identificazione dell'ID nell'URL.