Come gestire il timeout della sessione quando si utilizza la sicurezza programmatica Servlet 3.0

Per quanto riguarda la sicurezza programmatica di Servlet 3.0, quando una sessione va in timeout non è possibile richiamare HttpServletRequest#logout().Come gestire il timeout della sessione quando si utilizza la sicurezza programmatica Servlet 3.0

L'utente rimane connesso a JAAS?

In tal caso, qual è la procedura migliore per gestire la disconnessione da JAAS dopo il timeout della sessione?

In che modo il contenitore gestisce la successiva richiesta dell'utente di accedere nuovamente e creare una nuova sessione dopo il timeout della sessione?

Per inciso, quali sono i pro ei contro di utilizzare i seguenti tre approcci per gestire timeout della sessione quando si usa Servlet 3.0 Programmatico sulla Sicurezza:

HttpSessionListener#sessionDestroyed()
Fai il @ManagedBean @SessionScoped LoginManager attrezzo HttpSessionBindingListener e fare qualcosa in valueUnbound.
Annota un metodo in LoginManager con @PreDestroy.

Qualsiasi altro approccio suggerito/consiglio sulle migliori pratiche sarebbe sicuramente apprezzato.

fonte

2012-02-24 Patrick Garner

"Core Java Server Faces" p. 525 indica "Attualmente non ci sono specifiche per la disconnessione o per la commutazione di identità quando si utilizza la sicurezza gestita dal contenitore." –

Mi sono imbattuto in un paio di sproloqui su sicurezza J2EE, lamentando che una sessione invalidata è un povero sostituto per il logout formale, ma i blog erano più vecchi, scritti prima di Servlet 3.0, che fornisce un modo per disconnettersi programmaticamente. –

Ovviamente la tua edizione CJSF è precedente a Servlet 3.0. – EJP

C'è un'affermazione da qualche parte nella specifica Servlet che l'invalidità della sessione corrisponde esattamente allo stato in cui non vi è un Preside in esso. Questa è la chiave. logout() e timeout invalideranno la sessione e invalidando la sessione rimuoverà il Principal da esso e tutte le sue associazioni di valori.

Tutto ciò che JAAS fa davvero è consentire a LoginModules di accumulare Principali in un Subject, sia per l'utente che per i suoi ruoli. Tutto quello che il metodo JAAS logout() deve davvero fare è cancellare l'oggetto dei Principali che sono stati aggiunti dallo stesso modulo login(), o più probabilmente commit(), metodo, e questo è davvero solo per sicurezza totale se hai aggiunto cose come credenziali private a il soggetto. Poiché logout() non verrà eseguito dalla stessa istanza di login()/commit(), tale rimozione deve essere basata sulla classe principale piuttosto che su una raccolta interna di principal.

Il logout JAAS() non viene chiamato quando la sessione scade, ma come il preside viene rimosso dalla sessione che non dovrebbe davvero importare a nessuno.

Se si desidera tenere traccia della terminazione della sessione per qualche altro motivo, ad es. logging, rendere il bean utente un listener di binding di sessione e registrare la terminazione come un logout nel metodo valueUnbound(): questo è affidabile al 100% nella mia esperienza.

per rispondere alle vostre domande, non c'è un tale stato come 'loggato per JAAS': JAAS fornisce un servizio di login/logout al contenitore, non a se stesso; e un nuovo accesso è un nuovo accesso, in una nuova sessione, indipendentemente dal fatto che sia scaduto o meno.

fonte

2012-07-17 23:00:11 EJP

+1 per una risposta sintetica (corretta) =) Molti commenti offensivi sono stati rimossi da questo post, rendendo alcune delle risposte (rimosse) incoerenti nel tono. Tutto e 'bene quel che finisce bene. – earcam

Grazie a @EJP. È interessante notare che, se imposto un breakpoint dopo l'invocazione di request.logout(), posso vedere che la sessione non è invalidata, sebbene il Preside sia rimosso dalla sessione. Al momento del login nel JSESSIONID non cambia e l'oggetto di sessione rimane la stessa identica istanza (ad es. @ 15961), che è un po 'inquietante. L'utilizzo di session.invalidate() in aggiunta o al posto di request.logout(), ovviamente, causa la modifica di JSESSIONID e dell'oggetto di sessione. Questo è su JBoss AS7. Ancora più importante, il preside viene rimosso come hai detto indipendentemente da quale dei due metodi è stato invocato. –

@PatrickGarner Bene che tutto ciò che la documentazione di HttpServletRequest.html.logout() dice che lo fa. Session.invalidate() esegue l'invalidazione, ma non influisce sulla richiesta corrente o sul suo principal, quindi se lo usi puoi sempre visualizzare le cose come se l'utente fosse loggato. Devi chiamarle entrambe. Strano affare davvero. – EJP

La gestione della sessione non è direttamente collegata a JAAS .. e la gestione delle sessioni dipende molto dal contenitore.

Nel Jetty 8, la gestione della sessione viene gestita dal SessionManager (a livello di contesto) e da SessionIdManager (a livello di server).

Il browser invia l'ID di sessione al server. La classe che implementa SessionManager convalida l'ID della sessione. Se la sessione è scaduta, la sessione viene invalidata e rimossa e i listener della sessione vengono avvisati.

Non sono sicuro del motivo per cui è necessario "disconnettersi" dall'utente, ma si dovrebbe essere in grado di agganciare il logout agli ascoltatori.

'Rimanere registrato in JAAS' potrebbe non significare molto sul tuo contenitore. Il molo non ha una cache user/principal/objects, quindi non "resta loggato" a meno che tu non implementi una cache tu stesso, come abbiamo fatto noi.

Il modulo JAAS fornisce semplicemente l'autenticazione e l'autorizzazione; nient'altro.

ADD

Quando la sessione è scaduta, il server invia una 302 indietro e reindirizza alla pagina di login. Il modulo di invio sulla pagina chiama il modulo di accesso (che può essere un modulo JAAS) e, una volta completata l'autenticazione, crea una nuova sessione e un ID di sessione che vengono inviati di nuovo al browser tramite la media di un cookie (o riscrittura dell'URL).

A meno che l'app non gestisca un singolo ID di contesto per tutti i contesti, non penso che si debba eseguire alcun tipo di disconnessione programmatica quando scade una sessione; puoi 'invalidare' un utente che ha ancora una sessione valida in un altro contesto.

fonte

2012-03-09 18:02:35

Non so cosa ci sia dentro il coraggio di JAAS. Non so come il contenitore web si interfaccia con JAAS, ad es. dove sono archiviati gli oggetti, i principali e i gruppi, cosa succede realmente quando viene richiamato HttpServletRequest # logout() e quando scade la sessione. La pulizia eseguita quando viene richiamato HttpServletRequest # logout() viene eseguita anche dal contenitore se la sessione scade? In caso contrario, perché non è necessario in tali circostanze? –

Dopo aver letto le specifiche Servlet 3.0. e JAAS spec. e JEE 6 spec. Non conosco le risposte alle domande di cui sopra e spero che qualcuno possa indicarmi i thread di documentazione o dev-list o forse anche i documenti di progettazione JBoss/Tomcat/Jetty/Glassfish o snippet di codice sorgente che mostrano cosa succede al Soggetto , Principal e Group istanze quando la sessione scade. Sarebbe bello sapere cosa succede a questi oggetti quando viene richiamato anche HttpServletRequest # logout(). Le differenze, se ce ne sono, tra il modo in cui la disconnessione è gestita nelle due circostanze sarebbe grandiosa. –

Come gestire il timeout della sessione quando si utilizza la sicurezza programmatica Servlet 3.0

risposta

Problemi correlati