Hai essenzialmente due modi per farlo.
Chiamare un'API
Quando l'utente dichiara di aver terminato le attività sul sito di terze parti, chiama l'API di questo sito, chiedendo di confermare che le attività erano già state eseguite. Se assumiamo che ti fidi della terza parte e del canale tra te e il server di terze parti, questo ti garantisce che l'utente abbia effettivamente eseguito le attività richieste.
Possibili problemi:
Esempio:
Immagina di dover archiviare un determinato file su Google Drive, con un nome specifico. Una volta che l'utente ha terminato l'operazione, torna al tuo sito / applicazione mobile. Il tuo sito / applicazione mobile può quindi utilizzare OAuth per abbinare l'account di Google all'utente e, in base a specifica autorizzazione, accedere al file in Google Drive o almeno verificare che il file esista.
Fidato dell'utente
Se non è possibile fare la prima alternativa, devi fidarti dell'utente quando dice che ha effettivamente eseguito le attività.
Non devi necessariamente chiedere all'utente se ha svolto i compiti, con un'opzione sì / no; invece, puoi effettivamente controllare il contenuto di <iframe> o controllare gli URL che sono stati utilizzati dal <iframe> (forse link significa che l'utente ha completato l'attività, mentre il link indica che l'utente non è riuscito?)
Il punto è che, non appena esegui questi controlli su lato client , sei condannato. In realtà stai facendo affidamento sul cliente per dirti la verità. Puoi rendere facile l'imbroglio del cliente, dando un'opzione sì / no all'interno di un modulo, o potresti renderlo difficile, offuscando un pezzo di codice JavaScript che farebbe un po 'di magia nera con <iframe> ; tuttavia, non appena il codice viene eseguito sul lato client, può essere manomesso (e lo farà, se ci sono dei vantaggi)
Se sei sicuro di poterti fidare dei tuoi utenti, puoi affrontare gli aspetti tecnici attuali tramite StackOverflow. Se riesci a far cambiare la pagina a terzi, la messaggistica su più documenti sarebbe la più semplice e diretta soluzione qui (essendo anche relativamente facile da manomettere per un utente che vuole imbrogliare).
Naturalmente, se si ha un effetto leva sulla terza parte, è possibile sviluppare una soluzione insieme, che utilizza anche una coppia di chiavi privata-pubblica per crittografare i dati che passano attraverso l'utente. L'utente diventa semplicemente un trasportatore di dati e non può manometterlo. Detto questo, se hai questo tipo di potere sulla terza parte, perché non chiedi loro di fare un'API?
Possibili problemi:
-
L'utente può affermare di aver svolto i compiti, anche se non l'ha fatto. Non c'è nulla che tu possa fare per impedire completamente di imbrogliare qui (a meno che tu non possa scambiare un paio di chiavi con la terza parte).
-
Le soluzioni più semplici richiedono di modificare il sito Web di terze parti; se hai questo tipo di potere, potresti semplicemente chiedere alla terza parte di sviluppare un'API?
Esempio:
Prima di eseguire qualcosa sul tuo sito, l'utente deve fare alcune domande. Esiste un servizio di terze parti: un sito che ospita domande e raccoglie risposte dagli utenti (e verifica che le risposte siano corrette).
Si inizia generando un UID che si cripta con una chiave pubblica precedentemente fornita dalla terza parte. Quindi, reindirizza l'utente al sito di terze parti, specificando l'UID crittografato nell'URI; l'utente non può leggere l'UID, perché non ha la chiave privata.
Una volta che l'utente risponde alle domande, il sito di terze parti reindirizza l'utente al tuo sito e aggiunge all'URI alcuni dati che contengono l'UID, nonché lo stato di successo / errore, crittografato con la seconda chiave pubblica , quello che hai precedentemente fornito a terze parti. Una volta ricevuti questi dati, puoi essere certo che l'utente non l'abbia manomesso, anche se conoscesse entrambe le chiavi pubbliche: poiché l'utente non poteva conoscere l'UID originale, la presenza dell'UID autentico assicura che il messaggio fosse crittografato dalla terza parte.
Come puoi vedere, non c'è nulla di particolarmente complicato per qualcuno che abbia familiarità con la crittografia, e ci sono molti rischi per fallire per qualcuno che non lo è. Ancora una volta, una semplice API è un approccio molto più diretto.