Newsgroup: it.comp.www.php
Titolo: Autenticare un CAP

Doveri autenticare un cap in una form (5 cifre numeriche). Qualcuno ha
qualche idea ?
Grazie
Giuseppe


più precisamente cosa vuoi fare ??
Alex

 qualche idea ?
Credo che di cap ce ne siano veramente tanti: anche il 90210 di beverly
hills è un cap
LAMASE

 ha scritto nel messaggio
news:lqQH7.667$0x4....@news2.tin.it...


 ha scritto nel messaggio
news:3bf00...@212.7.64.37...


Grazie delle numerose risposte.
Mi interessa solo vedere che sia di 5 cifre numeriche, non che esista
effettvamente (mi sembra un po' esagerato). Diciamo pure che per lo meno si
evitano cose evidentemente fuori dell'ordinario.
Giuseppe
news.ctonline.it
 <dav@thecloud.o> wrote in message
news:9sp3u6$ev4$1...@serv1.iunet.it...



Semplicemente :
utilizzare le espressioni regolari (esattamente  5 cifre
numeriche) . Il consiglio che dň e' di farlo in JavaScript,
cosě la validazione viene fatta prima di inviare il form .
Con PHP il controllo con le espressioni regolari deve essere
fatto dopo l'invio.
Credo che confrontare il CAP inserito fra tutti quelli
possibili, anche tenendo a disposizione un database di CAP,
sia molto laborioso (computazionalmente parlando) .
Una soluzione efficace sarebbe quella di far scegliere una
provincia (fra tutte quelle possibili) magari da una
finestra popup, dopodiche' i comuni appartenenti alla
provincia, a cui sono associati i CAP (bisogna disporre di
un database completo, non so dove si possa prenderlo, e tra
l'altro sarebbe enorme).
Cosě si va sul sicuro, ma se la validazione deve essere
fatta per prevenire falsi CAP , cio' non ha senso, poiche'
qualcuno potrebbe inserire semplicemente un falso comune. Se
bisogna prevenire un errore di digitazione, puo' andare bene
il controllo con le espressioni regolari.
-- 
WEbdOM webmaster di 
www.metronic.it
 
il sito sulla telefonia ai prezzi che cercavi
Iscriviti a Pillol@ - la newsletter sulla telefonia (e non solo).
Metronic.It mobile phone philosophy
www.gadgetpoint.it
 serigrafia on line

 evitano cose evidentemente fuori dell'ordinario.
Se si tratta solo di controllare questo allora non č necessario tirare in
ballo il PHP...
basta mettere nel form html un tag del tipo:
<input type=text name=cap maxlenght=5>
Aspe... pero' cosě controlli solo la lunghezza massima non la minima...
uhm... non so se forse c'č anche minlenght...
va beh, cmq al massimo puoi usare un'espressione regolare di PHP...
Ciao
Alex

 evitano cose evidentemente fuori dell'ordinario.
ma prendere la select delle poste??

if ( ereg ( "^[0-9]+$", $CAP )  && strlen ( $CAP ) == 5 ) {
print "CAP OK";
} else {
print "CAP non valido";
}
Ciao, Luca

 if ( ereg ( "^[0-9]+$", $CAP )  && strlen ( $CAP ) == 5 ) {
farlo diventare: if ( ereg ( "^[0-9]{5}$", $CAP ))
le parentesi {5} indicano ripetizione per 5 volte della espressione
precendente.


 precendente.
ci avevo anche pensato.... ma dopo :-)))
Ciao, Luca

 ha scritto nel messaggio
news:3bf032e8...@news.cis.dfn.de...


Trovo questa tecnica meno dispendiosa in risorse macchina ed intellettuali.
Sicuramente, ma cmq sempre meglio validare il form con
Javascript (con eventi onChange del campo input contentente
il CAP e magari su onSubmit del Form), per evitare di
inviare il form con dati scorretti e quindi affidando al
client il controllo. La programmazione lato client va sempre
fatta quando è possibile, perche' si risparmia banda (è la
motivazione che ha portato alla nascita dei linguaggi client
side) e quindi si fa risparmiare tempo e denaro al
visitatore.
Se vitrovate a fare un ordine su Metronic.It , potete
provarlo on line ;))  (validazione email, codice fiscale
etc.) 
Saluti.


 ha scritto nel messaggio
news:3bf17a8...@news.cis.dfn.de...


 etc.) 
Ok, arrivo con il JS disabilitato e vediamo dove me lo spedisci il
pacco! :-))
IMHO, meglio fare:
- parsing dal client
- parsing "veloce" lato server
- parsing attento lato server
In particolare, gli ultimi due vogliono dire, nel caso di esempio di
validazione di un'email, una cosa del genere:
controllino veloce se la stringa contiene una "@": se la contiene, via
di regexp per controllare il resto della stringa; se non la contiene,
errore senza far lavorare la regexp.
Cosě sei sicuro di fare le cose per bene e di risparmiare, quando
possibile, risorse-macchina!
Ciao
--ev

possibile, risorse-macchina!
E' una buona logica, ma le risorse makkina risparmiate sono
del server in america, non del client .


 se quello ke ho fatto e' bello pero':)))
Ma se ti serve validare un dato che poi utilizzerai e questo controllo lo
fai solo in Javascript, l'unico utente stronzo e paranoico che l'ha
disabilitato ti può creare casini (es, scrive l'e-mail male e  poi la userai
in un programma: il programma la legge e si blocca).
Sicuramente si deve controllare ANCHE lato server.
LAMASE

 del server in america, non del client .
E dici poco! :-)
Ragiona in termini di script "grossi e pesanti" in siti molto trafficati
e vedi che, se devi scegliere, ci metti un'ora in più a scrivere lo
script ma lasci il server il più libero possibile!
Alla fine, perchè esiste mod_php ed il PHP usato come CGI non se lo caga
quasi nessuno? E perchè è nato (anche se funziona in maniera un attimo
differente) il buon vecchio mod_perl la posto dei semplici CGI in Perl?
E questa domanda è da porsela per miriadi di
applicazioni/aplicativi/soluzioni!
Tutto per far lavorare il meno possibile il server in (ipotizzabili ma
tangibili) situazioni di alto carico!
Certo però che, sempre IMHO, risparmiare risorse del server facendo
lavorare il client può portare in situazioni a volte sgradevoli!
E se non ti è ancora capitato, ti auguro non ti capiti mai! (e qui mi
bacchetto le mani da solo!!)
Ciao
--ev 

|... non ti dà la sicurezza che, IMHO, _devi_ esigere in determinati casi
|(e l'ecommerce è uno di questi).
|Per la banda, è sempre meglio risparmiarla finchè si può, ma quando ci
|sono di mezzo "cose importanti" (generalizzazione!) è meglio far
|attendere l'utente un paio di decimi di secondo in più!
Non mi sembra che Giuseppe, senza togliere niente a nessuno, consideri
l'argomento in questione un'operazione di importanza *vitale* per l'economia
internazionale. A lui interessa solo sapere se sono cinque caratteri e se
sono tutti numeri.
Quindi, forse, semplicemente non ha pensato che un JavaScript risparmia
strazi a lui e all'utente. Oltre tutto, JavaScript ha la carina funzione
isnan() (=is not a number) che controlla se una variabile è o no un numero.
Senza tirare in ballo espressioni regolari o altro.
Vogliamo ad ogni modo essere sicuri sicuri sicuri? PRIMA facciamo il
controllo con JavaScript, e POI lo rifacciamo in PHP: così quell'unico
*stronzo* che ha disabilitato JavaScript, viene beccato da PHP e peggio per
lui se perde tempo. Tutti gli altri, passato il primo controllo, passano
anche il secondo.
Sempre che non esista un metodo semplice per vedere se JS è disabilitato o
meno. Ora lo vado a chiedere.
Comunque, francamente non capisco tutto questo integralismo server-side.
Evidentemente non vi è mai capitato di compilare un form, lasciare in bianco
un campo, aspettare >15" dopo il submit e poi vedersi dire: "Il campo
'Scrivi una cazzata' è obbligatorio", perdendo tutto quando torni indietro.
Una volta che usare script server-side era una smazzata (settaggio di
permessi, accesso alle directories cgi-bin, prove e riprove, alcuni provider
volevano addirittura esaminare il codice) JavaScript era un'ottima risorsa.
Adesso che con php e asp qualsiasi persona (me compreso) può scrivere script
server-side, tutti spuzzano JavaScript (Ah, quella cosa là, roba da
dilettanti) e non ci si cura più né dell'eleganza del codice, né della sua
efficienza, né che i database siano ottimizzati.
E' la stessa cosa che è accaduta con la grafica: quando pochissime persone
potevano permettersi un modem a 28.8, si stava attenti alla pesantezza delle
immagini e si faceva in modo che il sito fosse navigabile anche
disabilitandole, adesso uno ti spara immagini pesantissime e tu devi star lì
ad aspettare perché il bottoncino con scritto "Clicca qui, cazzone" non ha
l'"ALT" e se c'è non significa niente.

attendere l'utente un paio di decimi di secondo in più!
beh, forse un controllino lato server , anke se ridondante,
aumenta l'affidabilita':)


 aumenta l'affidabilita':)
Giuro, questo è l'ultimo reply! ;-)
(anche se personalmente trovi queste discussioni alquanto interessanti!)
A riprova delle mie tesi ;-), posso anche dirti che un utente può anche
cambiarti del tutto i campi che vengono inviati allo script dalla parte
del server.
Esempietto al volo:
<form name="mioform" action="script.php" method="GET">
<input type="text" name="campo1">
<input type="text" name="campo2">
<input type="submit">
</form>
che tu controlli con un semplice js:
<script language="Javascript">
if(document.mioform.campo1.value == "qualcosa") {
	....
} else {
	....
}
if (document.mioform.campo2.value == "qualcos'altro") {
	....
} else {
	....
}
e fino a qui, secondo i sostenitori del "solo js" hai la possibilità di
controllare per bene i campi del form (nel caso quasi ovvio che l'utente
abbia js abilitato). Sono d'accordissimo, il controllo c'è, funziona e,
normalmente, sei a posto.
Adesso tu ti aspetti che al tuo script arrivi qualcosa del tipo:
script.php?campo1=pippo&campo2=pluto
e tramite js hai già controllato che "pippo" e "pluto" sono due valori
che vanno bene ai tuoi fini.
E, al 99% dei casi, sei a posto, inserisci i dati nel tuo DB o li parsi
come ti serve.
Ma se ad esempio un utente ti scrive direttamente, senza passare dal
form (quindi lo scrive nella barra dell'indirizzo del browser):
script.php?campo1=&campo2=
già qui se non hai un controllo dalla parte del server rischi di far
entrare due campi vuoti su due! Che non è bello! :-)
Se adesso obietti dicendo: "ma io posso far passare i dati in POST, in
modo che l'utente non scriva niente sulla barra degli indirizi" ti
rispondo che è possibile "fregare" il server anche se i dati passano in
POST.
Se ad esempio hai:
<form action="script.php" method="POST">
<input type="text" name="campo1">
<input type="text" name="campo2">
<input type="submit">
</form>
che controlli sempre con js, ti posso assicurare che qualcuno è in grado
di farti arrivare al posto di:
campo1=pippo
campo2=pluto
qualcosa del tipo:
mia_nonna=sta bene grazie
tempo=coperto
tutto_bene=si grazie
che, se non controlli dalla parte del server sei fregato, soprattutto
perchè, al posto delle scemate che ho scritto io, possono passare
stringhe alquanto maliziose!
Ok, è un caso raro, rarissimo se vuoi, però il programmatore attento non
deve farsele scappare! :-)
Ciao
--ev