Stiamo creando un sito Web di servizi aziendali, in cui gli utenti devono accedere per accedere ai contenuti. La parte di autenticazione di quel sito Web è abbastanza stabile e fa parte del nostro codice. Finché l'utente è sul nostro sito, è autenticata e detiene un cookie di sessione (in questo caso la gestione della sessione viene eseguita da cherrypy ).
Mentre il sito cresceva, volevamo aggiungere più funzionalità di visualizzazione / tracciamento e trovato dash (di plotly ) per essere una buona idea. Sfortunatamente, il modo consigliato per integrare le app di dash nei siti Web esistenti è tramite iframe s ( link ).
Nel nostro caso volevamo mantenere le cose semplici e abbiamo deciso di fare esattamente questo: generare un iframe e inserirlo nel nostro sito web esistente. Ora la domanda è: Come dovrei autenticare qualsiasi accesso a questo servizio incorporato?
(1) Il mio pensiero iniziale era semplicemente condividere il cookie di sessione tra sottodomini, ma non abbiamo visto un modo banale per configurarlo come parte della gestione della sessione cherrypy . (Il sito Web principale viene eseguito su "www.mydomain.com", mentre il servizio incorporato viene eseguito su un altro CNAME "service.mydomain.com"). Il servizio integrato dovrebbe anche convalidare l'id della sessione con il server cherrypy principale, magari attraverso un endpoint aperto (?), Che non sembra un buon progetto.
(2) Il mio prossimo pensiero è stato quello di configurare un server OAuth2.0 (ad esempio ory/hydra ), ma aggiunge complessità significativa, che speravo di evitare.
(3) Non sono sicuro al 100% se l'autenticazione di base sarebbe fattibile in questo caso. Tecnicamente, sembra che si possa utilizzare un proxy inverso come discusso qui: link
(4) Il mio ultimo è stato quello di fornire token monouso come parte del iframe , che dovrebbe essere nuovamente convalidato dal server cherrypy principale, ma non mi piace quanto sarebbe facile essere per intercettare quel iframe URL e utilizzare il token altrimenti.
PS: c'è una domanda simile qui , ma il le soluzioni discusse non hanno considerato OAuth2.0 e potrebbero essere obsolete.