Meglepő dolgok történnek, amikor felhasználóként egy Excel munkalapon lévő linkre kattintunk. Valószínűleg fel sem tűnik, hogy mi történik a háttérben, amíg nem próbálunk egy olyan oldal megnyitni, ami csak bejelentkezés után érhető el. Újabb mizéria a sütikkel.
Hozzá vagyunk szokva, hogy ha egy Excel dokumentumban rákattintunk egy linkre, akkor a kedvenc böngészőnk megnyitja az oldalt. A látvány alapján nyugodtan gondolhatjuk, hogy ez a folyamat játszódik le:
- A linkre kattintás után az Excel átadja a shellnek az URL-t, ami elindítja az alapértelmezett böngészőt.
- A böngésző megnyitja a kért URL-t.
- A webszerver visszaküldi a HTML választ.
Logikus nem? Az, csakhogy nem ez történik a valóságban!
Az elmélet és a gyakorlat közötti különbség akkor tűnik fel, amikor a kért oldalt authentikáció védi. Azt gondolnánk, hogy ha korábban be voltunk jelentkezve a böngészőnkben és megvan az authentikációs süti, akkor a második lépésben a böngésző azt szemrebbenés nélkül hozzácsapja a kéréshez, így az Excelből indított kéréseink is a bejelentkezett felhasználó nevében fogják elérni a szervert. Fájdalom, de nem.
A valóság – mint mindig – egy kicsit bonyolultabb, az Excel ugyanis megpróbál a böngésző helyett dolgozni:
- A linkre kattintás után az Excel küld egy HTTP kérést a kívánt URL-re a webszervernek.
- A webszerver visszaküldi a kért dokumentumot az Excelnek.
- Az Excel átadja a shellnek az URL-t, ami elindítja az alapértelmezett böngészőt.
- A böngésző megnyitja a kért URL-t.
- A webszerver visszaküldi a kért dokumentumot a böngészőnek.
Először tehát az Excel próbálja meg letölteni a kért erőforrást a webszerverről, és ha sikerült (HTTP 200 OK a válasz), akkor nyitja csak meg a böngészőt, hogy a felhasználó is lássa az eredményt. Szomorú, de a jelek szerint valójában kétszer jön át a kért fájl a hálózaton. Hogy ennek mi a pontos oka, azt nem tudom, de tény, hogy ha bármilyen hiba van – hálózat, HTTP 40x-50x – akkor nem nyílik meg a böngésző, hanem a hibaüzenet közvetlenül az Excelben jelenik meg. Lehet, hogy ez így felhasználóbarátabb.
Ezzel még így együtt is tudnánk élni, de kellemetlen meglepetések érhetnek, ha a hivatkozott erőforrás csak bejelentkezés után érhető el. Ekkor a következő történik:
- A linkre kattintás után az Excel küld egy HTTP kérést a kívánt URL-re a webszervernek.
- Mivel az erőforrás védett, a webszerver egy HTTP 302 Redirect válaszkóddal átirányít a Login.aspx oldalra, query stringben átadva az eredeti URL-t.
- Az Excel lekéri a Login.aspx oldalt, query stringben átadva az eredeti URL-t.
- A webszerver visszaküldi a Login.aspx HTML kódját HTTP 200 OK válasszal.
- Az Excel átadja a shellnek a redirect választban hivatkozott URL-t, azaz a Login oldal URL-jét a query stringgel.
- A böngésző megnyitja a Login.aspx oldalt, query stringben átadva az eredeti URL-t.
- A webszerver visszaküldi a Login oldal HTML kódját.
Az Excel megint a böngésző helyett dolgozik: először lekéri a kért erőforrást, de ha az máshol van, akkor már csak az átirányított URL-t adja át a böngészőnek. Ez sok esetben a bejelentkezést megvalósító Login oldal. Azonban amikor a 6. lépésben a böngésző megnyitja ezt az URL-t, akkor már lelkesen mellé csapja a login cookie-t, így a webszerver azt fogja látni, hogy a felhasználó már be van jelentkezve. De akkor mit keres a login oldalon?
Mit tehetünk ilyenkor a login oldalon:
- Ha a felhasználó már be van jelentkezve és van returnUrl paraméter a query stringben, szó nélkül átirányítjuk oda. Újabb redirect, villanás és töltés, de végül meg fogja kapni a felhasználó a kívánt oldalt.
- Hibaüzenet, hogy a login oldal nem bejelentkezett felhasználóknak való. Talán ez a legbarátságtalanabb megoldás.
- Megjelenítjük a login oldalt, hátha más felhasználó nevében akar belépni, de akkor vigyázzunk, hogy a fejlécben, vagy máshol ne szerepeljen az aktuálisan belépett felhasználó neve.
Ez így látszólag működik is, de csak akkor, ha a login oldal nem azzal kezdi a pályafutását, hogy az előzőleg bejelentkezett felhasználó nyomait teljesen kiírtja (sütik törlése, session lezárása stb.).
Egy kicsit kellemetlenebb a helyzet, ha a kért oldalt ugyan bejelentkezés nélkül is el lehet kérni, de csak bizonyos feltételek esetén, például ha az oldalhoz tartozó entitás állapota ezt engedélyezi (például csak akkor, ha “jóváhagyott” státuszban van) vagy ha a felhasználó be van jelentkezve (például admin). Ekkor ugyanis tipikusan nem az ASP.NET gondoskodik az erőforrás védelméről, hanem az oldal forráskódja ellenőrzi, hogy a kérés és az üzleti objektum összhangban van-e egymással. És ha nem, akkor mit lehet tenni, át lehet irányítani egy “Nincs jogod az oldal megtekintéséhez” hibaoldalra.
Helyettesítsük be ezt a fenti hét lépcsős folyamatba:
- A linkre kattintás után az Excel küld egy HTTP kérést a kívánt URL-re a webszervernek.
- Mivel az erőforrást nem szabad megjeleníteni, a weboldal egy HTTP 302 Redirect válaszkóddal átirányít a PermissionDenied.aspx egyedi hibaoldalra.
- Az Excel lekéri a PermissionDenied.aspx oldalt.
- A webszerver visszaküldi a hibaoldal tartalmát HTTP 200 OK válasszal.
- Az Excel látja, hogy ez a jó cím, ezért átadja a shellnek a PermissionDenied.aspx oldal URL-jét.
- A böngésző megnyitja a PermissionDenied.aspx oldalt, de a kéréshez mellékeli az authentikációs sütit is.
- A webszerver visszaküldi a hibaoldal kódját.
Valójában tehát a kliens meg sem próbálja úgy letölteni a fájlt a szerverről, hogy a felhasználó bejelentkezését igazoló sütit odatenné a kérés mellé! Ha az oldal fejlécében ráadásul az is szerepel, hogy ki az aktuális felhasználó, akkor azt fogja látni a felhasználó, hogy be van jelentkezve, de nincs joga megtekinteni az oldalt. Képzeljük el, mit szól ehhez egy admin!
Ha nem akarjuk, vagy nem tudjuk átírni az ellenőrző logikánkat, akkor a megoldást egy kliens oldali átirányítás jelentheti:
Nem írom le az összes lépést, a lényeg, hogy az Excelből egy olyan URL-re hivatkozunk (1. és 4. lépés), amire a szerver válaszul egy olyan META fejléces HTML markupot küld vissza (2. és 5. lépés), aminek hatására aztán végül a böngésző irányít át a valódi URL-re (6. lépés). Ezzel kijátszottuk az Excel okoskodását és biztosak lehetünk abban, hogy a böngésző biztosan oda fogja tenni a kérés mellé az authentikációs sütit.
Ez a cikk nem jött volna létre, ha nincs a Fiddler.
Balássy György szakmai blogja 