Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
Několik zásad, jak (ne)validovat e-mailové adresy.
S většinou webových lepilů je problém v tom, že přehnaně kontrolují e-mailové adresy, typicky za pomoci regexpů od jiných lepilů. Ukažme si tedy, jak vypadají platné e-mailové adresy:
"Abc@def"@example.com
- povšimněte si, že při zpracování stringu nemůžete spoléhat na to, že za prvním zavináčem je doména!Fred\ Bloggs@example.com
- ano, v adrese mohou být i mezeryuser+mailbox@example.com
- tohle je podoba adresy, kterou často využívám, přesto ani po dohadování s dutými hlavami na tech. podpoře neuznají svou chybucustomer/department=shipping@example.com
- extravagantní, ale stále validní$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com
Jak říká RFC 3696 (a další, hlavně 5322, je toho vícero a je důležité číst i erraty), v místní části e-mailové adresy se může nacházet libovolný tisknutelný znak s výjimkou @ \ , " [ ] < > : ; ( )
, přičemž i tyto znaky se vyskytnout mohou, pokud jsou escapovány. Už jen drobností je, že nemůžeme mít víc teček za sebou nebo že některé znaky nemohou uvozovat nebo ukončovat místní část, ale to už si můžete přečíst v RFC.
Důležité je nesnažit se přehnaně validovat ani doménové jméno. V době TLD typu .museum
je absurdní povolovat za poslední tečkou jen tři znaky.
Než vymýšlet hovadiny vyjde lépe si v řetězci najít poslední zavináč a jednoduše zkontrolovat, zda je doménové jméno validní. Před tímto zavináčem se raději nechovat jako kozel zahradníkem a nekontrolovat nic, než to kontrolovat blbě. Pro jistotu se podívat, jestli se do řetězce nedostaly netisknutelné znaky. Jak prosté!
Tiskni
Sdílej:
xyz@[IPv6:2001:4f8:0:2::18]
a k cemu tam takova adresa bude? proc ju tam vubec ukladat?
ano krasne je jak je validni, a k cemu takova adresa bude? kdyz tam budou sice krasne propasovane paznaky ktere jasne slouzi k ucelu poskozeni a ne kontaktu? proc mam tolerovat nejake hovna vkladane do databaze?
kdyz tam budou sice krasne propasovane paznaky ktere jasne slouzi k ucelu poskozeni a ne kontaktu? proc mam tolerovat nejake hovna vkladane do databaze?Pokud lze tvá aplikace poškodit (ať už XSS nebo nějaká forma SQL injection), hledal bych chybu nejprve v ní.
ja to samozrejme escapuju i pri vypisu :) o tom se tu snad nekdo bavi? ja se ptam proc bych mel poustet do databaze takove hovna, je tu nekdo schopny nato odpovedet?:)
<script>do_something_nasty(vole);</script> toto je validni jmeno? co muzu od takoveho uzivatele cekat za odpoved kdyz mu napisu?
az narazim na problem kdy si u me bude uzivatel s adresou <tak to mam hustej mejl>@.... stezovat tak budu brat vytku zobacku vazne, jeste jsem nenarazil na cloveka se zobackovou adresou :)
Ostatně zrovna ten login také z technického hlediska může být jakýkoliv řetězec, ale najděte mi soudného správce, který povolí uživateli login / jméno / nick ".-+~~+-.".To je nápad. Kolotoč!
jen tak mimochodem zkousel jsi takovej email zadat zde na abicku v profilu?;)
A mohu vědět, která třída to je?
V API jsem na žádnou takovou nenarazil, většinou jsem viděl validaci přes vlastní implementaci nějakým regulárním výrazem.
Děkuji
if (document.register.email.value.indexOf("@")<1) {alert("Toto nie je platná emailová adresa !"); document.register.email.focus(); return false;} txt=document.register.email.value; if ((txt.indexOf(".com")<5)&&(txt.indexOf(".cz")<5)&&(txt.indexOf(".org")<5) &&(txt.indexOf(".gov")<5)&&(txt.indexOf(".net")<5)&&(txt.indexOf(".sk")<5) &&(txt.indexOf(".mil")<5)&&(txt.indexOf(".edu")<5)&&(txt.indexOf(".as")<5)&&(txt.indexOf(".info")<5) &&(txt.indexOf(".eu")<5)) {alert("Toto nie je platná emailová adresa !"); return false;}
Samý jedničky, heč
Opravdu si myslíš, že je s tebou všechno v naprostém pořádku ?
Škoda, zkoušel jsem registrovat novou e-mailovou adresu <script>alert(\"My name is George\")\;</script>@gmail.com ani &tl;script >alert(\"My name is George\")\;</script>@seznam.cz mi neprošlo. Budu to muset zkusit doma na mém eximu ...
Nebo prohlásili UTF-8 jako jediné správné?Asi tak. Je to ASCII kompatibilní a obsáhne to všechno...