Archive | Web development RSS for this section

sphinx and WARNING: DOCID_MAX document_id, skipping

This error seems to wake-up with large ids >100.000.000 (like Ruby On Rails fixtures sys does).
Ok, like Piotr Jasiulewicz says this error appears because the sphinx was built without the –enable-id64 option.

Let’s go to solve this problem in Debian (note: I assume you use mysql, if not you have to change some dependencies packages).

Update 2012-05-31: this post refers to Debian Lenny i386. I don’t know if the binary package of Debian Squeeze (other distros, versions, architectures) is compiled with the same compile options at the moment. Anyway this post is intended to solve the specific warning (or to suggest a solution just in case you use another distro/architecture) .

Move to your preferred source folder (for example ~/src) or create it. Move to root user with su.
Download debian’s sphinxsearch sources:

#apt-get source sphinxsearch

Give permissions to your user on sphinxsearch files.

#chown -R youruser:youruser sphinxsearch*

Install mysql dev packages:

#apt-get install libmysqlclient-dev libmysqld-dev

Exit from root and return to your user. Enter in source folder of sphinxsearch (may vary with versions), configure with proper flags and make.

#exit
$cd sphinxsearch-0.9.9
$./configure –enable-id64
$make

Please note that pgsql is disabled by default and you should take a look at configure options (./configure –help) to see if you need others options, I don’t (except for libstemmer but I ignore this here).

Ok. If all was ok at make/compile time you can move on installation.

Move to root user with su (uninstall debian sphinx package if needed) and install.

#apt-get remove sphinxsearch
#make install

That’s all. Happy Sphinx On Ruby On Rails with fixtures 🙂

Advertisements

ruby on rails on nokia N900

Yes, we can! ruby on rails works well on nokia n900.
Install ruby from maemo repository (dev).
Download and install rubygems (use –no-rdoc and –no-ri).

Rubygems creates only /usr/bin/gem1.8 so you should create a soft link like this: ln -s /usr/bin/gem1.8 /usr/bin/gem

Type gem install rails -V and wait.

Now you are ready to start your rails app on nokia n900!
Just run ruby script/server in your project folder. To create a project folder use rails my_app as usual.

Your server may not start if you miss libopenssl-ruby. In this case you get an error about net/https: apt-get install libopenssl-ruby.

rails date validation, rails validate date for date_select

Ok, you are in right place if you need to validate a date from date_select helper.
Expecially if your problem is an invalid date like ’31/02/2009′  that becomes ’02/03/2009′ on rails!
If you don’t want to waste your time read here and don’t go immediatly to rails date validation plugin .

validates_timeliness plugin introduces a lot of great features to validate a date but its documentation is not so cool (this is my absolutely wrong opinion). You have to read it completly or take a look here about 3 important points:

  • I18n
    if you don’t use :en locale you have to implement validates_timeliness default translation in your translations file (for ex. config/locales/it.yml) or you will waste your time to debug stupid exceptions. Default plugin translation file can be found in vendor/plugin/validates_timeliness/lib/validates_timeliness/locale after installation;
  • Validate invalid date (like 31/02/2009 becomes 02/03/09) from select helpers
    You need to know that validates_timeliness doesn’t fix this problem automatically as you expect!
    You have to manually enable validates_timeliness workaround if you need to validate invalid date on rails.
    Put ” ValidatesTimeliness.enable_datetime_select_extension! ” your environment.rb (EOF) to enable validate_timeliness workaround and catch bad dates.
    Note: Patch to ticket #10556 introduced this problem: rails accepts invalid dates from input (instantiate Time object and convert it back to a date).  This problem generates a lot of confusion, checks on controllers, horrible workarounds and so on… A valid reason seems to exist! But WTF!!! People in panic and code with consistency problems…

Any other information (and download) can be find on validates_timeliness at github.

Have a nice day!

 

validates_timeliness

lighttpd, fcgi, rails and child exited with status 9, 1, 2, 3 or X

Ok, these errors are not good. They didn’t tell much about what happended.
But you can’t do as I did. Don’t wander on the dark side of the system…
Just try to execute your FCGI as your lighttpd did.
Find your lighttpd user in lighttpd configuration file (debian: /etc/lighttpd/lighttpd.conf).
On my configuration I see:
server.username  = “www-data”

so…

$ su
# cd /my_rails_root/public
# sudo -u www-data ./dispatch.fcgi

Read what’s happen and solve.
That’s all!

Validazione Codice fiscale Partita IVA con Ruby / Ruby On Rails

Cercando di validare codice fiscale e partita iva con Ruby, sono capitato nel sito di Umberto Salsi, dove si parla della validazione di Partita Iva e Codice Fiscale.

Visto che l’implementazione in Ruby non era disponibile ne ho realizzata una che ho già inoltrato all’autore della pagina perchè possa aggiungerla all’elenco.

Nel frattempo comunque, le due classi che ho preparato sono disponibili per il download.

Il codice Ruby che ho realizzato per eseguire i check di validità su codice fiscale e partita iva non è corredato da alcuna garanzia, potrebbe causare la morte di migliaia di persone, l’incendio del vostro PC, il mutamento del vostro orientamento sessuale, ma in nessun caso potrete ritenermi responsabile. Usatelo a vostro rischio e pericolo! 🙂

Scarica la validazione Ruby di codice fiscale e partita iva

updated (16/11/2009) – nuova versione con licenza GPL inclusa, descrizione, eccezioni e qualche miglioria

L’utilizzo è molto banale e potete riutilizzare, modificare e redistribuire il codice a vostro piacimento per qualsiasi utilizzo.

Un banale esempio di utilizzo per il codice fiscale:

require 'codice_fiscale'
if CodiceFiscale.valid?('ILTU0C0D1C3FISCAL3')
puts 'il codice fiscale è valido!'
else
puts 'il codice fiscale non è valido!'
end

Un banale esempio di utilizzo per la partita iva:

require 'partita_iva'
if PartitaIva.valid?('02030405060')
puts 'la partita iva è valida!'
else
puts '
la partita iva non è valida!'
end

Sull’opportunità o meno di utilizzare la validazione, vi consiglio di leggere il capitolo “Miti, superstizioni e falsità” sul sito di Umberto Salsi a proposito della validazione del codice fiscale. A tal proposito riporto riassumendo il concetto: usate la validazione ma non sempre è attendibile, potrebbe dare dei falsi negativi, bloccando per esempio la registrazione di utenti legittimi. Viceversa gli utenti malintenzionati potrebbero fabbricarsi in pochi secondi un codice fiscale falso (ma corretto) attraverso uno dei tanti servizi online. La validazione del codice fiscale risulta quindi utile solamente se si vuole eseguire un controllo formale per evitare errori di battitura, ma è solamente controproducente se si cerca con questo mezzo di tener lontano qualcosa e/o qualcuno.

Per quanto riguarda la partita iva vale quanto detto a proposito del codice fiscale.
Tuttavia ho individuato un bel webservice per la validazione delle partita iva messo a disposizione dell’Unione Europea e denominato VIES VAT number validation. Il wsdl e maggiori informazioni sul servizio potete trovarle nelle Faq. Il servizio peraltro funziona, l’ho provato oggi, ed è pure gratuito e discretamente veloce. Interroga i database dei paesi dell’Unione quindi è in grado di fornire validazione anche per le altre partite iva europee. Va sottolineato che non si limita a fare la validazione formale, ma da quanto si apprende attraverso le Faq è anche in grado di verificare se la partita iva esiste realmente ed è attiva. Per alcuni paesi inoltre, fornendo la partita iva, oltre a verificare se esiste ed è disponibile, vengono forniti anche alcuni dati utili sull’azienda tra cui nome ed indirizzo (l’italia è ovviamente esclusa da questa chicca).

Se qualcuno è interessato può scaricare la ruby class for VIES VAT number validation che ho realizzato per un applicativo su base Rails. Per altri usi dovete chiaramente adattarla, ma fa il suo dovere. Ricordate di copiare i wsdl in locale, è una scelta preferibile.

Buona giornata!

Attacco poste.it – Hacker defacciano il sito di Poste Italiane

Apprendo la notizia che il sito di Poste Italiane è stato defacciato. A questo punto il messaggio apparso a seguito dell’attacco al sito poste.it non può che essere condiviso .
Sabato 10/10/2009 alle ore 19:00 alcuni hacker (o forse uno soltato) hanno violato i sistemi di Poste Italiane con un attacco informatico.

A stretto giro di ruota subentra un sentimento di frustrazione. Le comunicazioni di Poste Italiane ci descrivono una situazione tranquilla, ma questi comunicati  non riescono a lenire il disappunto. Come al solito i comunicati stampa ed i messaggi inviati dai media in casi come questi non possono che essere rassicuranti.
Dicono: “Il sito poste.it ha subito un defacement, ma ne avvengono migliaia ogni giorno” – mal comune, mezzo gaudio, o no? – e subito dopo affermano che “comunque tutti i dati sono al riparo, nessuna fuga di informazioni, nessun reale pericolo” ed ancora usano paroloni roboanti per rassicurarci, cose come “le squadre di ingegneri delle control room”.

Sì!  Ma nel frattempo Mr.Hipo e StutM sono già penetrati nei loro sistemi, hanno defacciato la home page del sito, ed hanno anche lasciato un messaggio eloquente. Il sito poste.it, incluso nella top 50 dei siti italiani, dove ogni giorno milioni di utenti inseriscono le loro credenziali d’accesso – e senza considerare la natura dei servizi offerti -, è stato violato (ownato, o posseduto per chi non ama l’inglese).

una delle tante immagini del defacement

una delle tante immagini del defacement

Mr.Hipo e StutM lasciano un messaggio dove spiegano a modo loro le ragioni di questo attacco brutale.

Dicono che non hanno “toccato” gli account degli utenti e di non essere malintenzionati. E lanciano una domanda agli utenti di poste.it (il sito attaccato): “Cosa succederebbe se un giorno arrivasse qualcuno con intenzioni ben peggiori delle nostre?”.  Già, che cosa succederebbe?
Secondo Poste Italiane “il defacement è un’azione dimostrativa abbastanza comune” con un attacco di questo tipo non è il caso di preoccuparsi “è solo un ‘defacement’ che riguarda il sito informativo di Poste.it”, non accade assolutamente nulla, nessun pericolo, succede migliaia di volte al giorno anche ad altri siti – lo definiscono “fisiologico” – ed escluso il disagio arrecato ai suoi clienti/utenti per la sospensione del servizio – almeno questo appare innegabile – non ci sono conseguenze degne di nota, ne motivo di preoccupazione.

Purtroppo mi sento di dissentire.
Apprendo con amarezza in un articolo sul sito Repubblica.it che “il sito di Poste.it è stato sfregiato dai pirati. Dopo 30 minuti i responsabili se ne sono accorti e hanno messo il sito offline, rendendolo quindi non più raggiungibile dagli utenti” (aggiornamento: il comunicato ufficiale su poste.it parla di “pochi minuti“).
A mio parere è inquietante che, anche solo per un attimo, il defacement sia rimasto visibile agli utenti. Un sito come poste.it per la natura dei servizi che offre, per il numero delle utenze e non ultimo per il fatturato di Poste Italiane dovrebbe essere dotato di un IDS adeguato, cioè di un sistema in grado di analizzare, rilevare e rispondere ad eventuali intrusioni per esempio assicurandosi che le pagine siano sempre coerenti e prive di alterazioni non autorizzate. Un IDS per intendersi non è una persona che tra un caffè ed un cornetto ricarica la pagina per assicurarsi che non ci siano modifiche, ma un sistema software/hardware molto sofisticato, in grado di rilevare un defacement nell’esatto istante in cui si verifica, se non addirittura in anticipo – dato che peraltro rilevare un defacement è tecnicamente un operazione semplicissima.

Leggo invece che l’intrusione è stata rilevata dopo 30 minuti (“pochi minuti” secondo la ricostruzione ufficiale) e che ad accorgersi del fatto sono stati “i responsabili”. Se i tempi fossero veramente questi (ovvero 30min tra il defacement e la rilevazione), come riporta La Repubblica, credo che sia il caso di allibirsi. 30 minuti indicano che con probabilità quasi assoluta ad identificare il defacement sono stati per primi gli ignari utenti del sito. Le immagini sul defacement che girano nella rete, e sono ognuna diversa dall’altra, mi segnalano che in molti hanno visto la pagina defacciata e questo sembra avvalorare peraltro l’ipotesi sconcertante citata senza particolari accenti da Repubblica.it.
Ad ogni modo anche i “pochi minuti” citati della ricostruzione ufficiale non riescono a rasserenarmi.

“Hacked – stavolta siamo stati buoni ma possiamo fare molto di più”

Così titolano in molti, eppure a vedere le immagini che girano in rete il messaggio che hanno lasciato Mr.Hipo e StutM non è certo questo. Ma si sà, i miracoli del giornalismo d’assalto ed i suoi piloti se ne fregano se le informazioni che passano sono corrette. Con un titolo simile a quello riportato pare che  l’obbiettivo fosse minacciare, terrorizzare. Ma è davvero così? Questo mi spinge ad una riflessione. Dal canto suo Poste Italiane, nella comunicazione ufficiale su poste.it, riassume dicendo che il messaggio lasciato dal defacement è “una nota in cui gli hacker spiegavano che si trattava di un’azione dimostrativa”.

Mr.Hipo e StutM sono in buonafede? Non ci è dato saperlo. Potrebbero aver mentito nel messaggio lasciato. Di fatto potrebbero anche aver violato le informazioni sugli account e non averlo detto, anzi potrebbero aver detto di non averlo fatto proprio con l’intento di coprire l’operazione.
Ma Poste Italiane dice di no, dice che i dati sono al sicuro e dopo l’intervento della Polizia Postale, risulta che questo è vero. Fidiamoci, non è possibile che siano così irresponsabili da negare una fuga di dati/credenziali, esponendo i propri utenti a gravi conseguenze future e l’intervento della Polizia Postale deve rassicurarci.
Tuttavia appare altrattanto vero che Mr.Hipo e StutM (gli hacker che hanno violato e defacciato il sito poste.it) hanno dichiarato l’attacco rendendolo pubblico (almeno al momento della sua conclusione) ed hanno lanciato anche un messaggio. Molto probabilmente, se fossero stati malintenzionati, avrebbero evitato di dichiarare l’attacco ed avrebbero adottato tecniche per camuffarsi ed evitare di far individuare la loro intrusione, anche in futuro. Invece si sono dichiarati.

“Cosa succederebbe se un giorno arrivasse qualcuno con intenzioni ben peggiori delle nostre” a defacciare Poste.it? – Già, che cosa succederebbe?

Difficile dirlo con certezza, ma per ipotesi potrebbe accadere che:

  • non sarebbe inserito uno sfondo nero, con un immagine molto esplicativa, dichiarando l’attacco
  • sarebbero modificate solo piccole porzioni di codice sulla pagina senza conseguenze di tipo estetico
  • i dati inviati dagli utenti, per esempio attraverso il modulo di autenticazione, sarebbero inviati a siti esterni o comunque entrerebbero in possesso degli intrusi; ignari utenti (provabilmente decine di migliaia) inserirebbero il proprio nome utente e la propria password rendendola nota a chi ha effettuato l’attacco
  • le alterazioni scomparirebbero dopo 10-15 minuti, molto meno dei 30 minuti serviti ai “responsabili” per rilevare l’intrusione e chiudere il sito poste.it – in base a quanto citato da Repubblica.it oppure dei “pochi minuti” citati dal comunicato ufficiale di Poste Italiane

Sempre secondo un simile scenario ipotetico, il database di Poste Italiane potrebbe rimanere immacolato com’è avvenuto in questo episodio, ma in via ipotetica potrebbero non rendersi conto dell’attacco.
Ma quello che più ci interessa è il possibile danno alla privacy degli utenti in un simile scenario ipotetico. Potrebbe essere gravissimo: account in mano a chissà chi, assieme a tutti i dati a disposizione con gli accessi sottratti (numeri di conto, movimenti, estratti conto, email, ecc.), perlomeno per un breve tempo o anche indefinitamente nel caso fosse impossibile ricostruire quali dati sono stati sottratti e bloccare gli account a rischio.
Ecco, ora sappiamo quello che potrebbe ipoteticamente accadere semplicemente modificando la stessa pagina alterata da Mr.Hipo e StutM dove difatti il modulo di autenticazione (form) sopra citato risiede.

A questo punto dovremmo chiederci:  Mr.Hipo e StutM invece di lasciare un messaggio, come hanno fatto, potevano veramente fare di peggio o il loro è solo un bluff? Sono dei criminali perchè hanno violato la legge, ma ciò che dicono è vero oppure è falso, pongono un problema reale o vogliono solo gettare discredito? Non sono io a poter dare una risposta certa a queste domande, ma vale la pena di formarsi un opinione e ricercare una risposta. Fate vobis.

Il comunicato ufficiale pubblicato su poste.it

sanitize inline css with rails

Hi! You can simply use the sanitize(…) helper in your views to whitelist allowed tags and attributes… but what to do if you need to sanitize the content of a style attribute?  I found a solution to sanitize inline css with rails. This may not be the best solution available, but I didn’t find another solution (like an argument for sanitize helper).

Put this code in your config/enviroment.rb

# ALLOWED CSS PROPERTIES 
HTML::WhiteListSanitizer.allowed_css_properties = Set.new(%w(text-align font-weight text-decoration font-style))
# ALLOWED CSS PROPERTIES - acts like property_name-*, for example `text` allows text-align, text-deco...
HTML::WhiteListSanitizer.shorthand_css_properties = Set.new(%w())

Remember to restart your application, enviroment.rb must be reloaded also in development mode.

Have a nice day!