Fórum Root.cz
Hlavní témata => Server => Téma založeno: HanzHanz 05. 01. 2023, 23:41:24
-
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;)
-
- 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.
-
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ě.
-
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!