Autenticazione in JEE

[l***@gmail.com]

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.

[rootkit]

Post by l***@gmail.com
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.

posto che io ho sempre lavorato con spring e mi sono sempre trovato bene
con la sua implementazione: in effetti sì, quella è una soluzione
casalinga e lo standard offre di meglio:

https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASRefGuide.html

nota bene: le api fanno parte di java standard edition, non enterprise.
tant'è vero che seguendo lo standard tu proteggi a livello di esecuzione
di metodi/classi, non a livello di endpoint web (come fai con i filtri).

Post by l***@gmail.com
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?

si può fare tutto quello che dici anzi lo si fa regolarmente; qual'è il
problema?

Post by l***@gmail.com
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.

[l***@gmail.com]

Post by rootkit

Post by l***@gmail.com
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.

posto che io ho sempre lavorato con spring e mi sono sempre trovato bene
con la sua implementazione: in effetti sì, quella è una soluzione
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASRefGuide.html
nota bene: le api fanno parte di java standard edition, non enterprise.
tant'è vero che seguendo lo standard tu proteggi a livello di esecuzione
di metodi/classi, non a livello di endpoint web (come fai con i filtri).

Beh, consente anche di proteggere il livello web se configuri opportunamente il web.xml. Il problema e' che ha talmente tante limitazioni da risultare assolutamente inutile. Anzi una grande perdita di tempo, perche' essendo lo standard parti da li' e poi scopri che devi buttare via tutto alla prima richiesta che esce una virgola da quello che hanno pensato.

Post by rootkit

Post by l***@gmail.com
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?

si può fare tutto quello che dici anzi lo si fa regolarmente; qual'è il
problema?

Se mi dici come! Non mi pare ci sia modo, se non (forse) smanettando come un pazzo con filtri e altre cose imparazzanti (per uno standard).

Semplicemente mancano le callback per quando il login ha successo e non.

Post by rootkit

Post by l***@gmail.com
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.

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).

[M C]

On 07/12/17 13:54, ***@gmail.com wrote:
[...]

Post by l***@gmail.com
Se mi dici come! Non mi pare ci sia modo, se non (forse) smanettando come un pazzo con filtri e altre cose imparazzanti (per uno standard).
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.

[l***@gmail.com]

Post by M C
[...]

Post by l***@gmail.com
Se mi dici come! Non mi pare ci sia modo, se non (forse) smanettando come un pazzo con filtri e altre cose imparazzanti (per uno standard).
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.

Insisto che non si sono, per quanto possa sembrare assurdo! C'e' un API dalla Servlet 3.0 in poi, HttpServletRequest#login, ma che puoi usare solo con BASIC o DIGEST, cioe' con niente visto che non servono appunto a niente. Se leggi lo spec, dice esplicitamente che e' alternativa a FORM. Quindi se usi la FORM (cioe' praticamente il 99%) sei fottuto :)

Post by M C
Anche in Spring, che è già tutto pronto, devi comunque metterci del tuo.

L'avranno fatta decentemente.

Post by M C
E diciamo la verità, la parte security, soprattutto OAuth2, di Spring, è
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).

[rootkit]

Post by l***@gmail.com

Post by rootkit
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/

JAASRefGuide.html

Post by l***@gmail.com

Post by rootkit
nota bene: le api fanno parte di java standard edition, non enterprise.
tant'è vero che seguendo lo standard tu proteggi a livello di
esecuzione di metodi/classi, non a livello di endpoint web (come fai
con i filtri).

Beh, consente anche di proteggere il livello web se configuri
opportunamente il web.xml.

le autorizzazioni sono assegnate dichiarativamente (con le annotation)
sugli ejb, che stanno ad un livello pari o inferiore del web. quindi è
automatico che anche il livello web sia protetto. con il vantaggio che se
in un servizio web ti scappasse di chiamare un ejb che richiede privilegi
maggiori con quel sistema lo intercetti e lo blocchi, con il metodo
"casalingo" no.
inoltre con lo sviluppo web attuale ciò che è esposto sono direttamente
gli ejb, come servizi rest principalmente. i filtri per la sicurezza sono
una concezione del passato (anche remoto).

Post by l***@gmail.com
Il problema e' che ha talmente tante
limitazioni da risultare assolutamente inutile. Anzi una grande perdita
di tempo, perche' essendo lo standard parti da li' e poi scopri che devi
buttare via tutto alla prima richiesta che esce una virgola da quello
che hanno pensato.

come spiegavo la mia esperienza è con spring di cui tutto si può dire
(complicato, sovra ingegnerizzato, etc...) tranne che sia limitato.
conosco poco la parte standard, se non quella che è comune con il
framework che uso, ma direi che la filosofia che sta dietro al jee è
nota: java ti da le interfacce, poi l'implementazione è del singolo
container. vale anche per la login: va bene l'implementazione del
container? se sì, allora ce l'hai gratis, altrimenti bisogna mettersi di
buzzo buono e implementare il proprio.

Post by l***@gmail.com

Post by rootkit

Post by l***@gmail.com
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?

si può fare tutto quello che dici anzi lo si fa regolarmente; qual'è il
problema?

Se mi dici come!

sì ma poi mi paghi! :-)

Post by l***@gmail.com
Non mi pare ci sia modo, se non (forse) smanettando
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.

[l***@gmail.com]

Post by rootkit

Post by l***@gmail.com

Post by rootkit
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/

JAASRefGuide.html

Post by l***@gmail.com

Post by rootkit
nota bene: le api fanno parte di java standard edition, non enterprise.
tant'è vero che seguendo lo standard tu proteggi a livello di
esecuzione di metodi/classi, non a livello di endpoint web (come fai
con i filtri).

Beh, consente anche di proteggere il livello web se configuri
opportunamente il web.xml.

le autorizzazioni sono assegnate dichiarativamente (con le annotation)
sugli ejb, che stanno ad un livello pari o inferiore del web. quindi è
automatico che anche il livello web sia protetto. con il vantaggio che se
in un servizio web ti scappasse di chiamare un ejb che richiede privilegi
maggiori con quel sistema lo intercetti e lo blocchi, con il metodo
"casalingo" no.

Ma guarda, gli EJB potrei anche annotarli tutti perfettamente o sbattere degli interceptor o altro (che e' il mio caso, ma non sto a spiegare :), ma non risolverebbe nessun problema che ho sollevato (vedi piu' avanti).

Post by rootkit
inoltre con lo sviluppo web attuale ciò che è esposto sono direttamente
gli ejb, come servizi rest principalmente. i filtri per la sicurezza sono
una concezione del passato (anche remoto).

Non e' il mio caso e non tutte le applicazioni sono SPA. Comunque ripeto, il problema non e' bloccare questa o quella call, quanto l'integrazione con lo strato web (form di autenticazione, redirect, messaggi, eccetera).

Post by rootkit

Post by l***@gmail.com
Il problema e' che ha talmente tante
limitazioni da risultare assolutamente inutile. Anzi una grande perdita
di tempo, perche' essendo lo standard parti da li' e poi scopri che devi
buttare via tutto alla prima richiesta che esce una virgola da quello
che hanno pensato.

come spiegavo la mia esperienza è con spring di cui tutto si può dire
(complicato, sovra ingegnerizzato, etc...) tranne che sia limitato.

Ma scusa, io non ho mai parlato di Spring.

Post by rootkit
conosco poco la parte standard, se non quella che è comune con il
framework che uso, ma direi che la filosofia che sta dietro al jee è
nota: java ti da le interfacce, poi l'implementazione è del singolo
container. vale anche per la login: va bene l'implementazione del
container? se sì, allora ce l'hai gratis, altrimenti bisogna mettersi di
buzzo buono e implementare il proprio.

Cioe' andare di filtri o importare Shiro e Picketlink. Che poi non e' vero quanto dici: JSF e' uno standard e definisce tutto nei minimi particolare. Lo stesso vale per una serie di altre sottospecifiche. E' proprio quella per l'autenticazione che e' lasciata alla fantasia piu' totale.

Post by rootkit

Post by l***@gmail.com

Post by rootkit

Post by l***@gmail.com
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?

si può fare tutto quello che dici anzi lo si fa regolarmente; qual'è il
problema?

Se mi dici come!

sì ma poi mi paghi! :-)

Potrei pagarti se mi fai consulenza su Auth0, casomai :)

Post by rootkit

Post by l***@gmail.com
Non mi pare ci sia modo, se non (forse) smanettando
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.

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.

[rootkit]

Post by l***@gmail.com

Post by rootkit
come spiegavo la mia esperienza è con spring di cui tutto si può dire
(complicato, sovra ingegnerizzato, etc...) tranne che sia limitato.

Ma scusa, io non ho mai parlato di Spring.

spring security supporta anche jaas e offre le funzionalità che ti
aspetti.
https://goo.gl/E7e2Tt

Post by l***@gmail.com

Post by rootkit
conosco poco la parte standard, se non quella che è comune con il
framework che uso, ma direi che la filosofia che sta dietro al jee è
nota: java ti da le interfacce, poi l'implementazione è del singolo
container. vale anche per la login: va bene l'implementazione del
container? se sì, allora ce l'hai gratis, altrimenti bisogna mettersi
di buzzo buono e implementare il proprio.

Cioe' andare di filtri o importare Shiro e Picketlink. Che poi non e'
vero quanto dici: JSF e' uno standard e definisce tutto nei minimi
particolare. Lo stesso vale per una serie di altre sottospecifiche. E'
proprio quella per l'autenticazione che e' lasciata alla fantasia piu'
totale.

scusa, senza polemica ma per capire: cosa c'entra jsf con
l'autenticazione?
e cosa c'è di male a usare librerie aggiuntive, se queste ti offrono le
funzionalità che desideri?
e cosa vuol dire "l'autenticazione che è lasciata alla fantasia più
totale"? devi implementare un loginmodule che consta di *un* metodo, mica
sbizzarrirti di fantasia. se non basta (anche se ancora non ho compreso
il motivo) niente vieta di cercarsi la libreria che meglio "fitta" le
esigenze. figuriamoci, penso di aver trascorso metà del mio tempo a
valutare fra librerie java, moduli di node, framework front-end, build
tools, etc... scusami se non concepisco il tono da melodramma.

Post by l***@gmail.com

Post by rootkit
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.

Non sono d'accordo: in JSF (framework standard eh) non e' un problema
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...

[l***@gmail.com]

Post by rootkit

Post by l***@gmail.com

Post by rootkit
come spiegavo la mia esperienza è con spring di cui tutto si può dire
(complicato, sovra ingegnerizzato, etc...) tranne che sia limitato.

Ma scusa, io non ho mai parlato di Spring.

spring security supporta anche jaas e offre le funzionalità che ti
aspetti.
https://goo.gl/E7e2Tt

Si ma puo' essere che faccia il lifting necessario. Il fatto che Spring sia maneggiabile non significa che JAAS non sia complicato. Tra l'altro se googli e' quello che viene detto in giro anche da esperti.

Post by rootkit

Post by l***@gmail.com

Post by rootkit
conosco poco la parte standard, se non quella che è comune con il
framework che uso, ma direi che la filosofia che sta dietro al jee è
nota: java ti da le interfacce, poi l'implementazione è del singolo
container. vale anche per la login: va bene l'implementazione del
container? se sì, allora ce l'hai gratis, altrimenti bisogna mettersi
di buzzo buono e implementare il proprio.

Cioe' andare di filtri o importare Shiro e Picketlink. Che poi non e'
vero quanto dici: JSF e' uno standard e definisce tutto nei minimi
particolare. Lo stesso vale per una serie di altre sottospecifiche. E'
proprio quella per l'autenticazione che e' lasciata alla fantasia piu'
totale.

scusa, senza polemica ma per capire: cosa c'entra jsf con
l'autenticazione?

Stavo semplicemente facendo un esempio di una specifica JEE che non ha i problemi di JAAS.

Post by rootkit
e cosa c'è di male a usare librerie aggiuntive, se queste ti offrono le
funzionalità che desideri?
e cosa vuol dire "l'autenticazione che è lasciata alla fantasia più
totale"? devi implementare un loginmodule che consta di *un* metodo, mica
sbizzarrirti di fantasia. se non basta (anche se ancora non ho compreso
il motivo) niente vieta di cercarsi la libreria che meglio "fitta" le
esigenze. figuriamoci, penso di aver trascorso metà del mio tempo a
valutare fra librerie java, moduli di node, framework front-end, build
tools, etc... scusami se non concepisco il tono da melodramma.

Devi implementare un LoginModule (si ma poi come si integra con lo strato web, dove dici qual'e' la pagina di autenticazione, come gestisci i casi di success e non? mi pare che qui Spring diverga completamente da JAAS) perche' appunto usi una libreria esterna.

Che male c'e' a richiedere una libreria esterna? E' come chiedersi che male c'e'a non avere uno standard. La risposta la sai gia'.

Ad esempio, quando usi JAX-RS mica devi aggiungere librerie di implementazione nel pom (e se lo fai la dichiari solitamente provided perche' e' gia' nell'AS). Nel caso di JAAS non funziona cosi'. E' evidente che qualcosa di diverso c'e'.

Post by rootkit

Post by l***@gmail.com

Post by rootkit
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.

Non sono d'accordo: in JSF (framework standard eh) non e' un problema
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...

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.

[rootkit]

Post by l***@gmail.com
Che male c'e' a richiedere una libreria esterna? E' come chiedersi che
male c'e'a non avere uno standard. La risposta la sai gia'.

sì la so già, non c'è niente di male.
nodejs non ha uno standard, python non ha uno standard.
in javase c'è il logging system, che però non usa nessuno.
e vogliamo parlare della libreria per gestire le date pre-jdk8?
ma potrei proseguire per ore elencando librerie della community che
vengono regolarmente utilizzate per implementare/migliorare le api
standard, dalle varie apache-* fino a guava passando per lombok e joda.

Post by l***@gmail.com
Ad esempio, quando usi JAX-RS mica devi aggiungere librerie di
implementazione nel pom (e se lo fai la dichiari solitamente provided
perche' e' gia' nell'AS). Nel caso di JAAS non funziona cosi'. E'
evidente che qualcosa di diverso c'e'.

ciò che è diverso è che uno fa parte delle specifiche della standard
edition, l'altro dell'enterprise.

Post by l***@gmail.com

Post by rootkit
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...

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.

direi molto, molto opinabile.

[l***@gmail.com]

Post by rootkit

Post by l***@gmail.com
Che male c'e' a richiedere una libreria esterna? E' come chiedersi che
male c'e'a non avere uno standard. La risposta la sai gia'.

sì la so già, non c'è niente di male.
nodejs non ha uno standard, python non ha uno standard.
in javase c'è il logging system, che però non usa nessuno.
e vogliamo parlare della libreria per gestire le date pre-jdk8?
ma potrei proseguire per ore elencando librerie della community che
vengono regolarmente utilizzate per implementare/migliorare le api
standard, dalle varie apache-* fino a guava passando per lombok e joda.

Stai dicendo che non c'e' alcun valore nell'avere uno standard per caso?
Perche' che sia fattibile lavorare senza mi pare evidente e inutile ribadirlo.

Post by rootkit

Post by l***@gmail.com
Ad esempio, quando usi JAX-RS mica devi aggiungere librerie di
implementazione nel pom (e se lo fai la dichiari solitamente provided
perche' e' gia' nell'AS). Nel caso di JAAS non funziona cosi'. E'
evidente che qualcosa di diverso c'e'.

ciò che è diverso è che uno fa parte delle specifiche della standard
edition, l'altro dell'enterprise.

E quindi? Infatti il problema sta proprio li'. Ma il problema esiste, nonostante tu continui a negarlo.
La specifica non e' nata per JEE, e per questo motivo risulta overcomplicated per applicazioni web.

Post by rootkit

Post by l***@gmail.com

Post by rootkit
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...

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.

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.

[rootkit]

Post by l***@gmail.com

Post by rootkit

Post by l***@gmail.com
Che male c'e' a richiedere una libreria esterna? E' come chiedersi
che male c'e'a non avere uno standard. La risposta la sai gia'.

sì la so già, non c'è niente di male.
nodejs non ha uno standard, python non ha uno standard.
in javase c'è il logging system, che però non usa nessuno.
e vogliamo parlare della libreria per gestire le date pre-jdk8?
ma potrei proseguire per ore elencando librerie della community che
vengono regolarmente utilizzate per implementare/migliorare le api
standard, dalle varie apache-* fino a guava passando per lombok e joda.

Stai dicendo che non c'e' alcun valore nell'avere uno standard per caso?

se me lo chiedi ti rispondo: come programmatore di prodotto finale
utilizzare una implementazione standard piuttosto che una non standard
non mi porta alcun intrinseco valore aggiunto.

Post by l***@gmail.com
Perche' che sia fattibile lavorare senza mi pare evidente e inutile ribadirlo.

appunto.

Post by l***@gmail.com

Post by rootkit
ciò che è diverso è che uno fa parte delle specifiche della standard
edition, l'altro dell'enterprise.

E quindi? Infatti il problema sta proprio li'. Ma il problema esiste,
nonostante tu continui a negarlo.

no io non nego, al limite non condivido. mica vengo a dire che tu non
abbia il problema...

Post by l***@gmail.com

Post by rootkit

Post by l***@gmail.com
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.

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.

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.

[M C]

Post by rootkit
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.

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...

[l***@gmail.com]

Post by M C

Post by rootkit
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.

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.

Mai scritto infatti che conviene usare JSF sembre e comunque. Sottointeso quindi che ho provato le librerie client side (Angular, React). E devo dire che le apprezzo.

Comunque JSF non e' affatto morto, non so in base a cosa tu ti sia fatto quest'idea. Ad esempio PrimeFaces e' una libreria usatissima.

Post by M C
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...

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.