Disabilitare il requisito dell'email di attivazione per gli utenti invitati

Ciao a tutti, ho un caso d’uso che al momento non è supportato in modo adeguato: devo disabilitare l’email di attivazione per gli utenti invitati, inclusi gli utenti invitati tramite un link.

Dopo aver avviato l’argomento sopra, questa funzionalità è stata implementata, ma solo per gli utenti invitati tramite email.

La mia istanza di Discourse è accessibile solo su invito e in realtà invio i link di invito via email, ma non utilizzando le email integrate di Discourse. Genero i link di invito tramite una richiesta POST a /invites/link e li memorizzo in un database esterno, da cui invio i link all’utente. Quindi, quando gli utenti cliccano sul link, hanno già verificato la propria email, ma vengono poi richiesti di farlo nuovamente.

Capisco che il mio caso d’uso non sia particolarmente comune, quindi ho pensato di provare a creare un semplice plugin per modificare le parti necessarie di Discourse e farlo funzionare come mi serve.

Ho già impostato una struttura di base e aggiunto un’impostazione del sito (no_activation_enabled). Dopo aver cercato nel repository principale, credo che questo possa essere il file da modificare:

Non sono sicuro al 100%, ma penso che potrebbe funzionare modificando condizionalmente (se SiteSetting.no_activation_enabled è attivo e se l’utente è stato invitato da uno staff, forse tramite invite.invited_by.staff?) il valore di active in true all’interno di user.attributes:

    user.attributes = {
      email: invite.email,
      username: available_username,
      name: name || available_username,
      active: false,
      trust_level: SiteSetting.default_invitee_trust_level,
      ip_address: ip_address,
      registration_ip_address: ip_address
    }

Ma come posso modificare questo da un plugin? È persino possibile all’interno delle funzionalità offerte dai plugin? O possono solo aggiungere cose, non modificarle? Oppure devo sostituire l’intero file invite_redeemer.rb?

Ho completato l’introduzione alla creazione di plugin, nonché questa guida, ma dopo ore passate a scavare nel codice, inclusi altri plugin, mi sembra di sbattere la testa contro un muro… Quindi, se qualcuno ha qualche consiglio per me, ne sarei davvero grato!

Se stai gestendo la cosa da un sito esterno, perché non far gestire l’SSO e passare semplicemente la verifica nel payload?

Ciao Stephen, grazie per il tuo contributo.

Non gestisco gli account utente su un sito esterno. Ho un sistema principale basato su Airtable + Zapier + GCF che collega diversi servizi (tra cui ESP, ecc.), ma Discourse è il database principale degli utenti. Non voglio semplicemente utilizzare il modulo di registrazione standard di Discourse perché non è ottimale per le conversioni e non può essere integrato, ad esempio, nei post del blog. Al contrario, Discourse funge da provider SSO per il sito di contenuti basato su Jekyll: invia richieste fetch per verificare se un utente è loggato su Discourse e adatta le pagine dei contenuti di conseguenza.

Ehi, benvenuto :slight_smile:

Come @Stephen, non sono completamente sicuro che questo sia lo strumento giusto, ma confido che tu ci abbia pensato a sufficienza.

Eviterei questo a tutti i costi. C’è quasi sempre un’altra soluzione, anche se devi applicare una monkey patch a una classe. Per quanto riguarda le monkey patch in Discourse, vedi: Override existing Discourse methods in plugins.

In questo caso sembra che ci sia già del codice nel metodo su cui ti stai concentrando che fa ciò che desideri: discourse/app/models/invite_redeemer.rb at main · discourse/discourse · GitHub

Il problema è che gli inviti che hai generato non hanno il corretto emailed_status_type, quindi quella condizione non viene soddisfatta. Penso che la soluzione qui sia generare inviti diversi fin dall’inizio. È lì che mi concentrerei.

In sostanza, si sta reintroducendo una funzionalità rimossa dal nucleo perché troppo pericolosa: se gestite in modo errato questi token di invito, chiunque li rubi (prima che il destinatario previsto li utilizzi) potrebbe accedere al forum come il destinatario. Consiglio vivamente di non utilizzare questo tipo di invito per account di moderatori o amministratori.

Per questo motivo, il codice per gestirlo è già presente, ma sarà necessario apportare alcune modifiche personalizzate per accedervi effettivamente.