Newsgroup: it.lavoro.informatica
Titolo: Autenticazione in JEE

Trovo il tutto allucinante. Non riesco a capire quale sarebbe la best practice per un semplice form di login con redirect alla form se la url non e' autorizzata. Cose banali insomma.
 
Premetto che per anni ho semplicemente piazzato un filtro per proteggere le risorse e scritto la query per il login a mano. Ma ho sempre pensato che fosse una soluzione casalinga e JEE offrisse di meglio.
 
Invece noto che: decine di tutorial continuano a parlare di BASIC, DIGEST e cagate varie. Ora chi e' disposto nel 2017 ad accettare la finestrella standard di login del browser? Direi nessuno.
 
FORM e' ok, ma, salta fuori che non e' minimamente customizzabile. Se voglio mostrare un messaggio di errore? Se voglio eseguire logica supplementare oltre al login? 
 
Ci sarebbe programmatic authentication, ma non si capisce con cosa usarla. Sembrerebbe solo BASI o DIGEST, di certo non FORM (c'e' scritto nello spec che e' alternativa a FORM).
 
In piu', sembrerebbe che se esci dallo standard, ti perdi alcune cose come ad esempio il SSO fornito a gratis dall'Application Server.

 In piu', sembrerebbe che se esci dallo standard, ti perdi alcune cose come ad esempio il SSO fornito a gratis dall'Application Server.
 
umh, secondo me ti devi fare un po' di chiarezza mentale sul tema.
certo l'approccio java non è dei più immediati ma anche la problematica 
non è banale.
 
 

 non è banale.
 
In realta', anche informandomi altrove, vedo che molta gente mi dice di provare shiro o picketlink. Forse e' noto che quanto fornito da JEE fa schifo (o comunque e' troppo rigido).

 Semplicemente mancano le callback per quando il login ha successo e non.
 
Vado a naso senza documentazione sotto mano ma ci dovrebbero essere 
delle API per gestire le eccezioni di quando il login non ha successo.
Ricordati che puoi sempre estendere l'implementazione base che stai usando.
 
Anche in Spring, che è già tutto pronto, devi comunque metterci del tuo.
 
E diciamo la verità, la parte security, soprattutto OAuth2, di Spring, è 
un mezzo bordello. Speriamo l'abbiano ripulita nella 5.

 un mezzo bordello. Speriamo l'abbiano ripulita nella 5.
 
Io penso che prima o poi passo a Auth0. Mi chiedevo come mai JEE, dopo tanti passi in avanti su quasi tutti fronti, abbia ancora un sistema di autenticazione patetico (neanche fosse un aspetto di poco conto).

 come un pazzo con filtri e altre cose imparazzanti (per uno standard).
 
la messaggistica di errore direi che sia un problema del client. quanto 
al resto dipende da cosa consiste questa logica supplementare. java non 
offre un framework per l'autenticazione fatto e finito, in linea di 
principio il flusso di autenticazione lo dovresti implementare te. 
 

 principio il flusso di autenticazione lo dovresti implementare te.
 
Non sono d'accordo: in JSF (framework standard eh) non e' un problema del client manco per idea.  E ripeto, non c'e' proprio nulla da implementare. La specifica e' palesemente inutilizzabile, quindi e' da buttare tutto e farselo da se' (filtro) o usare una libreria esterna. Guarda a caso queste librerie esterne non mi pare implementino alcun interfaccia dello standard.

 del client manco per idea.  
 
se parliamo di jsf devo riportare il calendario indietro di almeno 10 
anni e ricordare come facevo allora, quando il web era stateful e le 
pagine si generavano lato server...

 pagine si generavano lato server...
 
Come vuoi, ma non e' come dici. JSF e' ancora molto usato e persino raccomandato  (da gente come Adam Bien e molti altri volti noti del mondo JEE) nel caso di applicazioni enterprise dove si richiede semplicita' e velocita' di sviluppo (a discapito di un maggior controllo sulla pagina ovviamente). 
Le SPA sono tutt'oggi un bel casino sotto molti punti di vista.

 Le SPA sono tutt'oggi un bel casino sotto molti punti di vista.
 
direi molto, molto opinabile.

 direi molto, molto opinabile.
 
Che c'e' di opinabile? Non mi dirai che fai prima a fare una form con dei checkbox  usando Angular o React, piuttosto che JSF + PrimeFaces per esempio.

 esempio.
 
sono abbastanza confidente che, a parità di rispettive conoscenze, ci si 
metta lo stesso tempo. se la tua tesi è che con questi sistemi si 
sviluppano i front-end più lentamente sei fuori strada, ma anche di 
parecchio, fosse solo per la facilità con cui si fa il debug. sono sicuro 
che anche adam bien avrà argomenti più convincenti per raccomandare le 
jsf. 

 jsf.
 
Lungi da me aprire un flame, ma le argomentazioni pro JSF mi ricordano 
un po' quelle di Delta11 per il COBOL.
JSF da quello che vedo in giro è morto - aspettando solo la sepoltura - 
come altre architetture, es. portlet. Il fatto che ci sia gente che lo 
usa è dovuto diversi motivi tra cui il più semplice è che sia facile 
affezionarsi ad una architettura, di cui si diviene "maestri", per poi 
usarla indefinitivamente anche quando altre emergono e la soppiantano.
"Chi lascia la via vecchia per la nuova, sa quel che lascia, e non sa 
quel che trova" è valida in molti ambiti e a volte anche in informatica. 
Ma provare, anche solo in ambito casalingo, non nuoce.
 
Se così non fosse oggi starei ancora a scrivere codice usando Struts2 e 
JSP (brrr) ...
 
Poi è ovvio che sopragiungono altre barriere. Immagino che fare il 
porting di un'applicazione complessa da JSF a Spring + Angular sia lungo 
e costoso...

 e costoso...
 
Questo e' un buon punto. Ma ce ne sono altri. Ad esempio se devo sviluppare un'area amministrativa usata da decine o al massimo centinaia di utenti, con JSF sviluppi veloce come un siluro. Non e' altrettanto vero per le librerie js sopra citate.