iBaffiPro ha scritto:
1) È possibile configurare Spring Security in modo che i nomi per i ruoli non debbano necessariamente iniziare con "ROLE_"? Dovrei editare ConfigurazioneSpringSecurity che estende WebSecurityConfigurerAdapter oppure dovrei modificare tante altre cose della mia WebApp?
Sicuramente sì, si possono cambiare, perché mi era già capitato di leggere qualcosa a riguardo (ma non ricordo dove). Ma non ti so dire più, dovresti vedere la reference ufficiale o fare qualche ricerca.
iBaffiPro" post_id="8675918 ha scritto:
2) È possibile decidere di non inserire nel file .war la classe contenente i test e la classe CrittografarePassword.java che oltre a non servire possono contenere delle informazioni non proprio bellissime. CrittografarePassword.java è una classe con un metodo main() che mi permette di ottenere la password crittografata dell’utente più importante dell’applicazione.
Le classi di test (src/test/java/****) già di norma NON vanno a finire nel package finale (jar, war o altro che sia). Eventualmente solo le classi di test possono essere impacchettate in un jar apposito ma è una cosa che si fa raramente.
Se si vuole escludere una risorsa (classe o altro) dal war, si configura il
maven-war-plugin (ecco un caso in cui va esplicitato nel pom) usando il
<packagingExcludes> .
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<packagingExcludes>WEB-INF/classes/nome/del/package/NomeClasse.class</packagingExcludes>
</configuration>
</plugin>
Deve essere proprio così il path, come sarebbe strutturato nel war. Più path sono separati dalla virgola. E la documentazione dice che si possono anche usare le Regular Expressions.
Verifica poi naturalmente il contenuto del war!
iBaffiPro" post_id="8675918 ha scritto:
3) È possibile non inserire nel file .war la cartella INFO-WEBAPP con tutto quello che c'è dentro dove salvo note personali che non vorrei mettere sul server (descrizione webapp, procedura per caricare l’app su un IDE, dispense, PDF, ecc…).
Se definisci cartelle in locazioni che NON sono note a Maven/IDE, non c'è nessun problema. Se ad esempio al livello di src metti es.
src\*****
note\*****
sql\*****
Maven e l'IDE non "sanno" nulla di
note e
sql, nessun contenuto di queste finirà mai di per sè in un package finale, né verrà usato a runtime. Restano solo nel tuo progetto.
iBaffiPro ha scritto:
4) Come faccio a verificare cosa accade quando scrivo un carattere che non sia in UTF-8 nel form di registrazione e quindi essere certo che la webapp non crolli inesorabilmente e si raggiunga la pagina error.html di Thymeleaf?
Caratteri sballati in un form comunque in generale NON fanno fallire una request. Mal che vada le stringhe che il backend riceve sono appunto sballate (se poi il BE schianta per quello è un altro discorso ...).
Queste questioni sull'encoding, specialmente per i dati che vanno da client (browser) a server sono sempre un po' spinose. Assicurati che la pagina sia scritta e dichiarata in UTF-8. Prova a mettere in un form un classico es. áéíóú , verifica con i developer tool del browser che la POST abbia il body corretto e sul BE in debugging verifica lo String che ti arriva. Se vedi "áéíóú" ragionevolmente non ci sono casini. Se invece vedi altro .....
E testa con più browser.
iBaffiPro ha scritto:
5) Nella classe di test quali test potrei/dovrei fare prima di procedere con il resto dell’applicazione? Dovrei simulare la registrazione di un utente? Come si fa questa operazione?
Per i test le possibilità sono molto ampie. Dipende molto da cosa vuoi testare, cioè da dove partire "di sopra", fino ad arrivare a che livello "di sotto" e quindi mockando che cosa.
Se hai la classica struttura controller -> service -> dao, puoi testare con unit test solo lo strato di controller, solo lo strato di service o entrambi (che diventa più un "integration" test dato che spanna due strati). Generalmente il dao nei test diventa un "mock" fittizio, NON si va normalmente su una base dati reale. Cioè sì, si può fare ma come forse ti avevo già detto, testare su una base dati persistente è più critico e ci vogliono più accorgimenti per rendere davvero i test indipendenti tra di loro.