227 messaggi dal 08 marzo 2012
teo prome ha scritto:
dai normali http header posso solo cercare dei dati raggruppabili ma nessuna certezza sull'univocità; provo a rigirare il problema, se qualcuno si connette alla mia api privata che rilascia dati è perché ottiene un token, escludendo il furto quel token lo ottiene da un mio qualche servizio cui può accedere quando paga l'accesso all'api dati, a meno che non pubblico ufficialmente i metodi che utilizzo per creare il token, ma allora qui sto sbagliando io.

A questo punto posso fornire un codice univoco a chi ha comprato il servizio e dirgli di allegarlo alle richieste verso la mia api dati come header specifico; in questo modo almeno riconosco il cliente. A livello commerciale venderò dei pacchetti di richieste, supponiamo 200r/gg, che il mio cliente utilizzi postman o altro poco importa, ha comprato un servizio, se il collegamento all'api dati avviene tramite un suo sito web però posso accorgermene dall'Origin, X-Forwarded, ecc. corretto?

Se poi il mio scopo è fornire dati diversi a seconda che sia un'app o un sito, mi sembra fosse un altro problema indicato nel thread, con quanto sopra dovrei già essere in grado di capire --> sitoWeb cliente.com/altro; l'alternativa è mettere su due servizi api diversi e lasciare all'utilizzatore la decisione su quale utilizzare.
Modificato da teo prome il 24 aprile 2020 09:12 -


Condivido, il problema è se chiami il servizio da un Javascript?
La tua API KEY è visibile da chiunque ispezioni il codice sul browser e l'IP non è quello della macchina server mal client (browser) che effettua la richiesta.

Quindi potenzialmente se lo usi su un JS divulghi un token che ho rilasciato solo a te...non so se mi spiego.

Non credo però che da qui se ne venga fuori...o sbaglio?
694 messaggi dal 13 novembre 2008
Contributi
problema IP:
infatti non parlo di IP, diciamo che proprio non mi interessa e non mi è utile; il concetto è che un sito web di un cliente che usa le mie api perché gli concedo la possibilità di avere un token (ha pagato il servizio) e gli do un codice univoco da allegare alla richiesta = so chi sei dal tuo dominio + hai un token valido + hai un codice univoco --> ti puoi connettere e nella mia tabella sei CLIENTE1
un app qualsiasi dello stesso cliente che usa le mie api perché gli concedo la possibilità di avere un token (ha pagato il servizio) e gli do un codice univoco da allegare alla richiesta = so chi sei dal codice univoco + hai un token valido --> ti puoi connettere e nella mia tabella sei CLIENTE1

problema token e codice univoco:
il codice univoco sarà per esempio qualcosa generato a partire da una chiave fornita al cliente (che non la invierà ovviamente con la richiesta), potrà essere usato 1 volta per richiesta; non è tanto distante dal metodo con cui tiri fuori un token, solo che ha uno scopo diverso, identificare il cliente. Sarà compito del cliente che fa l'app implementarlo in base a delle specifiche.

il token di accesso api avrà anch'esso una scadenza a breve rinnovabile tramite la logica token-->richieste-->scadenza token-->refresh token-->nuovo token

certo che tutto i token sono intercettabili, proprio per questo si impostano scadenze brevi o monouso... ma perché un cookie di autenticazione non è intercettabile secondo te?

il problema lo puoi risolvere in questo modo (è un esempio, non è il Modo), certo devi fare un po' lavoro che non è banalmente recuperare un ip.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.