#!/usr/bin/perl
use DBI;
my $host = '127.0.0.1';
my $url = 'jdbc:Cache://127.0.0.1/SOURCE';
my $dbo = DBI->connect("dbi:JDBC:hostname=$host;port=9001;url=$url", 'username', '***')
or die $DBI::errstr;
my $qry = $dbo->prepare("select * from custom.table");
$qry->execute();
print "Structure of $table \n\n";
my $num_fields = $qry->{NUM_OF_FIELDS};
for (my $i=0; $i< $num_fields; $i++) {
my $field = $qry->{NAME}->[$i];
my $type = $qry->{TYPE}->[$i];
my $precision = $qry->{PRECISION}->[$i];
print "$field, $type, $precision\n";
}
$qry->finish();
weRock
09/gen/2013
Obtain name, type and precision for columns in DBI
I had to find the structure (name, type, and precision for every column) of a table, connected via JDBC using DBI, and this is how I did it:
15/ott/2012
Nuova SIM e controlli di sicurezza vodafone
Causa acquisto nuovo cellulare, che richiede la Micro-SIM, e causa taglio artigianale SIM non andato a buon fine, mi reco ad un vodafone point per richiedere una nuova Micro-SIM funzionante.
L'operatrice mi richiede il cartellino con il codice fiscale.
Poi mi chiede il numero di telefono che scrivo su di un post-it.
Poi mi consegna, gratuitamente, la nuova Micro-SIM, già immediatamente funzionante.
Hey! Ma l'operatrice non mi ha chiesto carta d'identità o passaporto, nemmeno la patente, ed il codice fiscale non è un documento di riconoscimento, non ha la foto, non ha nessun sistema di sicurezza (PIN, Microchip, RFID, o quant'altro) ed è semplicemente riproducibile.
Senza controlli aggiuntivi, chiunque può richiedere una nuova SIM a nome di chiunque altro....!
L'operatrice mi richiede il cartellino con il codice fiscale.
Poi mi chiede il numero di telefono che scrivo su di un post-it.
Poi mi consegna, gratuitamente, la nuova Micro-SIM, già immediatamente funzionante.
Hey! Ma l'operatrice non mi ha chiesto carta d'identità o passaporto, nemmeno la patente, ed il codice fiscale non è un documento di riconoscimento, non ha la foto, non ha nessun sistema di sicurezza (PIN, Microchip, RFID, o quant'altro) ed è semplicemente riproducibile.
Senza controlli aggiuntivi, chiunque può richiedere una nuova SIM a nome di chiunque altro....!
Etichette:
sicurezza
12/lug/2012
PDF firmati digitalmente... alcuni appunti
Come gestire un PDF firmato digitalmente:
http://www.egov-pa.it/component/content/article/7-articoli/firma-digitale/11-come-gestire-un-pdf-firmato-digitalmente.html
deploy delle impostazioni di sicurezza:
http://blogs.adobe.com/pdfitmatters/2010/02/deploying_acrobat_to_import_se.html
come esportare/importare le opzioni di sicurezza:
http://learn.adobe.com/wiki/download/attachments/52658564/acrobat_reader_security_9x.pdf#page=37
okay non è un vero post, sono solo degli appunti che mi servono... intanto lo pubblico, poi se sarà... scriverò un articolo più completo.
http://www.egov-pa.it/component/content/article/7-articoli/firma-digitale/11-come-gestire-un-pdf-firmato-digitalmente.html
deploy delle impostazioni di sicurezza:
http://blogs.adobe.com/pdfitmatters/2010/02/deploying_acrobat_to_import_se.html
come esportare/importare le opzioni di sicurezza:
http://learn.adobe.com/wiki/download/attachments/52658564/acrobat_reader_security_9x.pdf#page=37
okay non è un vero post, sono solo degli appunti che mi servono... intanto lo pubblico, poi se sarà... scriverò un articolo più completo.
Etichette:
sicurezza
02/gen/2012
Chi è il mio CSR?
Sono sempre stato un professionista nel ricordare PIN, password, codici di accesso vari. E quando mi rendo conto che non vale la pena ricordare, so che devo scrivere le credenziali in un posto comodo e sicuro.
Ma con il SecureCode delle carte di credito MasterCard ho sempre avuto un brutto rapporto.
Oltre al codice scritto sulla carta di credito, ed oltre al codice di sicurezza stampato sul retro, alcuni esercizi commerciali su Internet richiedono, per le carte MasterCard, anche l'inserimento di un SecureCode, in pratica una password da associare alla carta. Fatto sta che la prima volta ero di fretta... inserire nuova password... confermare nuova password... nuova password inserita a caso ... pagamento andato a buon fine! Yuppy!
Ma da quella volta non me ne è più andata bene una! Grazie a dio, prima di sbagliare il codice per tre volte, è sempre possibile cliccare su "SecureCode dimenticato", inserire qualche piccolo dettaglio personale (e probabilmente noto a tutto il mondo tipo data nascita codice fiscale etc. etc.), ed inserire un nuovo codice, bello fiammante, pronto per essere scordato.
E se invece digita la password errata per ben tre volte? Io ho dovuto chiamare mia sorella, che mi ha prestato la sua di carta e meglio ancora, mi ha anche accompagnato fino in stazione dove ho preso appena in tempo il treno per Milano con il biglietto appena acquistato. Ma se non c'è così tanta fretta, a mente lucida, si telefona al numero verde scritto sulla carta, si comunica qualche dato personale, et voilà! Codice resettato, al prossimo acquisto se ne inserisce uno di nuovo (probabilmente è ciò che dovrà fare mia sorella visto che il codice che le ho inserito proprio non me lo ricordo).
Fatto sta che mentre stavo acquistando un biglietto Venezia - New York dal sito della Delta Airlines, al momento dell'inserimento del Secure Code mi esce questo inquietante e criptico errore:
Provo. Riprovo. Esco. Riprenoto. Reinserisco i dati. Cancello i moduli. Mi sconnetto e riconnetto. Ricompilo.
Sempre, consistently, lo stesso errore!
Così, non so perché, ma provo a rifare tutto utilizzando Internet Explorer al posto di Chrome. Clicco su "Secure code dimenticato" (ovvio, no? ormai non ci provo neanche più. sometimes life it's so easy!), imposto il nuovo secure code e... volo prenotato!!!
Non posso crederci. New York, aspettami!
Ma con il SecureCode delle carte di credito MasterCard ho sempre avuto un brutto rapporto.
Oltre al codice scritto sulla carta di credito, ed oltre al codice di sicurezza stampato sul retro, alcuni esercizi commerciali su Internet richiedono, per le carte MasterCard, anche l'inserimento di un SecureCode, in pratica una password da associare alla carta. Fatto sta che la prima volta ero di fretta... inserire nuova password... confermare nuova password... nuova password inserita a caso ... pagamento andato a buon fine! Yuppy!
Ma da quella volta non me ne è più andata bene una! Grazie a dio, prima di sbagliare il codice per tre volte, è sempre possibile cliccare su "SecureCode dimenticato", inserire qualche piccolo dettaglio personale (e probabilmente noto a tutto il mondo tipo data nascita codice fiscale etc. etc.), ed inserire un nuovo codice, bello fiammante, pronto per essere scordato.
E se invece digita la password errata per ben tre volte? Io ho dovuto chiamare mia sorella, che mi ha prestato la sua di carta e meglio ancora, mi ha anche accompagnato fino in stazione dove ho preso appena in tempo il treno per Milano con il biglietto appena acquistato. Ma se non c'è così tanta fretta, a mente lucida, si telefona al numero verde scritto sulla carta, si comunica qualche dato personale, et voilà! Codice resettato, al prossimo acquisto se ne inserisce uno di nuovo (probabilmente è ciò che dovrà fare mia sorella visto che il codice che le ho inserito proprio non me lo ricordo).
Fatto sta che mentre stavo acquistando un biglietto Venezia - New York dal sito della Delta Airlines, al momento dell'inserimento del Secure Code mi esce questo inquietante e criptico errore:
Your authentication could not be completed because of a system error.
If this happens consistently, please contact your CSR.
Provo. Riprovo. Esco. Riprenoto. Reinserisco i dati. Cancello i moduli. Mi sconnetto e riconnetto. Ricompilo.
Sempre, consistently, lo stesso errore!
Così, non so perché, ma provo a rifare tutto utilizzando Internet Explorer al posto di Chrome. Clicco su "Secure code dimenticato" (ovvio, no? ormai non ci provo neanche più. sometimes life it's so easy!), imposto il nuovo secure code e... volo prenotato!!!
Non posso crederci. New York, aspettami!
Etichette:
web
08/nov/2011
Google, catch 22
Cosa c'è di meglio che aprire Google per trovare una risposta, sentirsi fortunati perché Google ci porta precisamente sulla domanda di un tizio con il nostro stesso problema, e però l'unica risposta è un tizio incazzato nero che dice: ma è mai possibile? ancora questa domanda? Perché invece di continuare a farci perdere del tempo, prima di scrivere una domanda non cerchi un po' su Google?
01/set/2011
Google Italy Blog: Musica a tutto Chrome, anche in estate la tua musi...
Google Italy Blog: Musica a tutto Chrome, anche in estate la tua musi...: Stanchi della radiolina portatile, delle canzoni trasmesse in spiaggia, del numero limitato di brani sulla vostra playlist? L’estate è tempo...
29/lug/2011
Programmatori pazzi
Bene o male, ma soprattutto male, qualunque sviluppatore impara a scrivere qualche piccola applicazione per il Web.
Magari abbiamo scritto la nostra applicazione per tenere traccia delle attività da svolgere, come pagare la bolletta del metano, ricordarsi di revisionare la macchina, portare Tobia alla toelettatura per cani, consegnare un nuovo prototipo al cliente, o pagare gli alimenti per la prole alla ex fidanzata. L'accesso all'applicativo sarà previa autenticazione, e gli utenti potranno inserire i propri dati, leggerli in tabella, ricercarli, filtrarli.
Poi che cosa manca? Gli utenti, oltre ad interagire con l'applicativo Web, vorranno scaricare i dati e portarli sul telefonino, farsene una copia su chiavetta, o importarli in Excel e farci qualche piccola elaborazione.
Da qualche parte nella pagina si dovrà predisporre un link o una paginetta di download, e gli utenti, dopo aver aggiustato qualche filtro, potranno scaricare il file sul proprio client e gestirlo come preferiscono.
E quindi, il programmatore medio che cosa si inventa? Generalmente la tecnica scelta si attesta intorno a queste soluzioni:
La prima tecnica è molto limitata: come possiamo applicare dei filtri? Ma uno sviluppatore creativo è in grado di risolvere anche questo: in fondo, quanto ci vuole a creare in anticipo tutti i file con tutti i filtri possibili ed immaginabili, tutti già preimpostati?
Per la seconda tecnica, uno script con privilegi di scrittura su di una cartella che poi verrà servita tramite server HTTP è il sogno di ogni criminale informatico. Ma se proprio non ci sono altre possibilità, conviene almeno sapere che oltre al chmod 777 o all'Everyone Full Control esistono anche svariate vie di mezzo.
Per la terza ogni commento è superfluo. Posso solo giurare di aver visto anche questo!
Se però non avete notato altro, forse la sicurezza informatica non è il vostro mestiere, e probabilmente non lo sarà mai.
Il vero problema, grosso come un pilone portante del Burj Khalifa di Dubai, è che se mettiamo un file in \var\www\home\downloads\ l'utente vi potrà accedere felicemente andando al link http://www.example.com/downloads/attivita-nomeutente.dat ma oltre al nostro amico autorizzato vi potrà entrare anche tutto il resto del mondo. Certo, disabilitare il browsing delle directory è senz'altro un'idea brillante, ma non basta.
Il concetto è che al nostro Web Server non importa assolutamente nulla dell'autenticazione che abbiamo sviluppato nel nostro programma: abbiamo implementato un sistema di autenticazione per le nostre paginette Web? Bene. Abbiamo utilizzato un framework che implementa la parte di sicurezza? Meglio ancora. Ma questo sistema lo dobbiamo implementare anche per i nostri file. Solo allora possiamo servire le nostre pagine, dinamicamente, e protette dalle nostre credenziali.
(Ci sono casi in cui generare precedentemente i file da far scaricare agli utenti è cosa buona e giusta; tra l'altro il Web Server è sicuramente molto più veloce del nostro script nel servire le pagine; in questi casi però cerchiamo almeno di dare ai file un indirizzo URL casuale).
Magari abbiamo scritto la nostra applicazione per tenere traccia delle attività da svolgere, come pagare la bolletta del metano, ricordarsi di revisionare la macchina, portare Tobia alla toelettatura per cani, consegnare un nuovo prototipo al cliente, o pagare gli alimenti per la prole alla ex fidanzata. L'accesso all'applicativo sarà previa autenticazione, e gli utenti potranno inserire i propri dati, leggerli in tabella, ricercarli, filtrarli.
Poi che cosa manca? Gli utenti, oltre ad interagire con l'applicativo Web, vorranno scaricare i dati e portarli sul telefonino, farsene una copia su chiavetta, o importarli in Excel e farci qualche piccola elaborazione.
Da qualche parte nella pagina si dovrà predisporre un link o una paginetta di download, e gli utenti, dopo aver aggiustato qualche filtro, potranno scaricare il file sul proprio client e gestirlo come preferiscono.
E quindi, il programmatore medio che cosa si inventa? Generalmente la tecnica scelta si attesta intorno a queste soluzioni:
- si crea una bella crontab sul server, con una riga che viene eseguita ogni tot giorni, che crea una estrazione per ogni utente in \var\www\home\downloads\attivita-nomeutente.dat;
- la pagina di download, quando viene richiamata, inizia a scrivere un file in \var\www\home\downloads\attivita-nomeutente.dat. Una volta competato il file, viene mandato in output un bel link all'estrazione appena creata;
- la pagina di download richiama un processo sul server che inizia a scrivere un file in \var\www\home\downloads\attivita-nomeutente.dat. Poichè il processo è asincrono, si mette uno sleep di 5 secondi in modo da dare il tempo al processo asincrono di completare il file. Poi ci mettiamo un bel link al file appena generato.
La prima tecnica è molto limitata: come possiamo applicare dei filtri? Ma uno sviluppatore creativo è in grado di risolvere anche questo: in fondo, quanto ci vuole a creare in anticipo tutti i file con tutti i filtri possibili ed immaginabili, tutti già preimpostati?
Per la seconda tecnica, uno script con privilegi di scrittura su di una cartella che poi verrà servita tramite server HTTP è il sogno di ogni criminale informatico. Ma se proprio non ci sono altre possibilità, conviene almeno sapere che oltre al chmod 777 o all'Everyone Full Control esistono anche svariate vie di mezzo.
Per la terza ogni commento è superfluo. Posso solo giurare di aver visto anche questo!
Se però non avete notato altro, forse la sicurezza informatica non è il vostro mestiere, e probabilmente non lo sarà mai.
Il vero problema, grosso come un pilone portante del Burj Khalifa di Dubai, è che se mettiamo un file in \var\www\home\downloads\ l'utente vi potrà accedere felicemente andando al link http://www.example.com/downloads/attivita-nomeutente.dat ma oltre al nostro amico autorizzato vi potrà entrare anche tutto il resto del mondo. Certo, disabilitare il browsing delle directory è senz'altro un'idea brillante, ma non basta.
Il concetto è che al nostro Web Server non importa assolutamente nulla dell'autenticazione che abbiamo sviluppato nel nostro programma: abbiamo implementato un sistema di autenticazione per le nostre paginette Web? Bene. Abbiamo utilizzato un framework che implementa la parte di sicurezza? Meglio ancora. Ma questo sistema lo dobbiamo implementare anche per i nostri file. Solo allora possiamo servire le nostre pagine, dinamicamente, e protette dalle nostre credenziali.
(Ci sono casi in cui generare precedentemente i file da far scaricare agli utenti è cosa buona e giusta; tra l'altro il Web Server è sicuramente molto più veloce del nostro script nel servire le pagine; in questi casi però cerchiamo almeno di dare ai file un indirizzo URL casuale).
Etichette:
sicurezza
Iscriviti a:
Post (Atom)