Backlink – co ho nahradilo?

Duch.Veliky

Ahoj,

rád bych se zeptal, čím bylo nahrazeno

$this->backlink

, když se potřebuji vrátit na předchozí stránku? Dokumentace mi hlásí, že je deprecated

Děkuji za radu :)

Milo

Kde to dokumentace hlásí?

Kamil Valenta

A co to je vůbec za implementaci? V

$this->backlink

může být celkem cokoliv.
A potřebuješ vůbec nějaký backlink? Snad téměř vždy jsem se setkal s tím, že vůbec potřeba nebyl. Většinou je to jen vyrážení klínu klínem, nejčastěji u špatně implementované autentizace.

Marek Znojil

Hádám, že máš na mysli oznámení v Planette.

Avšak, řešení v článku Jak po odeslání formuláře zobrazit stejnou stránku? je stále aktuální.

Kamil Valenta

Vždycky mne dojímá, když někdo vrazí „palec dolů“, místo toho, aby utrousil s čím konkrétně nesouhlasí, nebo věcně oponoval…

A třeba zrovna článek „Jak po odeslání formuláře zobrazit stejnou stránku“ považuju za chybně implementovanou autentizaci, která uměle vytvořila problém, který ještě uměleji „vyřešila“ potřebou backlinku. A pak se člověk ve všech URL napříč systémem tahá s něčím, co třeba vůbec nepotřebuje. Ale možná ho tazatel skutečně potřebuje, nevím, proto jsem se ptal, k čemu ten backlink má být…

Editoval Kamil Valenta (12. 4. 2021 10:43)

Milo

@KamilValenta Ten palec dolů je ode mě. Mě totiž vždycky dojímá, když někdo osvíceně napíše, že je něco špatně a nenapíše k tomu proč. Backlink s autentizací nijak přímo nesouvisí. Buď to vysvětli, nebo nemystifikuj uživatele, že má chybně implementovanou autentizaci.

Marek Bartoš

Já bych se přidal s dotazem, proč je backlink při autentizaci teda špatně, protože je to asi jediný případ, kdy se mi backlink opravdu hodil a netuším, jak jinak bych měl uživatele s expirovaným přihlášením po znovupřihlášení vrátit na stejnou stránku :)

Též nesouhlasím s tím, že by se s ním v url člověk tahal napříč celým systémem. Persistentní backlink definovaný pouze pro Login/SignPresenter bude vžy pouze v url tohoto presenteru, nikde jinde.

Editoval Mabar (12. 4. 2021 12:09)

Kamil Valenta

Výborně, na tohle už se dá nějak reagovat.
Zkus si prosím můj post znovu přečíst, věnuj pozornost slovům „může být“, „snad téměř“, „většinou“ a „nejčastěji“.
Opravdu si myslíš, že osvíceně někomu říkám, že má něco špatně? Že ho mystifikuji, když se teprve ptám na co to potřebuje?
Ano, backlink přímo s autentizací nesouvisí. Netvrdím, že ano. Napsal jsem za sebe, že jsem se s tím tak nejčastěji setkal. Pokud Ty ses s backlinkem setkal častěji v jiných případech, je to zase Tvá statistika a já Ti ji neupírám…

K věci.
Z mého pohledu má HTTP nějaké stavy.
Velice často je autentizace implementovaná tak, že přihlášený dostane na nějaké URL „200“ a nepřihlášený „30x“ a je redirectován na oddělené přihlášení. Tím se mu změní URL a složitě se pak řeší, jak ho vrátit zpět.
Proč vůbec dostal „30x“, jaký je k tomu důvod?
Já nepřihlášenému uživateli vracím „401“ a v response mu hned vykreslím přihlašovací formulář. URL se mu nemění, takže pak nepotřebuji žádný backlink. Jsem přesvědčen, že je v pořádku za nějakých okolností dostat z URL „401“ a za jiných okolností „200“.
Je to velmi pohodlné, když někomu přihlášení expiruje, nebo když dělám proklik např. z emailu a on se musí teprve přihlásit, vždy pak hned pokračuje na téže URL.

Marek Bartoš

Ono nejde pouze o uložení url adresy, ale uložení celého requestu. Kdybys odesílal formulář, tak si to mechanizmus store/restoreRequest() zapamatuje. Oceníš, když vyplňuješ nějaký komplexní formulář a v okamžiku když ho odešleš už jsi odhlášen. Stačí se znova přihlásit a formulář se zpracuje.

Kamil Valenta

Mabar napsal(a):

protože je to asi jediný případ, kdy se mi backlink opravdu hodil

Souhlasím. Také to nejčastěji vídám u autentizace.

a netuším, jak jinak bych měl uživatele s expirovaným přihlášením po znovupřihlášení vrátit na stejnou stránku :)

Jak jsem již psal, já hlavně nevidím důvod uživatele posílat někam pryč, takže ho pak ani nemám potřebu někam vracet :)

Též nesouhlasím s tím, že by se s ním v url člověk tahal napříč celým systémem. Persistentní backlink definovaný pouze pro Login/SignPresenter bude vžy pouze v url tohoto presenteru, nikde jinde.

Jo, tohle dává smysl. Netuším, proč to někdo tedy tahá celým systémem, ale už vícekrát jsem se s tím setkal. Já to nepoužívám vůbec, tak jsem nad tím do hloubky nepřemýšlel.

Kamil Valenta

Mabar napsal(a):

Ono nejde pouze o uložení url adresy, ale uložení celého requestu. Kdybys odesílal formulář, tak si to mechanizmus store/restoreRequest() zapamatuje. Oceníš, když vyplňuješ nějaký komplexní formulář a v okamžiku když ho odešleš už jsi odhlášen. Stačí se znova přihlásit a formulář se zpracuje.

Ano, storeRequest LoginForm získá z forwardu toho presenteru, redirect na současnou URL to zichruje pro případ, že expiruje celá sessiona, takže restoreRequest selže…

Milo

@KamilValenta Reagoval jsi protivně, já na oplátku taky. Ptal jsem se @DuchVeliky, kde to dokumentace tvrdí, aby se to v ní mohlo případně dořešit. Toho se držím.

Kamil Valenta

Milo napsal(a):

@KamilValenta Reagoval jsi protivně,

Pokud toto myslíš vážně, tak můžeme toto téma ukončit a pokračovat v čekání na odpověď co, jak a proč má tazatel implementováno.