Closed sablaireau closed 8 years ago
e farla al vecchio modo like C?
ovvero?
quello che importa è che abbia la @
e che sia simile a x@y.s
dove x
è una stringa che non deve finire per un non carattere a-z A-Z 0-9
e può avere solo punti in mezzo che non siano consecutivi e deve iniziare per un carattere a-z A-Z 0-9
Stessa cosa per `y'.
Mentre per s
deve essere solo una stringa con solo lettere.
Quindi in C diventa più macchinoso ma almeno è fattibile se non si possono usare le regex, al più ci posso provare e poi ti passo il codice.
forse ne ho trovata una che java mi accetta e provandola sul quel tool sembra funzionare..ma testate anche voi per sicurezza.
^[\w-_\.+]*[\w-_\.]\@([\w]+\.)+[\w]+[\w]$
o.k. va bene
ovviamente in java ho dovuto scriverla così:
^[\\w-_\\.+]*[\\w-_\\.]\\@([\\w]+\\.)+[\\w]+[\\w]$
forse ne ho trovata una che java mi accetta e provandola sul quel tool sembra funzionare..ma testate anche voi per sicurezza.
^[\w-_\.+]*[\w-_\.]\@([\w]+\.)+[\w]+[\w]$
mi sembra giusta 👍
Se in Java stai usando la classe Pattern
qui c'è una spiegazione molto dettagliata.
ottimo, grazie!! Cmq per il momento l'ho messa solo nella registrazione, adesso vedo di aggiungere tutti i controlli per quanto riguarda la creazione delle ricette
ho aggiunto i controlli sull'email nel momento in cui riempiamo i db, sono da testare. Se funzionano..li aggiungo anche nella logica per un ulteriore sicurezza (man in the middle tra server e db)
provo a seguire le tue istruzione per testarlo..
ok..a me sembra funzionare. L'ho testato anche con il trigger gmail (incoming email) e funziona..però non compare la scritta lato client (che avvisa dell'errore) come invece compare per la action gmail
Ah sì..forse compare..come non detto.. in ogni caso, adesso aggiungo questi controlli (che mi sembrano funzionare) anche altrove
uhm allora noi spediamo tutto al server dopo che finisci la descrizione e a questo punto che riceviamo qualche cosa dal server.
Dentro a trigger gmail c'è una scritta che ti dice se è giusta o no l'email sotto il campo
sì sì niente..come non detto ;-)
sto tentando di mettere i controlli sulla temperatura, ma di quale temperatura stiamo parlando? thmax e thmin? Entrambe devono essere comprese tra -70 e +70 (inclusi)?
invece per quanto riguarda le date, lascerei la stringa nel db..perchè altrimenti bisogna cambiare tutto, sia db che logica..il chè è un po' rischioso; inoltre i controlli sarebbe sempre meglio farli sul server, per evitare un man-in-the-middle tra server e db..ciò significa gestire le eccezioni..come dicevo prima (discorso che io e Alex avevamo lasciato in sospeso)
Per thim e thmax le avevo prese dal quello che avevo letto dal quello che mi avevi passato molto probabilmente ho capito male, da quanto ho capito se la temperatura raggiunge X allora si manda un e.mail
sì esatto: se l'utente inserisce thmax ad esempio..allora si monitora la temperatura corrente e se supera thmax viene scatenata l'azione. Quindi i controlli che avete messo voi sono su queste due temperature giusto? entrambe devono essere impostate dall'utente con un numero compreso tra -70 e +70?
credo di sì..stavo facendo delle prove (e guardando il vostro codice) e mi sembra di capire così
si per la prima frase.
Si da [-70/+70] per entrambi
si si ho controllato adesso, da -70 a +70 compresi gli estremi solo interi [-70,-69 . . .+70]
ottimo grazie!! Li aggiungo sul server e poi posso chiudere questo issue. Perchè il discorso delle eccezioni è un'altra cosa..le ho già guardate un attimo, ma le rivedo poi bene anche con Alex, cmq l'importante è che vengano catturate in modo da non bloccare il thread..poi possono anche venire ignorate: se c'è un errore nei dati (ad esempio la data), la ricetta non verrà svolta..il discorso è più o meno questo
di nulla figurati :) Non lo so com'è fatto il server, ma a mio avviso si potrebbe dire che ogni volta che un dato è falso (esempio la temperatura non è un numero) allora si ipotizza un attacco ed il server non risponde poiché tutti i controlli sono fatti al lato client.
Mentre se è un problema sul server (esempio stupido: non c'è più memoria per nuovi utenti) allora si manda un errore da informare il client.
Quello che voglio dire è di cercare di non inviare segnalazioni di errori a valanghe per evitare varie tipologie di attacco.
Tuttavia le mie sono solo idee :) ^-^
no no certo...hai ragione..infatti io pensavo proprio di non fare nulla, cioè il thread deve continuare a girare all'infinito, quindi è importate catturare le eccezioni in modo che non lo blocchino, dopodichè se i dati sono sbagliati non si fa nulla..non si invia l'errore al client nè niente, semplicemente la ricetta viene ignorata (e il man-in-the-middle si fotte)..al prossimo giro (se il man-in-the-middle non c'è più) verrà eseguita normalmente. Errore più grave è quando i dati sono sbagliati già nel db (a quel punto la ricetta viene sempre ignorata), però abbiamo messo abbastanza controlli sia sul server che sul client per far sì che ciò non succeda ;-)
o.k. perfetto!!!! Povero man-in-the-middle :) quasi quasi mi dispiace per lui :)
Ahahahahahaha...a me no!!! :P
era ironica la mia affermazione :) XD Avete fatto un ottimo lavoro complimenti!!!!
hihihi..sì sì..l'avevo capito :) Grazie!! Anche voi!!!
1) Ho provato ad inviare un e.mail falsa dalla gmail action e me l'ha accettata. L'indirizzo era
pippo
. Quindi si dovrebbe usare più angular per la parte client quindi meno variabili globali e mettere più controlli sulla parte server. Ho usato un googleChrome con la console e ho cambiato il campo email del json ed è stata inviata.2)Inoltre per ogni campo dalla parte client eseguiamo dei controlli di validità come ad esempio per la temperatura (-70/+70) si dovrebbero anche mettere sul server o ci sono già?