Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
SELECT ENCRYPT('nějaké-heslo')
vrátí asi takovýto řetězec: MeXkFnYUhP7cw
Jakou funkcí v PHP dosáhnu stejného výsledku ? Koukal jsem na mcrypt, crypt, ale stejně jsem nenašel tu správnou
Díky za radu.
password()
.
encrypt()
v MySQL je definovaná dost vágně na to, aby mohla být implementována někde jinde ještě jednou a bylo zaručeno, že obě implementace budou vracet vždy stejné výsledky.
SELECT * FROM .... WHERE ...
uděláš SELECT *, password = ENCRYPT(vstupoduzivatle) as spravneheslo FROM ... WHERE ...
a je to. Nevidim kde je problém.
Nebo taky
SELECT * FROM ... WHERE password = ENCRYPT(vstupoduzivatle) AND ...
podle toho, na co to potřebuejš...
encrypt()
i druhý parametr. Nějak se na něj zapomíná.
Jinak je samozřejmě nesmysl tahat zašifrované heslo z databáze a snažit se ho porovnávat v PHP. Na to máme SQL.
SELECT encrypt('heslo');Pokaždé to vygeneruje něco jiného. První 2 znaky jsou použitá sůl. Když výsledek uložíš do sloupce např. password, tak pro ověření stačí:
SELECT encrypt('heslo',password)=password;Z uloženého hesla
password
použije jen první 2 znaky.
encrypt()
bere z šifrovaného řetězce jen prvních 8 znaků, zbytek ignoruje. Možná proto je místo ní doporučena funkce password()
, která bere v potaz všechny znaky.
// overime existenci mailove schranky
if ($db->query("SELECT email FROM users WHERE email = '$_REQUEST[email]'")->num_rows) {
// overime spravnost zadaneho hesla, bohuzel musime primo imap pripojenim, protoze funkce encrypt v MySQL vraci pokazde jiny retezec
if ($mbox = @imap_open("{127.0.0.1:143/notls}", $_REQUEST['email'], $_REQUEST['old-password'])) {
...
Abyste chápali čeho jsem chtěl dosáhnout - chtěl jsem umožnit uživatelům měnit heslo do jejich schránky.
SELECT (ENCRYPT('ahoj','AB'));Dá vždy stejný výsledek.
ENCRYPT('ahoj','TG');(respektive jako
ENCRYPT('ahoj')
, kde se náhodně vygenerovalo to 'TG')
SELECT CASE WHEN 'TGlcRH68Dkg3g' = ENCRYPT('ahoj',SUBSTRING('TGlcRH68Dkg3g',1,2)) THEN 'rovna se to' ELSE 'NErovna se to' END AS result;Prostě si musíte vzít ty první dva znaky z uloženého encrypt-ovaného řetězce a použít je jako salt.
ENCRYPT()
- ba naopak .
encrypt('heslo',password)=passwordJako druhý parametr dáš to šifrované heslo v databázi.
ENCRYPT()
bere jen tolik znaků kolik potřebuje, takže ten SUBSTRING()
co jsem psal výše, je naprosto zbytečný až špatný.
if ($db->query("SELECT email FROM users WHERE email = '$_REQUEST[email]'")->num_rows) {
$_REQUEST[]
je protažen mysql_escape_string
em
Jen to prostě ukazuje na to, že používáte něco, s čím neumíte zacházet. A to prostě není dobře, protože jednou vyrobíte prasečinu, která už nevinná nebude.
Fajn, řekněme - smyšelný příklad - že najezdím ročně kolem 200 tisíc kilometrů (jakožto zahraniční řidič tahače), osobní auto umím řídit i se zavázanýma očima a mám za tu dobu za sebou jednu nehodu, kterou jsem nezpůsobil.
Vy najezdíte jakožto běžný motorista ročně kolem 15ti tisíc a máte za sebou třeba 2 zbořená auta vlastní vinou.
Jsem oprávněn Vám říkat, že používáte něco s čím neumíte zacházet a to prostě není dobře, protože jednou někoho zabijete a to už tak nevinné jako sešrotovaná auta nebude ? Je to cesta do pekel.
mysql_escape_string
em odpovídá mému požadavku a jeho formát není nikterak pozměněn.
Mě to naopak připadá jako zbytečné plácání proměnnými. Pokud vám jde čistě jen o modifikaci hodnot v gobálním poli, tak můžu samotnou fci escape_stringu přesunout s klidem do složené části SQL dotazu, kdy se nic modifikovat a znovu přiřazovat nebude.
Ale tohle, jsou jen detaily u tak jednoduché části kódu, jako je ten, který jsem napsal. Modifikace hodnot v globálním poli je možná trošku prasečina a možná se to ani nemá, ale v mém případě použití to nehraje roli.
SELECT * FROM tabulka;
", který nacházím i v komerčních aplikacích. Prostě si to někdo zjednodušil a pak už se k danému kódu nevrátil, protože mu připadal OK. Chybu to nezpůsobí hned a nemusí to způsobit nikdy, ale udržovatelnosti programu to neprospěje. Ovšem je to mnohem menší zlo, než modifikace superglobálních polí.
mysql_escape_string
k přepsání hodnoty pole z požadavku je první polovina vytvoření SQL injection. Pak se vám někde stane, že tu hodnotu escapujete dvakrát, jako opravu to escapování zrušíte a tam, kde se to escapovalo správně jednou, máte vyrobené SQL injection. Mnohem lepší je vyhnout se přepisování parametrů požadavku, vyhnout se i mysql_escape_string
a použít parametrizované dotazy.
Tiskni Sdílej: