Newsgroup: it.lavoro.professioni.webmaster
Titolo: Dubbio amletico, fidarsi o non fidarsidegli utenti?

Dovendo fare una semplice form in cui l'utente deve inserire:
Nome, Cognome, Codice fiscale, e-mail
secondo la vostra esperienza è meglio una form semplice e se sbaglia 
sono cazzi suoi e fa avanti e indietro (fisicamente) dall'ufficio che 
gli fornirà il servizio..
O è meglio inserire anche i campi "sesso" e "data di nascita" ed 
effettuare un controllo che il CF sia corretto?
La seconda opzione ci porta dritti alla questione privacy, consenso al 
trattamento (che comunque andrà fatto visto che serve l'email)...
Poi.. non è finita qui..
la form (protetta da SSL ovviamente) dovrà stampare i dati dell'utente 
ed un PIN/PUK (generati random) consentendo all'utente di stamparli 
possibilmente senza lasciare troppe tracce in giro per l'HD per cui 
pensavo di "visualizzare" una semplice pagina HTML piuttosto che 
generare un PDF che finirebbe senz'altro sull'HD del client.
Rischi? la cache del browser ovviamente.. soluzioni? idee?


Non pensarci.
-- 
Impastato Marcello
www.blueware.it
 

Rischi? la cache del browser ovviamente...
Usa i vari header/pragma per non fare salvare niente nella cache. Non
credo che sia possibile fare di piu', a meno di tchafficare con Flash
o Silverlight.
Leonardo
-- 
The thoughts of others were light and fleeting,
Of lovers' meeting, or luck, or fame.
Mine were of trouble, and mine were steady:
So I was ready when trouble came.

 Rischi? la cache del browser ovviamente.. soluzioni? idee?
si usa un fs cifrato a carico dell'utente
il tuo dubbio:
NON fidarsi dell'utente mai perche non e' detto che quello che faccia
casini sia un "utente" a cui interessa il servizio


Ahi ahi, javascript meglio evitarlo come la peste in questi casi!
-- 
Impastato Marcello
www.blueware.it
 

Ahi ahi, javascript meglio evitarlo come la peste in questi casi!
E perché mai?
Non ho mica detto né tantomeno pensato che, una volta passato il test lato
client in Javascript, io quei dati li considero corretti (e non potrebbero
esserlo, comunque! Non posso considerare, e per legge non devo provarci, i
casi di omocodia).
Il test lato client ha solo lo scopo di RIDURRE il traffico di rete, e non
obbligare l'utente alla trafila di modificare il proprio codice fiscale se
si accorge di avere inserito il numero di tessera della COOP.



Ridurre il traffico di rete? e di quanto? 100-200 byte? uh.... vedi che 
danno provoca all'intero sistema internet; se si vuole ridurre il traffico 
di rete basta evitare sistemi P2P.
-- 
Impastato Marcello
www.blueware.it
 

di rete basta evitare sistemi P2P.
Sì... ho sentito spesso fare questi ragionamenti e questi calcoli.
La prima volta, forse apocrifa, è stata "640 K bastano e avanzano!", ed è,
se non mi sbaglio, attribuita addirittura a Bill Gates.
Comunque la mia prima preoccupazione è relativa all'usabilità: i controlli
(secondo me) andrebbero fatti il più possibile "vicino" al lato utente per
bloccare gli errori il PRIMA possibile, e in modo ridondato (cioe' anche a
livello server) per bloccare PIU' errori possibili [1].
Dato che il blocco lato server è più gravoso (tanto per dire, càpita anche
di avere form che si svuotano e vanno riempite da capo - e chi non se l'e'
mai visto succedere, alzi un tentacolo), andrebbe evitato più possibile, e
in questo Javascript (e, perché no, misto AJAX) aiuta.
Leonardo
[1] tenendo conto che c'e' un costo in termini di manutenibilita'.


 per cui è preferibile effettuare i controlli di base anche lato server.
Il fatto che rifai i controlli serverside non vuol dire che quelli js
siano da evitare "come la peste" eh. Nella peggiore delle ipotesi
migliorano la UX.
-- 
MySQL and PHP are popular not because of their quality, but despite it.

 documenti ecc... per le correzioni
Il casino è proprio qui, che i dati inseriti non corrispondano ai 
documenti che dovrà presentare personalmente alla RA (Registration 
Autority) il ché è praticamente certo che qualche stordito prima o poi 
commetterà un errore..
L'idea di base era di "alleggerire" il lavoro della RA per cui l'utente 
inserisce i propri dati via web, si presenta munito di documenti alla RA 
che a quel punto deve solo confermarli spuntando l'utente dalla propria 
applicazione.
Ma mi sa che si fa prima a farlo fare direttamente alla RA anche in 
considerazione del fatto che l'utente potrebbe effettivamente non 
disporre di una stampante per i motivi più impensabili e "perdere" il 
file contenente PIN/PUK
Mi resta il problema di come passare il PIN/PUK all'utente.. certo 
potrei far stampare 2 copie del contratto, una per l'utente con PIN/PUK 
e l'altra per la RA senza i suddetti dati ma sembra assai poco elegante 
come soluzione..
D'altra parte non posso ricorrere ad una busta sigillata perché 
aumenterebbe considerevolmente i costi dell'operazione..

come soluzione..
Quando l'eleganza e la funzionalità cozzano, scegli la seconda :-)
Potresti far stampare PIN/PUK su un foglio a parte, o su un tagliando da
ritagliare e conservare. O inviarlo via SMS (un telefonino ce l'hanno si
può dire tutti).
Così, la tua percentuale di reject si riduce a quelli che si dimenticano
il telefonino, lo resettano, lo perdono, cancellano distrattamente l'SMS
o sbagliano il numero a cui inviarlo [1]. Per quelli, dai in outsourcing
il lavoro alla Fondazione Diane Fossey.
Leonardo
[1] tieni presente la possibilità che qualcuno dia il numero d'un nemico
    e ti richieda un milione d'invii di PIN. A pensar male si fa peccato
    ma, come diceva Housman che non a caso ho in sign...



Più gravoso? Io direi che sia più gravoso lato client.
-- 
Impastato Marcello
www.blueware.it
 

Più gravoso? Io direi che sia più gravoso lato client.
Ma anche no. Diciamo che computazionalmente il test lato client costi (e
sto esagerando) dieci volte quello lato server.
Be', se ho dieci client al giorno, "quasi" qualunque sia il carico reale
per me e' irrilevante: il tempo di smaltirlo ce l'ho.
Se ho mille client al giorno, ciascuno subirebbe un gravame 10C - mentre
io ne subirei uno 1000C: ossia cento volte superiore.
Quindi, demandare il demandabile (ma non di più, certo!) al client, come
anche raddoppiare il workflow, puo' avere senso, se questo mi riduce, in
media, il carico sul server.
Pensa che in certi casi io mi faccio preparare direttamente le query SQL
dal client, e lato server faccio UN primo controllo di "supervalidita'",
in caso di passaggio del quale spedisco la query pari pari al database -
se il 99% delle query sono 'super-valide' come accade di regola, ciascun
client "spende" pochissimo in piu', ma io risparmio un botto di risorse:
praticamente la somma di tutti quei pochissimi.
(Ma vorrei ri-sottolinearlo: in 'certi' casi ;-) ).
Leonardo


 Rischi? la cache del browser ovviamente.. soluzioni? idee?
Quando restituisci la pagina HTML imposti gli header in modo da dire al 
browser di non fare caching della pagina.
Direi "Expires: now" e "Cache-Control: no-cache, must-revalidate".


Tempo perso, imho.
Se javascript è disabilitato la query che generi client-side è stringa 
nulla.
-- 
Impastato Marcello
www.blueware.it
 

 client-side.
Te lo spiego io.
Su un server, caricare una pagina dinamica richiede di forkare il 
processo del webserver, compilare lo script php (o chi per esso), fare il 
parsing dei dati arrivati dal client, elaborarli, generare una pagina di 
risposta, eventualmente con connessione al DB e/o con accesso in lettura 
e scrittura al filesystem (sessione). Aggiungici che occupi un socket, 
che hai delle latenze di rete, che devi trasferire dei dati (e per di piu` 
con il window scaling al minimo sul TCP, visto che sono pochi byte).
Lato client hai la vm javascript gia` caricata e attiva, tutti i dati 
disponibili in RAM, e nessuna latenza di rete e nessun trasferimento dati.
Dire che fare il controllo sul server non costa 10 volte tanto, ma circa 
10.000 volte tanto.
Se hai un sito trafficato (diciamo il solito facebook) con 1 milione di 
utenti contemporanei, far fare un controllo da 1 millisecondo su un 
milione di client per evitare di tenere impegnato il server per 1 secondo 
per un milione di utenti (alias un milione di secondi), ha il suo bel 
peso.
Se poi quell'utente e` imbecille, e ti rifa` il submit del form perche` 
non vede il messaggio di errore, e magari lo rifa` altre 5 volte perche` 
il server impiega piu` di 3 secondi a rispondergli, sei nel pantano (per 
non dire peggio).
Logico che poi non ti fidi dei dati lato server, ma almeno per il 99% 
delle persone ti sei risparmiato ALMENO una connessione extra.
Bye.

 nulla.
Ma tu lo usi mai js? Perché magari sei uno di quellu che pensa che se
tanto il client può averlo disabilitato allora tanto vale non usarlo per
niente .


nulla.
Esattamente. MA in quel trascurabile 99% di casi in cui JS funziona, e
l'utente fa richieste "normali", io risparmio un botto. E' di nuovo la
legge di Amdahl.
Del resto è lo stesso principio che usano gli help desk. Ti POTREBBERO
far rispondere da un tecnico con ventisei certificazioni e dodici anni
di esperienza dvra sul campo, che certamente risolve il tuo problema.
Eppure ti fanno rispondere da una troterella che ti domanda cose come,
"La luce di POWER ON è accesa?".
E perché lo fanno, se nei casi in cui si è depolarizzato il sensore di
fine corsa della testa di stampa serve COMUNQUE la diagnosi del super-
ingegnere?
Lo fanno perche' nel 90 per cento dei casi l'utente non ha infilato la
spina nel buco della scossa, e quel 90 per cento dei casi lo "rimedia"
una sventurata da 800 EUR al mese, senza dover assumere chissa' quanti
super-ingegneri da 5000 EUR al mese e ci stai bene.
Le due direttive (è poi una sola) nel settore sono:
	"Make the common case fast"
	"Make the common case cheap"
L'utente pervicacemente senza Javascript o che mi altera i campi della
form con sapiente perfidia, il piccolo Bobby [ 
http://xkcd.com/327/
 ],
sono il caso piu' comune? No.
===
Mettiamoci dei numeri. Li scelgo apposta perché prima tu abbia torto e
poi tu abbia comunque ragione ;-), a testimonianza del fatto che serve
sempre fare tutti i conti.
Io ho un test "military grade" che mi costa 1500 millisecondi, un test
"amichevole" che me ne costa 200, ma soprattutto un CRITERIO col quale
posso dire "Questa query non abbisogna di test", e un test di verifica
che mi costa 2 millisecondi scarsi (regexp).
Certamente non tutte le query passano quel criterio! Ma molte si', dal
momento che sono robetta tipo "SELECT version();" o poco piu'.
Con ventimila query al giorno, passarle tutte al setaccio militare non
posso farlo con l'hardware attuale, perche' in una "giornata" di 8 ore
(19200 di quelle 20000 query arrivano dalle 9 alle 17) io non ho tutti
i millisecondi necessari. Quindi devo potenziare l'hardware - e questo
ha un costo.
Posso farlo? Certo che si'. E' un po' come tornare a casa, e rifare il
biglietto aereo per il giorno dopo. Posso; ma non ne sono contento.
Ma il 90 per cento dei miei utenti ha Javascript operativo, e il 60% -
e passa - delle query che fanno sono queriucce da du' lire. Che questo
sia il caso lo verifico lato CLIENT, e la richiesta lato server ha una
richiesta di "trattamento di favore".
Quindi avrò:
	- gente in corsia prioritaria, onesta: il 60% del 90% = 54%.
	- gente in corsia prioritaria, abusiva
	- gente non in corsia prioritaria: il restante 46%
Gli abusivi falliscono il test lato server ("Ti meriti la priorità?"),
e ricadono nel calderone verificato militarmente.
Adesso non ho piu' 19200 test militari da fare, ma solo 8832. Che puo'
essere la differenza fra un Basic Plan da 230 EUR/mese, ed un Pro Plan
da 310 EUR/mese.
Sono 960 EUR l'anno. Quanto m'è servito per implementare e soprattutto
collaudare i test separati? Tre giornate l'anno per mantenere le nuove
query che si rendono via via necessarie.
E a 500 EUR/giornata di costi sistemistici, ci sto rimettendo... avrei
fatto meglio a dar retta a te e a mettere tutto lato server, una volta
per tutte :-)
(Inutile dire che con altri numeri le conclusioni potrebbero essere un
bel po' diverse. Attenzione: serve tempo (dunque denaro) anche per una
valutazione potabile dei numeri in ballo).



Javascript lo uso essenzialmente per controllare gli oggetti di una pagina 
lato-client; i controlli sintattici, semantici e tutto li svolgo lato 
server.
-- 
Impastato Marcello
www.blueware.it
 

 ha scritto nel messaggio 
news:s24846p73f85mg8kv...@L.Serni...
cutto tutto per semplicità di lettura... dunque abbiamo questa situazione:
(a) controllo client-side (mediante Javascript)
(b) controllo server-side (es: mediante php)
Analizziamo le varie ipotesi:
(1) nessun controllo (a) e (b) non sussistono.
(2) controllo soltanto mediante (a) significa che in caso di javascript 
disabilitato non viene effettuato nessun controllo.
(3) controllo soltanto mediante (b) significa che il controllo viene 
effettuato ANCHE se l'utente ha javascript disabilitato.
(4) controllo mediante (a) e (b) significa che viene effettuato un doppio 
controllo.
L'ideale sarebbe effettuare un controllo di tipo (2) se javascript è 
abilitato oppure di tipo (3) se javascript è disabilitato; ma purtroppo non 
è possibile stabilire a priori quanto attuare il tipo (2) o il tipo (3).
In questi termini e con questa restrizione, un controllo di tipo (4) implica 
l'intervento lato-client e l'intervento lato-server che andresti comunque a 
implementare per sicurezza.
Ciò premesso se hai 1.000.000 di accessi che vanno a compilare il form.... e 
di questi il 30% hanno javascript disabilitato di questo milione con una 
soluzione di tipo (2) 300.000 sarebbero fuori uso; con una soluzione di tipo 
(3) appesantiresti il tuo hardware ma non escluderesti nessuno; con una 
soluzione di tipo (4) appesantiresti non solo il tuo hardware come nel caso 
precedente ma in caso l'utente abbia javascript abilitato faresti due 
controlli; nel caso l'avesse disabilitato invece uno solo.
Ora dal momento che un controllo client-side non porta alcun beneficio dal 
momento che devi comunque fare un controllo server-side; puoi 
tranquillamente escludere il controllo client-side e demandare tutto ad un 
unico controllo server-side.
Se poi invece non ti vuoi curare degli utenti che possono avere javascript 
disabilitato allora la soluzione di tipo (2) è la migliore, ma se non vuoi 
escludere nessuno la soluzione migliore è la (3).
-- 
Impastato Marcello
www.blueware.it
 

 server.
Ah ecco, almeno sai di cosa stiamo parlando.



A me sembra proprio di no... :-) non si parlava di controllare dei campi di 
un form... ma di validare il contenuto di un campo del form, che è 
sensibilmente diverso.
Lato javascript puoi tranquillamente controllare se un campo è vuoto oppure 
no nessun problema. Del resto se il campo è vuoto quando andrai a fare la 
validazione lato server quest'ultima fallirà comunque; se il campo è pieno 
passi il controllo lato client, ma comunque andrai a fare una validazione 
del campo lato server.
Il mio appunto era abbastanza semplice: sia che il campo sia vuoto, sia che 
non lo sia, fai il controllo del dato lato server; lato server puoi infatti 
controllare se il campo è vuoto e quindi saltare tutto il resto.
In ogni caso sono scelte implementative. Se a te piace seguire una strada 
nessuno te lo impedisce; se a me piace seguirne un'altra, nessuno me lo 
impedisce :)
Il concetto di "semplice" è strettamente soggettivo in questi casi.
-- 
Impastato Marcello
www.blueware.it
 

 dal momento che devi comunque fare un controllo server-side; puoi
Fai due errori:
1- non esiste che il 30% abbia javascript disattivato. Siamo piu` tra l'1 
e il 3%.
2- non e` vero che non porta alcun beneficio. Apporta enormi benefici sia 
di usabilita` (segnali l'errore mentre l'utente sta ancora scrivendo, 
quindi puo` correggerlo prima di premere submit) che di carico sul server.
Ti e` mai capitato, magari con un cellulare con tastiera touch su uno 
schermo da 2 pollici, di compilare un form, sbagliare un dato e lui ti 
riporta al form, dove devi, oltre a correggere il dato, riscrivere la 
password due volte perche` l'HTML impedisce di precompilare un campo 
password, e magari lo sbagli di nuovo, o ne sbagli un altro, e ripeti dal 
punto 1 finche` ti rompi le balle e abbandoni il sito?
Ecco, con un controllo lato client non ti rompi, correggi al volo quello 
che non va bene, e sei un utente felice.
Bye.

momento che devi comunque fare un controllo server-side
Questa conclusione, purtroppo, e' sba-glia-ta. Il fatto che il controllo
"vero", che conta, sia fatto DOPO, non vuol dire che non sia comodo fare
controlli "veloci" PRIMA che potrebbero evitarti, fallendo, il controllo
piu' oneroso dopo.
Tu dici: se ho un controllo sicurissimo, ferreo ed inaggirabile a valle,
e' inutile avere un controllo alla buona, che può dare falsi allarmi e/o
guastarsi, a monte.
Sicuro sicuro?
Bene: sbrana via l'impreciso indicatore della benzina dal tuo cruscotto.
Tanto, il carburatore ti avvertirà con certezza infallibile di quando il
serbatoio sarà vuoto. Al millilitro, preciso. Provare per credere :-)


 del campo lato server.
Con js puoi fare tutte le validazioni che ti pare, calcolate sul client
oppure via ajax col server, è chiaro che si tratta di controlli
preventivi, non definitivi. Sono un di più, come lo sono i CSS per dire,
come lo è l'interfaccia grafica su cui gira il sistema operativo, è roba
che non è strettamente necessaria, ma visto che c'è ed è dannatamente
utile usiamola quando possibile, o no?



I due controlli hanno due scopi diversi, ma il controllo lato server dovrà 
comunque controllare una seconda volta ciò che è stato fatto lato client; 
perchè se l'utente ha js disattivato e non controlli i campi che avresti 
dovuto controllare con js.... lato server quei campi (non validi, te li 
ritroveresti validi).
Ciò premesso, quello posto dall'op del thread è un caso diverso, noi abbiamo 
un form composto da:
1) Nome
2) Cognome
3) Codice Fiscale
4) Email.
La domanda posta dall'op era la seguente, quoto:
<quote>
secondo la vostra esperienza è meglio una form semplice e se sbaglia sono 
cazzi suoi e fa avanti e indietro (fisicamente) dall'ufficio che gli fornirà 
il servizio.. O è meglio inserire anche i campi "sesso" e "data di nascita" 
ed effettuare un controllo che il CF sia corretto?
</quote>
In altre parole chiede un consiglio sullo scegliere fra:
(a) un form semplice (se l'utente sbaglia sono problemi suoi etc etc)
(b) inserire i campi "sesso" e "data di nascita" ed effettuare un controllo 
che il CF sia corretto
Se dovessi scegliere fra la (a) e la (b) suggerirei la (a) anche perchè da 
come si evince l'errore dell'utente, comporta per l'utente un maggiore 
dispendio di energie (vedi premessa) e quindi è incentivato a inserire i 
dati correttamente (si presume si tratti di una cosa seria).
Consigliare la (b) implica complicare la vita quando non è necessario. Il 
codice fiscale contiene già sia la data di nascita che il sesso; quindi i 
campi "sesso" e "data di nascita" sono inutili.
La cosa migliore per aiutare l'utente finale è trovare un compromesso fra 
l'inserimento sintatticamente corretto dei dati e l'inserimento secondo 
buona fede dell'utente finale.
Quindi scomodare javascript per controllare se i campi sono vuoti oppure no 
non ha alcun senso nel caso specifico; fare un controllo sintattico dei 
quattro campi lato server invece è più flessibile in quanto se si verifica 
un errore è possibile riproporre il medesimo form come già precedentemente 
compilato segnalando il campo sintatticamente non corretto; il tutto 
indipendentemente dal fatto che l'utente abbia javascript abilitato o 
disabilitato.
Infine, operando in tal modo, ipotizzando che l'utente sbagli 
deliberatamente l'inserimento dei dati, può essere avvisato in una sola 
volta di tutti i campi dove ha sbagliato; cosa che in javascript si potrebbe 
fare segnalando un campo alla volta... e al tempo stesso l'utente potrebbe 
annoiarsi a vedersi apparire le finestrelle; senza considerare comunque che 
l'utente potrebbe tranquillamente compilare il primo campo per passare al 
quarto direttamente.
In tal caso il controllo sul secondo e terzo campo (che non ricevendo mai il 
focus non darebbero luogo ad alcun evento) e tutto andrebbe a farsi xxxx :)
Certo, in tal caso al submit bisognerebbe scatenare un evento che controlli 
tutti i campi in una sola volta... quindi il medesimo controllo lato server.
I form in html sono ben diversi da quelli di una applicazione vera e 
propria.
-- 
Impastato Marcello
www.blueware.it
 

Ma che cosa c'entra. Cooper
Scusami se scendo adesso dal pero: in che senso, "Cooper"? :-?
Leonardo che si dev'essere perso qualche cosa


annoiarsi a vedersi apparire le finestrelle
=====8-&!!!
Scusami, ma a questo punto mi sono fatto un'opinione abbastanza precisa -
non hai, semplicemente, idea di come fare un controllo del genere in modo
professionale... e quindi le scovi di sottoterra per implementare l'unica
soluzione che ti è familiare, il famoso controllo lato server.
Le "finestrelle", per amor del cielo. Nel 2010.
Guarda, lasciamo perdere... diciamo che fai proprio bene così e hai senza
dubbio ragione te; chissà a che pensavo quando mi sono messo a discutere,
per davvero. Scusa anzi se t'ho fatto perder tempo per la mia scarsissima
esperienza, ma sai, "sono un giovane che lavora qui da poo, capito".


 Scusami se scendo adesso dal pero: in che senso, "Cooper"? :-?
Nel senso che Cooper ha cambiato nick, ma quello vecchio si fa prima a
scriverlo e mi farebbe strano chiamarlo "Blueware Studio".


Nel senso che Cooper ha cambiato nick
Ah, ecco(tm). Thanks.
Leonardo



Se non ti piace il nome "finestrelle" vogliamo chiamarle DIALOG BOX? cosi ti 
č piů figo? :)
-- 
Impastato Marcello
www.blueware.it
 


haha me lo stavo a chiedere anche io :D  cmq in firma c'è anche il mio nome 


 è più figo? :)
vai qui:
http://www.youtube.com/create_account
inserisci googleitalia come nome utente e premi tab
quante dialog box vedi?
-- 
come (omissis) abbiamo fatto a prendere un termine che significa 
"toccare con il (omissis)" e renderlo sinonimo di "quoto"?

Il 19/07/10 18:06, BlueWare WebStudio ha scritto:

La cosa è seria..
In pratica sono i 4 campi obbligatori per il rilascio di una smart 
card/token USB o meglio del certificato/i contenuti negli stessi.
L'idea alla base è far compilare la form all'utente rilasciandogli al 
contempo un file/stampata contenente PIN/PUK della smart card/token che 
gli servirà successivamente per poterlo utilizzare.
I dati verrebbero salvati sul server crittografati (con la chiave 
pubblica della RA) inseriti in un DB da cui la RA potrà accedere per 
"caricare" (non leggere) i dati nel proprio server, ovviamente nome, 
cognome, CF e email saranno "visibili" per poterli confrontare con i 
documenti dell'utente che deve essere fisicamente presente per poter 
ritirare la propria smart card.
Questo però in effetti comporta semplicemente un gran casino, tanto vale 
che sia la RA ad inserire i dati direttamente nel proprio sistema 
saltando in toto la parte online (intesa come web) unico problema è che 
in un sistema perfetto la RA non dovrebbe poter accedere a PIN/PUK anche 
se in effetti possono sempre accedervi con un hack (ma questa è un altra 
storia)
Attualmente InfoCert lavora così:
PIN e PUK sono in una busta sigillata sulla quale è impresso un codice a 
barre, nel sistema vengono inseriti i dati di cui sopra e letto il 
barcode della busta che ovviamente andrà ad interrogare un DB per 
ripescare PIN/PUK senza farlo sapere all'operatore della RA.
Quindi attraverso PIN/PUK viene generata la chiave privata dell'utente 
all'interno del token e la CSR (Certificate signing request) che 
successivamente viene firmata digitalmente dall'operatore attraverso la 
propria smart card ed inviata alla CA che genera il certificato digitale 
dell'utente reinviandolo alla RA che lo carica nella smart card/token 
dell'utete


gli servirà successivamente per poterlo utilizzare.
Non vedo il problema. Io farei compilare tutti i campi, anche per chiarire
che e' una cosa seria ed incentivare l'attenzione del cliente <chuckle>, e
aggiungerei un controllo lato client, per assicurarsi che al server arrivi
roba pulita, roba alterata da un malintenzionato, o roba schifida da gente
senza Javascript (questo ti elimina quel 95% di persone distratte - ma con
Javascript - che costituisce l'utonza media che vedo io; magari tu vivi su
un pianeta diverso e piu' fortunato).
Poi il server naturalmente controlla i dati scremati in arrivo.
Quasi quasi aggiungerei anche un CAPTCHA ma per quello vedi tu.
Inoltre controlli che il CF sia univoco, si sa mai che uno richieda dodici
smartcard.
E volendo a quel punto mandi all'email che ti ha dato il tizio un link con
l'attivazione. Se clicca il link vai avanti, se no dopo 48 ore butti via i
dati e non generi proprio nulla. In questo caso il CAPTCHA serve meno; non
penso ci siano bagarini di smart card, e potrebbero sempre fare a mano.
A questo punto sai d'aver a che fare con una richiesta valida, proveniente
da un cristiano con due neuroni che fanno contatto, che vuole la card. Sei
a posto: salvi i dati e gli stampi un foglio A4 diviso in due parti, sopra
tutti i dati del caso, sotto un bel PIN/PUK con "DA RITAGLIARE, CONSERVARE
E NON FAR VEDERE ALLA RA" in Times New Roman 144 punti, grassetto, nero. E
anche lampeggiante, se la stampante lo supportasse :-).
E se vuoi fare lo sborone, sulla pagina stampi anche un bel barcode con l'
ID del record in questione. Basta un fottuto 3-of-9.
A quel punto, quando alla RA arriva lo spumarino pallido con il foglio, l'
impiegato batte il numero (o gli lampeggia contro il barcode scanner) e il
sistema mostra a video - "MARIO ROSSI, ...". E' lei, Mario Rossi? Cacci un
documento, cortesemente. Sì, è lei. Aspetti che prendo la bvsta.
Se a questo punto l'impiegato ti rimanda indietro un CHECK e tu dici che i
dati dopo un mese non siano più validi, o la RA controlla le revoche, puoi
gestire il caso che uno chieda per sbaglio due smartcard: quando chiede la
seconda, se ((la prima non è ancora stata scaricata dalla RA) OR (la RA ha
in mano la revoca e non ha mandato il CHECK) OR (e' passato un mese, e non
e' arrivato alcun CHECK)), puoi annullare la prima senza troppi rischi. La
RA ovviamente deve negare la card se la richiesta è più vecchia di 29, non
30, giorni (se no ti rimane una "finestra" in cui l'impiegato caccia fuori
la card e il tuo sistema accetta la revoca con la generazione di una nuova
richiesta - se lo faccio da un terminale mobile ho il tempo di rientrare e
andare da un impiegato diverso che non mi riconosce, Zwei smartcarden!).


 Rischi? la cache del browser ovviamente.. soluzioni? idee?
mah, senti, io metterei tutto in un bel frame e buonanotte...

 ritirare la propria smart card.
Già... e chi genera la chiave privata? Tu? E io mi dovrei fidare?
-- 
  Daniele Orlandi						つづく

Il 20/07/10 11:58, Daniele Orlandi ha scritto:

Ovviamente la chiave privata la genera la RA davanti all'utente quando 
inserische il token/smart-card nella porta USB del *loro* server.
le chiavi di cui sopra non hanno nulla a che vedere con quella/e dei 
token, servono solo per codificare/decodificare dati che dovrebbero 
essere mantenuti su un web server pubblico prima di passare da un server 
all'altro e possono essere di tipo gpg2
Certo è più pratico ranzare tutto e far inserire i dati direttamente 
nell'applicazione che genera la CSR alla RA così evito un bel po' di 
lavoro inutile.

 inserische il token/smart-card nella porta USB del *loro* server.
E chi mi dice che invece non sia una chiave generata esternamente e poi 
caricata sul token?
Molto meglio che *IO* generi la chiave privata sul *MIO* token come dico io 
e poi tu, CA, mi firmi la chiave pubblica.
-- 
  Daniele Orlandi						つづく

 e poi tu, CA, mi firmi la chiave pubblica.
L'Art 6 lo consentirebbe
(
https://www.pec.it/documenti/DPCM-30032009-DOCUMENTI-ELETTRONICI.pdf
)
in linea teorica, ma in linea pratica si evita di farlo..
La questione è piuttosto semplice, l'utente potrebbe generare una copia 
della propria chiave privata per poi caricarla sul token vanificando 
così la sicurezza intrinseca del dispositivo anche se ad onor del vero 
verrebbe sgamato dalla RA in quanto non è possibile caricare la chiave 
pubblica per cui basterebeb verificarne la presenza..
La soluzione al problema è in realtà semplicissima ed è l'idale anche 
per quelle aziende di dimensioni medio/grandi che devono fornire ai 
propri utenti dei token di autenticazione, farli diventare loro stessi 
delle RA.
Questo consente virtualmente anche ad un privato una volta firmato il 
contratto con la CA di diventare una RA e rilasciare certificati per se 
e per altri, ovviamente entra in gioco tutto il discorso della fiscalità 
ma quella è un altra storia..

 ma quella è un altra storia..
Cosa c'entra la fiscalità?
-- 
  Daniele Orlandi						つづく