È possibile inviare un link di accesso via email tramite API?

Supporto
1

Ciao! Sto davvero apprezzando l’utilizzo della API di Discourse!

Seguendo la guida sul reverse engineering della API, ho riscontrato un problema nel far sì che la API invii un link di accesso.

Contesto del perché sto facendo questo
Ho creato un servizio SSO per un hackerspace locale, in modo che gli utenti possano accedere al nostro Discourse tramite il sistema di gestione delle iscrizioni dell’hackerspace.

Tuttavia, alcune persone potrebbero aver utilizzato un indirizzo email diverso nel sistema di iscrizioni rispetto a quello usato su Discourse. Poiché l’accesso locale è disabilitato quando SSO è attivo, vorrei che gli utenti potessero cliccare su “Inviami un link di accesso via email” per accedere e poi aggiornare il proprio indirizzo email se lo desiderano (oppure continuare a usare il link di accesso, come preferiscono).

Obiettivo
Vorrei inviare un link di accesso all’utente @ domain .co.uk tramite la API.

Ho provato questo:

curl -X POST "https://discourse.<site>.org.uk/u/email-login" --data "{\"login\":\"user%40domain.co.uk\"}" -H "Api-Key: xxxxx" -H "Api-Username: system" -H "Content-Type: application/json"

La risposta che ricevo è:

<html><body>Stai venendo <a href="https://discourse.<site>.org.uk/">reindirizzato</a>.</body></html>

Se non includo la chiave API, ricevo [BAD CSRF].

Quindi, il problema su cui sono bloccato è: come posso far sì che Discourse invii un link di accesso via email all’utente @ domain .co.uk tramite la API?

Grazie mille per qualsiasi aiuto. Continuerò a provare diverse soluzioni per vedere cosa funziona.

P.S. Preferirei non dover ricorrere a un workaround del tipo:
Effettuare una richiesta a /session/csrf e salvare il token CSRF,
poi effettuare una richiesta a /u/email-login con il token CSRF.

È possibile farlo utilizzando solo una chiave API?

Grazie!
:slight_smile:

2

Solo per un aggiornamento: è corretto utilizzare la rotta CSRF seguita dalla rotta del link email?

Non esiste un’implementazione di questo nell’API quando viene fornita una chiave API?

3

Come si interfaccia il tuo servizio SSO con Discourse? Se stai utilizzando DiscourseConnect, penso che l’endpoint /u/email-login sarà disabilitato.

4

Grazie per la risposta. Sì, sta utilizzando Discourse Connect.

Vedi, pensavo lo stesso, quindi ho disabilitato Discourse Connect e ho provato a ottenere un link di accesso, ma non sono riuscito a farlo funzionare. È così che ho ottenuto l’output nel mio post sopra.

Se l’ottenimento di un link via email è disabilitato quando Discourse Connect è attivo, dovrò ripensare al mio approccio su come collegare gli account dal servizio SSO del sistema di membership a Discourse.

5

Il modo più semplice, come hai menzionato, è abbinare gli account tramite indirizzo email. Quando ciò non è possibile, esistono alcune strategie che utilizziamo:

  1. Abbinare gli utenti utilizzando un altro identificatore univoco. Puoi creare in anticipo le associazioni DiscourseConnect per un utente tramite la console. Questo funzionerà solo se disponi di un identificatore coerente sia in Discourse che nel Provider di Identità.

  2. (più comune) permettere agli utenti di registrarsi per nuovi account, quindi chiedere loro di inviare un messaggio a un amministratore e richiedere che il nuovo account venga “fuso” con quello vecchio (utilizzando il pulsante nella parte inferiore della pagina di amministrazione dell’utente). Questo abbinerà automaticamente le email e creerà l’associazione DiscourseConnect.

6

Grazie per la tua risposta.

L’approccio di unire gli account è probabilmente quello che sceglierò.

Sarebbe un’ottima funzionalità rendere questo processo autonomo per l’utente, magari tramite un’API in cui gli utenti possono accedere tramite un link inviato via email e aggiornare quindi il proprio indirizzo email per sincronizzare i due account.
Oppure consentendo all’utente di autenticarsi fornendo l’email e la password del proprio account Discourse, insieme a un nuovo indirizzo email.

Grazie ancora per il tuo tempo.