Sto utilizzando Discourse come identity provider per la mia applicazione Rails (ti accedi alla mia app Rails con il tuo login Discourse; non il contrario). Vorrei aggiungere un link alle pagine dei profili utente in Discourse per portarti al rispettivo profilo sulla mia app Rails. Per fare ciò, Discourse dovrebbe conoscere il loro ID utente nella mia applicazione/database Rails.
So che DiscourseConnect salva ‘external_id’ quando fai il contrario (accedi a Discourse con un altro login). Ma salva qualcosa quando è in questo modo?
Non lo fa, quindi avrai bisogno di qualcosa di personalizzato.
Mi chiedo se avrebbe più senso gestire questo nella tua app Rails, dato che conosce l’ID Discourse di un utente?
Potresti configurare un percorso come /profile-by-discourse-id/:discourse_id che cerca l’utente pertinente in base all’ID Discourse e quindi reindirizza al profilo dell’utente nell’app Rails.
Grazie @david. Abbastanza divertente, è esattamente quello che ho fatto per collegare nell’altra direzione (dalle mie schede profilo utente dell’app Rails ai profili utente di Discourse) tramite questo plugin Discourse (/user-by-id/123/summary) poiché la mia app Rails memorizza l’ID utente di Discourse invece del nome utente (poiché i nomi utente possono cambiare).
Quella soluzione funzionerebbe nell’altra direzione tranne per il fatto che non tutti gli utenti del forum hanno profili utente nella mia app Rails. Un utente Rails viene creato solo una volta che l’utente Discourse “si unisce” all’organizzazione, mentre il forum Discourse può contenere non membri.
Quindi suppongo che le mie due opzioni siano:
A) Creare un plugin JavaScript che invii una richiesta ajax alla mia app Rails per determinare se l’utente Discourse è anche un utente nell’app Rails e, in tal caso, visualizzi un link; o
B) Al momento della creazione dell’utente Rails e del collegamento all’utente Discourse, oltre a memorizzare l’ID utente Discourse nel database dell’app Rails, memorizzare in qualche modo l’ID utente Rails nel profilo utente Discourse (ad esempio, come campo utente personalizzato).
Penso che (B) sia la soluzione migliore (a condizione che il campo utente personalizzato non sia modificabile se non dagli amministratori), anche se non ho familiarità con i campi personalizzati o se sono accessibili tramite API.
MODIFICA: Ora ricordo dall’ultima volta che ci ho pensato: il problema è che i campi utente personalizzati sono modificabili dall’utente, il che li rende un brutto posto dove memorizzare un riferimento generato dal sistema come questo
