Ahoj, poprosím zkušenější, jestli se náhodou nesetkali s následujícím problémem:
- mám funkční web který potřebuji přenést jinam (Bookedscheduler, rezervační systém)
- na novém serveru jsem provedl čistou instalaci s novou databází, vše běží jak má
- naimportoval jsem kompletní databázi ze starého serveru (mysqldump a potom source)
- všechny tabulky se přenesly bez chyb včetně uživatelů
Nicméně databáze obsahuje uživatelské účty a hesla a při pokusu o přihlášení dostanu hlášku "nesprávné uživatelské jméno nebo heslo". Údaje jsou 100% správné, na starém hostingu účty fungují.
Netušíte prosím kde by mohl být problém?
Pokud je to PHP + SQL, tak zkus nastavit konfiguraci tak, aby se pouzivala krizem (nova instalace a stara DB nebo stara instalace s novou db).
Tj. musis overit zda ta aplikace doopravdy pristupuje k DB (coz asi by zastaveni DB melo udelat nejaky jiny error).
A dalsi vec je, zda se nesaltuji hesla v DB necim jako "hostname ci secret, kde aplikace bezi". Takova vec by zamezila prolomeni hesel kdyby ti unikla jenom DB, ale taky to znamena vetsi opruz pri migraci.
Neznám Booked scheduler, ale dovedu si představit takovýto problém způsobený novou instalací a přenesením DB ze staré. Hesla se typicky ukládají jako hash, ke kterému můžeme mít nějaké nastavení. Některá nastavení snad budou v DB u každého uživatele (třeba typ hashovací funkce a její parametry), ale jsou i parametry, které v DB záměrně nebudou. Někdo může hashe ještě šifrovat klíčem uloženým mimo DB (takže uniklá záloha DB nebude tak hodnotná), někdo k podobnému účelu může používat tzv. pepř (asi to není preferovaná varianta, ale to je už jiná debata). Pokud tato část nastavení nesedí, může to způsobit onen problém s přihlášením.
typujem to na problem s enkodovanim(collation). porovnaj schemy medzi db cez phpmyadmin alebo heidisql alebo podobne ze ci sedi vsetko.
Děkuji všem za rady, zjistil jsem zatím následující:
- kódování je stejné, obojí latin1_swedish_ci
- hesla jsou uložena jako hash, v původní i naimportované databázi taktéž stejné
V příloze je screenshot z mysql (select * from users;)
Citace od: HanzHanz kdy 06. 01. 2023, 03:12:17
- hesla jsou uložena jako hash, v původní i naimportované databázi taktéž stejné
Nejde o to, že by nebyly stejné, ale že ta aplikace ve skutečnosti bude mít někde v konfiguraci magický string, který přidá před/za každé heslo, než ho zahashuje. A tenhle string nemusí být na nové instalaci stejný (může to být třeba hostname nebo cokoliv, tu aplikaci neznáme).
Tj. pokud stará instalace měla v konfiguraci nastaveno "abcde", pak místo heslo "password" ve skutečnosti hashovala "abcdepassword". Pokud nová má v konfiguraci "bleh", bude hashovat "blehpassword" a pak jí samozřejmě ověření hashe neprojde.
Ale pokud je to tohle https://github.com/LibreBooking (čímž si nejsem jistej), tak tam nic takovýho nevidím...
pokial sa jedna o toto https://www.bookedscheduler.com/ predpokladam, ze mas kupenu licenciu a teda aj nejaku formu podpory. Nebolo by jednoduchsie obratit sa rovno na dodavatela SW?
Ano jedná se jedná se o tento sw. Původně phpScheduleit, pak Bookedscheduler, který byl do verze 2.xx opensource, nyní je to placené jako SaaS. Librebooking je fork a pokračování té opensource verze.
Citace od: HanzHanz kdy 06. 01. 2023, 03:12:17
Děkuji všem za rady, zjistil jsem zatím následující:
- kódování je stejné, obojí latin1_swedish_ci
- hesla jsou uložena jako hash, v původní i naimportované databázi taktéž stejné
V příloze je screenshot z mysql (select * from users;)
ten salt je hned vedla password v tabulke users. to asi problem nebude...
nasiel som ale toto https://forums.bookedscheduler.com/viewtopic.php?t=832
pisu na konci: 5. Clear the /tpl_c folder on the new server before you try logging in.
skus mozno to pojde :)
latin1_swedish_ci bude collation (ne kódování), ale u sloupce s heslem je to nejspíš celkem jedno, pokud se tam nedějí nějaké šílenosti. Nejspíš půjde o binární data (možná zakódovaná v hex, base64, nebo něčem podobném), a prakticky jakékoliv kódování bude OK, ledaže by došlo k záměně třeba UTF-8 a UTF-16. Ale to už by byla otázka komunikace s DB...
Salt v tabulce s uživateli – to ano, ale vedle toho se někdy používá ještě pepper nebo šifrování klíčem uloženým mimo DB, jak jsem psal výše.
Chlapi děkuji za rady, stále bez úspěchu...
Napadlo mě zkusit překopírovat pouze jednoho uživatele (jeden záznam, sebe) ze staré databáze do nové pomocí phpmyadmin a pak se zkusit přihlásit. Nicméně nejsem s mysql žádný velký kamarád. Jak to prosím udělat?
Hlásím pokrok...
Do nové databáze jsem k pokusnému uživateli "User" (který měl default heslo "password") nakopíroval hash hesla i salt mého admin uživatele ze staré databáze a nyní je možné se na novém hostingu přihlásit pod "User"/"admin heslo ze staré databáze".
Ne že bych těch uživatelů měl moc, cca 100, ale copy/paste by byl opruz. Je mi jasný, že to tedy půjde udělat hromadně, ale s sql jsem na tom superbídně.
Takže po hromadné migraci to neprošlo a po jednotlivém zkopírování ano?
A v obou případech byl výsledný obsah položky password hash i salt v cílové DB totožný?
To zní nějak divně.
Citace od: Tomas-T kdy 06. 01. 2023, 15:04:38
Takže po hromadné migraci to neprošlo a po jednotlivém zkopírování ano?
A v obou případech byl výsledný obsah položky password hash i salt v cílové DB totožný?
To zní nějak divně.
Podezřívám aplikaci samotnou... Původní a nová verze jsou jiné a původní už není ke stažení. Nová verze má sice migrační nástroj ze staré, ale ač se to tváří, že vše proběhlo v pořádku, přihlášení prostě nefunguje.
Překopíroval jsem tedy pouze tabulku s uživateli pomocí phpmyadmin a už to jde.
Každopádně moc děkuji všem za pomoc! Kdybyste měli chuť si u mě někdo zahrát tenis, máte u mě 1h pronájmu kurtu zdarma (pouze letní provoz) - kousek od Prahy.
Pěkný den!