Konečné řešení komponenty vyhledávacího formuláře nebo login formuláře?

Konečná řešení mám velice rád :)

Ale vážně, zrovna dneska řešíme problém s přihlašovacím formulářem. Klasická potíž je, jak přesměrovat uživatele po přihlášení na tu stránku, na které se přihlásil.

V zásadě jsou dvě možná řešení:

1. Každá stránka umí přihlášení (tj. signál login v BasePresenteru například)
2. Na přihlášení je dedikované URL/presenter a používá se nějaký mechanismus přesměrování zpět

Řešení A) se jeví jako snadnější (velmi lehce se dostaneme zpět na stránku, kde uživatel klikl na „přihlásit“), ale v praxi se moc nevidí. Přemýšlel jsem, proč tomu tak je a napadlo mě několik důvodů:

• problémy se subdoménami:
  • „zapamatovat přihlášení“ v prohlížeči je vázané na doménu
  • přihlašování přes SSL (certifikát vázaný na doménu)
• phishing: není možné uživateli vtloukat do hlavy, že jediný správný formulář je na této (snadno zapamatovatelné) URL

Tenhle způsob jsem tedy musel zavrhnout a zbývá nám varianta B) a otázka: Jak nejlépe řešit přesměrování zpět na stránku, na které uživatel klikl na „příhlásit“ ?

• posílat zpětný link v GET parametrech
• referer

Obojí má svoje výhody a nevýhody, které tady nebudu rozepisovat, rád bych se totiž zeptal na váš názor a zkušenosti, popřípadě se přimluvil za příslušný oddíl v dokumentaci, nějaké best practices apod.

To si úplně nerozumíme, ale to je asi i moje vina, takže to rozvedu a doplním:

Nejde mi o situaci, kdy by vedl přímo nějaký odkaz na stránku dostupnou jen přihlášeným uživatelům s určitými právy (to řeší store a restoreRequest). Jde mi o situaci, kdy nepřihlášený uživatel má web dostupný „read-only“ a po přihlášení jsou mu dostupné další funkce. Pokud tedy nejsem přihlášený, mám na každé stránce někde odkaz „přihlásit“, který má uskutečnit přihlášení a přesměrovat zpět tam, kde jsem na ten odkaz klikl.

Z důvodů uvedených výše je použitelná pouze varianta B, přihlašování má vlastní presenter a mechanismus přesměrování zpět. Samozřejmě AuthPresenter tedy musí znát stránku, na kterou má přihlášeného uživatele vrátit. Přináší to minimálně tři problémy:

• na některé presentery nemá smysl/je nežádoucí přesměrovávat zpátky (například registrační formulář, odhlášení uživatele apod.)
• hlídat podstrčenou cizí URL (technicky to ničemu nevadí, ale je to hloupé)
• kvůli požadavku na jedinou přihlašovací URL je nutno odkaz na původní stránku nemít v URL

Napadly mě tři varianty řešení:

1. mít signál login na BasePresenteru, který udělá storeRequest a pošle na login URL
2. posílat odkaz v GET parametru na login URL
3. využívat referer

První a druhý problém by se dal vyřešit elegantně tím, že si URL přeložím na PresenterRequest a odfiltruju nežádoucí Presentery. Třetí problém řeší sama třetí varianta, ostatní by si musely informaci o zpětné URL uložit do session.

Druhé dvě možnosti jsou implementačně jasné, mě zajímala hlavně první možnost, protože umožňuje zabít dvě mouchy jednou ranou. Nelze podstrčit URL a snadno zkontroluji, jestli má smysl přesměrovávat na původní stránku, protože musím pracovat s původním PresenterRequestem.

Ta se bohužel dá v Nette udělat jen poměrně prasácky, protože neumožňuje uložení modifikovaného PresenterRequestu (je potřeba v něm zrušit daný signál). Musel bych tedy reimplementovat Application::storeRequest, a uložit klon posledního PresenterRequestu, kterému zruším parametr do (aby nedošlo k opětovnému zavolání signálu login na původním Presenteru). Ovšem funguje to a zatím jsem na nic lepšího nepřišel, takže používám tohle řešení.

Na závěr opět otázka: Jde to udělat jednodušeji a lépe?