Společné přihlášení v rámci dvou aplikací
- iwory
- Člen | 147
Zdravím, možná plánuji řešit neřešitelnou situaci nebo je to blbost, ale i tak se zeptám :)
Na hostigu beží již 3 roky Nette aplikace která funguje a je ok.
Nicméně se teďka začaly dělat nové výstupy které se píší v nové
Nette aplikaci jelikož v té staré není vše zrovna optimálně řešeno a
je lepší postupně aplikaci přemigrovávat než to celé přepisovat.
Takže současná struktura je:
--app
--www
--temp
----cache
----sessions
--log
...Teďka bych chtěl spustit aplikace paralelně, takže bych strukturu změnil na:
--old
----app
----www
----temp
------cache
------sessions
----log
--new
----app
----www
----temp
------cache
------sessions
----log
...pomocí rootového .htaccessu bych akorát řídil která aplikace se má načíst podle požadavku klienta.
Problém je ale samozřejmě v přihlášení bez kterého se do aplikace nedostanete. Pakliže se přihlásím ve staré aplikaci a přejdu do nějakého modulu/funkcionality která je již v nové aplikaci, tak mne bude chtít aplikace logicky přihlásit a to je ta věc které se chci vyhnout.
Dávám mi smysl vydefinovat společný user storage jelikož obě apliace budou pracovat se stejnou DB a stejnými daty ale nevím zda je to optimální řešení a jak na to…
Další otázka je, zda to takto vůbec řešit nebo jsou jiné cesty?
Díky moc za názory
Editoval iwory (30. 9. 2016 13:38)
- Tharos
- Člen | 1030
Neřešil jsi tu už jednou něco podobného? :)
https://forum.nette.org/…i-v-aplikaci#…
Pokud naopak potřebuješ být automaticky přihlášený ve více aplikacích, nejjednodušší cestou je IMHO sdílená session storage a používat stejný jmenný prostor.
Editoval Tharos (30. 9. 2016 16:03)
- iwory
- Člen | 147
Tharos napsal(a):
Neřešil jsi tu už jednou něco podobného? :)
https://forum.nette.org/…i-v-aplikaci#…
Pokud naopak potřebuješ být automaticky přihlášený ve více aplikacích, nejjednodušší cestou je IMHO sdílená session storage a používat stejný jmenný prostor.
Ano, kdysi jsem to řešil a byla to první věc na kterou jsem se podíval :-D Ale neřeší to aktuální problém.
Takže čistě teoreticky sdílená session storage není tolik špatné
řešení?
Snad jen, lze nějak elegantně oddělit sessions storage třeba jenom
u uživatele aniž bych to musel nějak šíleně ohýbat?
- Tharos
- Člen | 1030
Takže čistě teoreticky sdílená session storage není tolik špatné řešení?
Tak pochopitelně nejsofistikovanějším řešením by bylo mít nějaký stand-alone identity server. :) Ale představ si ten overhead… Cost vs. benefit někde v oblacích. Proto já bych se sdílené session storage v tomhle případě nijak zásadně nebránil.
Jen je dobré si uvědomit, jaká to má rizika. Takovéto sdílení není principiálně dobré proto, protože pak se aplikaci A může jistým způsobem hrabat v datech aplikace B a naopak a žádná z nich pak pochopitelně nemůže garantovat konzistenci těch dat. Je proto vhodné s tím související kód napsat trochu s důrazem na robustnost… Jinak bych se toho ale vůbec nebál.
Snad jen, lze nějak elegantně oddělit sessions storage třeba jenom u uživatele aniž bych to musel nějak šíleně ohýbat?
Zkusím se přes víkend pro zajímavost podívat. :)
Editoval Tharos (30. 9. 2016 18:45)
- iwory
- Člen | 147
Jen je dobré si uvědomit, jaká to má rizika. Takovéto sdílení není principiálně dobré proto, protože pak se aplikaci A může jistým způsobem hrabat v datech aplikace B a naopak a žádná z nich pak pochopitelně nemůže garantovat konzistenci těch dat. Je proto vhodné s tím související kód napsat trochu s důrazem na robustnost… Jinak bych se toho ale vůbec nebál.
Tak to určitě, v tomhle případě jde jenom primárně o tom, udržet pro uživatele session při přechodu mezi aplikacemi. Postupně se bude aplikace přepisovat do nové a ze staré nebude funkcionalita dostupná, takže by se funkcionality neměly nikde křížit :)
Díky moc :)
- Tharos
- Člen | 1030
O víkendu jsem o tom tedy lehce přemýšlel a řešil bych to zhruba následovně…
Mějme aplikaci A se sessions v namespace A a aplikaci B se sessions v namespace B. Aplikace A je ta historická, B je nově psaná.
V aplikaci B bych rozšířil nativní UserStorage takovým
způsobem, že pokud se v IUserStorage::isAuthenticated zjistí,
že uživatel není přihlášen, provedl bych ještě „fallback“ do
namespace A a podíval bych se, jestli náhodou není uživatel přihlášen
tam (tzn. v aplikaci A). Pokud ano, i v namespace B bych ho označil za
přihlášeného a také bych do namespace B nahrál správnou identitu (pomocí
IUserStorage::setIdentity, koukni se, jak to dělá
Security\User::login). Samozřejmostí je pak kontrola, zda taková
identita v aplikaci B vůbec existuje…
Nazval bych to takovým řízeným sdílením té informace o přihlášení, ale zároveň s absencí míchání dat. Jediné křížení tam je, že aplikace B čte session data aplikace A, což není až taková hrůza. A navíc čte jenom jen tu jednu jedinou informaci, a totiž, zda je uživatel přihlášen.
Dává to smysl? :) Dáš z toho dohromady kód? :)
Editoval Tharos (2. 10. 2016 21:08)