Syntax Highlighter

Io penso che funzioni!

Inserire del codice nel blog

Orbene,

quelle tre persone che leggono questi articoli (1 è Facebook, 1 è Twitter, quindi rimango solo io...), si saranno accorte che quando ho postato del codice HTML o Xml è successo sempre un bel po' di casino.

Ho quindi cercato un modo alternativo di inserire codice HTML su Blogger.

E la soluzione eccola qua!

Un bel po' di JavaScript che consentono molto facilmente di embeddare il codice Xml/HTML.

Stasera ci provo, vediamo che succede...

Spring Security: personalizzare l'authentication provider

Abbiamo già visto come gestire la sicurezza con Spring Security.
Come avevamo visto il framework si basa su una logica di authentication-manager, authentication-provider. Ci sono già alcune implementazioni pronte: molto comoda è quella in memoria, specialmente per il testing.
Altra implementazione "comoda" è quella JdbcDao. Il limite di questa implementazione è che il db da cui pescare i dati deve per forza essere fatto in un certo modo, anche se si possono specificare le query da eseguire, ma la flessibilità non è al 100%.
Mi sono quindi detto: proviamo ad implementare il mio provider.
Devo implementare l'interfaccia AuthenticationProvider che ha un unico metodo authenticate
Il metodo deve verificare che l'utente si possa autenticare e restituisce un oggetto Authentication, che porta con se lo username e le GrantedAuthority a cui appartiene, praticamente i ruoli dell'utente.

Vediamo un po' di codice...

public Authentication authenticate(Authentication auth) throws AuthenticationException {
        String username = auth.getPrincipal().toString();
        String password = auth.getCredentials().toString();
        if (!"Andrea".equals(username))
            throw new BadCredentialsException("Nome Utente non valido!");
        if (!"Andrea".equals(password))
            throw new BadCredentialsException("Password Errata!");
        Collection gas = new ArrayList();
        GrantedAuthority ga = new AndreaGrantedAuthority("G1");
        gas.add(ga);
        UsernamePasswordAuthenticationToken result = new UsernamePasswordAuthenticationToken(username, password, gas);       
        return result;
    }


La cosa veramente da notare e che, lo confesso, mi ha un po' spiazzato, sono le prime 2 righe, cioè il reperimento di username e password.
Soprattutto la password non era lampante. Poi, studiando un po' di teoria, ho visto che siamo nello standard. L'oggetto Authentication viene passato in ingresso e, se tutto va a buon fine, ne viene rilasciato un'altro in uscita. Nel mio caso ho usato un UsernamePasswordAuthenticationToken, che è già a corredo del framework.
Per dare i ruoli all'utente ho usato una classe AndreaGrantedAuthority che implementa l'interfaccia GrantedAuthority.
Questa classe deve essere poi dichiarata come
security:authentication-provider ref="myAuthenticationProvider"
il tag ref indica che ci dovrà essere un bean spring fatto + o meno così

bean id="myAuthenticationProvider" class="it.andrea.AndreaAuthenticationProvider"

E' ovvio quindi che questo bean è perfettamente integrato in Spring: é quindi possibile iniettare SessionFactory e quant'altro ci possa servire per il reperimento dei dati dell'utente: io per brevità non lo ho fatto ma posso assicurare che funziona.

Da dire che così il gioco non può funzionare, perchè il nostro provider vuole anche uno UserDetailService al quale chiedere com'è fatto l'utente. Infatti il provider si è solo chiesto se l'utente era abilitato o no, non quale fosse in dettaglio il suo profilo.

Per lo UserDetailService mi riprometto di scrivere un nuovo articolo.

Perchè Java va bene per lo sviluppo on line "di base"

L'autore,
che è italiano e vive a Firenze come me, mi perdonerà questa traduzione all'impronta del titolo del suo post.
Mi piace il suo punto di vista: è vero, si possono anche fare le cose molto complicate in Java, ma si può anche iniziare in maniera molto semplice. Poi a complicar le cose c'è sempre tempo, come per aggiungere Unit Testing e quant'altro. E poi la cosa + importante: Java è VERAMENTE una V.M. multipiattaforma, stabile ed affidabile, e questo fa ben la differenza...

Linee guida per la codifica in Java

Ultimamente, forse spinto da eccesso di pignoleria, sono andato a cercarmi le convenzioni per la codifica in Java.
Eccole qua, fresche fresche (sono solo targate 1999) da Sun
Proverò ad usarle....

Veicolare le informazioni su più piattaforme

Io ho, come tante persone, oltre a questo blog, sia Facebook che Twitter.
Finora, a manina, andavo su entrambe le piattaforme e postavo i link al blog.
Devo dire che, con un post al giorno o giù di lì, (a parte la piccola interruzione recente), dopo un po' diventa noioso fare copia incolla.
Negli ultimi giorni mi sono quindi messo alla ricerca di un qualcosa che lo facesse al posto mio, ed ho trovato TwitterFeed
Devo dire che è ben fatto: si occupa lui di pubblicare per mio conto i post che scrivo qui, su varie piattaforme (le già citate Facebook e Twitter ma anche Laconica, Ping.fm e Hellotxt)
Su twitter fra l'altro può utilizzare anche una serie di servizi per creare short links (bit.ly di default), cosa molto comoda visto il limite delle 140 battute.
Si può impostare la frequenza di aggiornamento (1 volta al giorno per me, più frequente per i grafomani) ed i tag da mettere al messaggio.
Visto poi l'interfacciamento con ping.fm e Hellotxt allora si può pensare di mettere in cascata la pubblicazione su tante e tante piattaforme.
Tutto qua, buon divertimento.

Google Web Toolkit 2.0

Cavolo,

uno si distrae un attimo e il mondo va avanti!

Proprio oggi mi sono accorto che è uscita la versione 2.0 del Google Web Toolkit.

Secondo me la cosa più eclatante di questa versione, a parte probabilmente la velocità, sempre maggiore, è l'introduzione della uiBinder.

In pratica si possono dichiarare interfacce grafiche attraverso l'xml, e non più soltanto da codice.

Bella spinta alle interfacce Gui, non pensate?

Finalmente il telefonino Google

http://www.tomshw.it/cont/news/google-nexus-one-ecco-le-nuove-immagini/23190/1.html

Spring Security: primi approcci

Recentemente ho avuto il piacere, chiamiamolo così, di imbattermi in Spring Security.
Spring Securiry è la soluzione di Spring per "mettere in sicurezza" una web application.
La prima cosa da fare è aggiungere un filtro nel web.xml,
usando la classe org.springframework.web.filter.DelegatingFilterProxy
ed intercettando con quella tutte le chiamate, come ben spiegato qui.
La classe sopra citata è il wrapper che intercetta tutte le chiamate.
Per configurarlo è sufficiente editare l'ApplicationContext file: in questo modo ci si riallaccia al meccanismo di gestione di Spring per le web Application.
Scorrendo la documentazione sopra citata si vede che una minima configurazione prevede il tag http. Ora, secondo le specifiche dei files di configurazione di Spring, questo non è possibile. La spiegazione è che, semplicemente, si è usato come default namespace il tag security invece che il tag beans
Se si vuole continuare ad usare il tag beans come default, la dicitura http è da intendersi come security:http
All'interno del tag http è sufficiente specificare authentication-manager ed authentication-provider da usare. Questi due definiscono le regole con cui un utente viene riconosciuto dal sistema.
Authentication-manager contiene la lista dei provider che gestiscono il meccanismo di autenticazione. In pratica si può creare una catena di autenticazioni, ad esempio da database, via LDAP, in memoria, dove ogni authentication-provider implementa la propria logica per dire se è possibile autenticare un utente all'interno del sistema.
Ogni authentication-provider ha uno user-service, cioè un meccanismo che definisce qual'è il profilo dell'utente all'interno dell'applicazione.
Diciamo che i primi approcci su spring-security si fermano qua: interessante sarà analizzare quali sono gli authentication-provider e gli user-service già inclusi nel pacchetto e come fare a crearsi i propri.

Traduzione in inglese qui