Sostituire l'autenticazione con un'alternativa senza password

Contribuisci Funzionalità
1

Questo post riguarda una funzionalità che sicuramente non esiste ma che vorrei implementare io stesso. Al momento, però, non ho idea di quanto lavoro potrebbe richiedere e lo scopo di questa domanda è cercare di capire cosa sia necessario.

Alcuni contesti: stiamo lavorando a una soluzione di autenticazione senza password. https://trykno.com/ La soluzione funziona come servizio, il che significa che i proprietari dei siti che utilizzano il servizio non devono gestire l’invio sicuro di e-mail o l’archiviazione di segreti e informazioni di identificazione personale.

Sarebbe fantastico avere un forum per il progetto e vorremmo utilizzare Discourse.
Tuttavia, dobbiamo sostituire il sistema di autenticazione in modo che utilizzi Kno.

Domande?

  • Il sistema di autenticazione in Discourse è pluggable?
  • Ci sono ipotesi hardcoded sul fatto che l’utente abbia un indirizzo e-mail?
  • Qual è il framework front-end? (Vedo ember-rails nel Gemfile, ma nessun riferimento a Ember in package.json)

Scusate se queste domande sono semplicistiche, non sono uno sviluppatore Ruby e qualsiasi spunto sul problema sarebbe prezioso. Grazie

2

Assumendo che tu intenda “Discourse” :stuck_out_tongue: Sì, è estendibile. Puoi sviluppare un plugin di autenticazione oppure utilizzare il sistema SSO nativo.

Sì, ogni utente deve avere un’email in Discourse. Puoi fornire email non valide (che terminano con .invalid), ma non lo consigliamo.

Ember. Tuttavia, per un plugin di autenticazione, è improbabile che tu debba modificare il front-end.

6 Mi Piace
3

Ah, che imbarazzo, aggiornerò.

È una funzionalità per cui non è necessario conoscere l’email dell’utente quando si utilizza Kno, anche se può essere richiesta.

2 Mi Piace
4

Al momento è possibile non utilizzare una password e ricevere semplicemente un link.

Se il tuo obiettivo è sviluppare kno, probabilmente vorrai configurarlo come un server OAuth. In questo modo, gli utenti potranno utilizzarlo come una delle diverse fonti di autenticazione, dove SSO rappresenta l’unica opzione. Consulta Discourse OAuth2 Basic

2 Mi Piace
5

Vedo la possibilità di ricevere un link, ma kno offre funzionalità aggiuntive, come l’autenticazione del dispositivo tramite WebAuthn, una volta confermata l’email con un codice monouso.

Sviluppare come server OAuth purtroppo non soddisfa i requisiti di cui abbiamo bisogno. (Dovrei probabilmente scrivere qualcosa nel nostro FAQ per spiegare il motivo, ma la questione si riduce al fatto che Kno ti permette di autenticarti su un dispositivo utilizzando un altro dispositivo).

Analizzando la situazione più da vicino, sembra che dovrei essere in grado di mettere insieme una prima versione funzionante implementando una soluzione SSO specifica per Discourse.

1 Mi Piace
6

È possibile utilizzare un solo provider OAuth e disabilitare tutti gli altri tipi di autenticazione?

In tal caso, sarebbe utile anche che cliccando su “Accedi” venisse avviato automaticamente il flusso di autenticazione, ovvero senza aprire la finestra di accesso e chiedere all’utente di selezionare il provider.

7

Potresti riuscire a collegarlo.

Ma perché preoccuparsi, dato che una volta che qualcuno è loggato, raramente vede quel dialogo?

È meglio che tu impieghi il tuo tempo in modo più produttivo su altri problemi.

8

L’hai già provato? Perché è così che funziona Discourse da anni di default :wink:

3 Mi Piace
9

Beh, questa è ottima.
No, non l’ho ancora provato perché non ho ancora implementato il provider OAuth per il mio servizio, e immagino che dopo dovrò scrivere un plugin, dato che sarà un nuovo provider OAuth.

Ho quasi completato l’integrazione SSO, quindi immagino sia il momento perfetto per passare all’uso di OAuth. :smiley:

1 Mi Piace