Utilizzo delle richieste POST come GET

0

Sto costruendo un'applicazione web con NodeJs e Angular.

Ora ho una configurazione di routing con Angular e un'API con NodeJs in modo che Angular possa comunicare con NodeJ.

Ma quando imposto GET route in NodeJs. "Sovrascrivono" i percorsi da Angular o mostrano dati semplici.

Ad esempio:

In NodeJs ho un GET / autorizzato che controlla semplicemente se l'utente è autorizzato, quindi invia un vero o falso indietro. Ora sui miei percorsi angolari protetti sto usando una risoluzione che esegue un GET sul percorso / autorizzato e se restituisce true l'utente riceve l'accesso alla pagina.

Ma il problema è che se l'utente visita www.example.com/authorized. Restituirà una pagina bianca con "True" o "False". Ora questo non è necessariamente un problema di sicurezza, ma non sembra molto bello. Inoltre, non voglio che gli utenti abbiano accesso a tali chiamate API.

La mia soluzione consiste nel rendere la route una chiamata POST, ma non penso che sia il modo corretto.

Quindi la mia domanda è:

  • Come faresti questo?
  • Ci sono degli svantaggi nel rendere tutto un POST (anche quando non stai pubblicando alcun dato)
posta Soundwave 10.05.2017 - 16:49
fonte

2 risposte

0

Risposta in due parti: Pensieri generali e una risposta reale di seguito:

Pensieri generali

Dal contesto dell'applicazione generale, penso che dovresti specificamente non provare a fare ciò che stai chiedendo come fare. Una regola generale in cui vivo è che gli endpoint API devono sempre restituire una risposta API appropriata.

Ad esempio, la risposta di Marstato porterà certamente a ciò che stai cercando di fare, ma ci sono alcuni aspetti negativi non intenzionali che possono causare problemi lungo la strada. Principalmente, il tuo accept-header ora agisce efficacemente come parametro di routing. Cosa succede se rimuovi accidentalmente l'intestazione dalla tua richiesta in angolare in fondo alla strada? Cosa succede se un altro sviluppatore si unisce e tenta di implementare la chiamata API senza rendersi conto dell'importanza dell'intestazione di accettazione? In entrambi i casi il risultato sarà lo stesso: non riceveranno un vero o un falso, ma torneranno invece qualcos'altro. E questo sarà molto confuso.

Ancora una volta, ci sono sicuramente dei modi per fare ciò che vuoi fare, ma penso che la vera risposta sia che non dovresti davvero provare a farlo. Gli endpoint API sono solo per gli sviluppatori e qualsiasi risposta che possa potenzialmente confondere gli sviluppatori è una risposta errata e non dovrebbe essere restituita da un endpoint API.

Sì, gli utenti del tuo sito possono accedere all'URL in questione e visualizzare uno schermo bianco con "false". Tuttavia, gli endpoint dell'API dovrebbero essere raggruppati e invisibili all'utente finale, quindi non c'è davvero alcun motivo per cui qualcuno dovrebbe finire su example.com/authorized per vedere quella schermata. Separare chiaramente le tue chiamate API (ad es. Api.example.com/authorized o example.com/api/authorized) è un buon modo per ridurre al minimo le probabilità che qualcuno inciampi accidentalmente sui propri URL API, rendendo anche il sistema un po 'più organizzato.

Quindi la mia risposta generale è che la probabilità e il danno di qualcuno che inciampa accidentalmente nei propri URL API è (o dovrebbe essere) abbastanza bassa da non meritare la logica aggiuntiva nelle chiamate API, specialmente da una risposta non standard dall'API potresti confondere te stesso o altri sviluppatori lungo la strada.

Risposta effettiva

Se davvero vuoi farlo, un altro modo per farlo sarebbe quello di verificare la mancanza di credenziali di accesso. Presumibilmente la tua chiamata API è più di una semplice richiesta GET? La chiamata API restituisce vero / falso a seconda che l'utente sia autorizzato o meno, corretto? Ciò significa che la chiamata API sa quale utente è autorizzato, il che significa che le credenziali dell'utente stanno arrivando nella richiesta. Poiché stai facendo una richiesta GET, significa che le credenziali sono nell'intestazione, in un cookie o nei parametri URL. I cookie non dovrebbero essere usati per le chiamate API, quindi la migliore ipotesi è che le credenziali dell'utente siano nell'intestazione HTTP in qualche modo. Tuttavia, se un utente accede semplicemente a example.com/authorize nel proprio browser, tali credenziali non saranno presenti. Di conseguenza, si può semplicemente presumere che venga utilizzato un browser se nell'intestazione HTTP non sono presenti assolutamente credenziali utente e, in caso contrario, restituire una normale chiamata API se sono presenti credenziali. Lo stesso vale anche se si accettano le credenziali dell'utente nei parametri URL (anche se sarebbe strano).

    
risposta data 10.05.2017 - 17:48
fonte
2

Rendere tutto un tipo POST di funziona , ma come dici tu, non è di gran lunga il modo corretto.

Vedo due soluzioni:

  1. Non dichiarare percorsi in conflitto. Periodo.
  2. Utilizza la negoziazione del contenuto HTTP: I browser invieranno un Accept -Header contenente text/html . Se questo è presente, invia l'intera applicazione HTML. In angolare, invia application/json (o qualsiasi altra cosa tu codifichi i tuoi dati con per il trasporto http) nell'intestazione Accept . Rileva questo nel tuo server Node e invia i dati non elaborati.
risposta data 10.05.2017 - 17:01
fonte

Leggi altre domande sui tag