ASP.NET 4.0 űrlap alapú hitelesítés IE11 alatt

Korábban már említettem, hogy a böngészők detektálásán alapuló megoldások gondot okozhatnak, amikor megjelenik egy új böngésző vagy egy új böngésző verzió. Sajnos mivel az ASP.NET korábbi verziói is tartalmaznak böngésző detektálós részeket, az Internet Explorer 11 megjelenése ott is gondot okozhat.

Véletlen egybeesés, hogy az említett cikk után egy nappal Eric Lawrence is írt egy cikket az IE11-ről és a User-Agent sniffingről. Néhány érdekesség belőle:

• Az IE csapat szándékosan úgy választotta meg a UA stringet, hogy a weboldalak inkább WebKites böngészőnek ismerjék fel, mint régebbi IE verziónak.
• A nyár folyamán az ASP.NET csapat kiadott frissítéseket a probléma megoldására, például .NET 4.0-hoz a KB2836939-et. A többi frissítés listája megtalálható a cikkben.

Mi egy olyan problémába futottunk bele korábban, hogy az IE11 lelkesen felküldte az ASP.NET forms authentication cookie-t a szervernek, de a szerver fittyet hányt rá. A web.config fájlban lévő forms elemnél korábban nem szerepelt a cookieless attribútum, mert az alapértelmezett UseDeviceProfile eddig tökéletesen működött, most viszont explicit módon be kellett állítanunk a UseCookies értéket, hogy az oldal IE11-gyel is működjön rendesen.

Itt egy régebbi szerverről volt szó, amin ASP.NET 4.0 futott a fenti frissítés nélkül, 4.5-ön ezt nem tapasztaltuk.

Megjegyzem a cookieless="UseCookies" biztonság szempontból is a javasolt beállítás.

 

Technorati-címkék: IE,Windows 8,ASP.NET,security

IE11 User-Agent string

A Windows 8.1-ben megjelenő Internet Explorer 11-hez tartozó User-Agent string (ez az, amit a HTTP kérésben a böngésző felküld a szervernek) a következő:

Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

Akkor lesz nyilvánvaló, hogy mi ebben az érdekes, ha összehasonlítjuk a korábbiakkal, például az IE10 és az IE9 azonosítójával:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

A formátum tehát teljesen megváltozott, sőt az MSIE jelölés teljesen eltűnt! Ez akkor okozhat gondot, ha valamilyen kliens vagy szerver oldali kódunkba böngészőfüggő viselkedést írtunk, ugyanis a régebbi kódunk nem biztos, hogy jól fogja felismerni az új böngészőt.

Az ASP.NET platformban is vannak olyan részek, amik tekintettel vannak a kliens böngészőjére, és sajnos korábban már volt rá példa, hogy egyes funkciók nem jól működtek az újabb böngészőkkel.

Szerencsére az ASP.NET böngésző detektáló része a .browser fájlok segítségével rugalmasan alakítható, amit az is jól mutat, hogy Windows 8.1-en a C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers mappában található ie.browser fájl már az új User-Agent stringnek megfelelő részt is tartalmaz:

<browser id="InternetExplorer" parentID="Mozilla">
   <identification>
     <userAgent match="Trident/(?'layoutVersion'[7-9]|0*[1-9]\d+)(\.\d+)?;(.*;)?\s*rv:(?'version'(?'major'\d+)(\.(?'minor'\d+)))" />
     <userAgent nonMatch="IEMobile" />
     <userAgent nonMatch="MSIE " />
   </identification>
   <capabilities>
     <capability name="browser"              value="InternetExplorer" />
     <capability name="version"              value="${version}" />
     <capability name="majorversion"         value="${major}" />
     <capability name="minorversion"         value="${minor}" />
     <capability name="layoutEngine"         value="Trident" />
     <capability name="layoutEngineVersion"  value="${layoutVersion}" />
     <capability name="type"                 value="InternetExplorer${major}" />
   </capabilities> 
</browser>

A tapasztalatunk az, hogy érdemes tesztelni az új böngészővel a régi webalkalmazásokat, még akkor is, ha a saját kódunkba nem írtunk böngészőfüggő részeket, mert a platform is tartalmaz ilyeneket. Különösen akkor érdemes odafigyelni, ha a szerver oldalon még ASP.NET 4.0 van, tehát nem a legfrissebb 4.5 (amit az in-place upgrade miatt nem mindenhol mernek telepíteni).

Egy következő cikkben írok majd néhány konkrét ASP.NET-es problémáról, amibe belefutottunk IE11-gyel.

 

Technorati-címkék: ASP.NET,browser,IE

Outlook Web App nem csak light verzióban IE 11 alatt

Aki frissített Windows 8.1-re és megpróbálta elérni az OWA-t Internet Explorer 11 alól, az valószínűleg szomorúan tapasztalta, hogy csak “light version”-ben hajlandó működni:

Ez azért kínos, mert a light verziót pont a kőkorszaki böngészőkre találták ki, az IE11 viszont igen csak modern böngészőnek számít, még akkor is, ha csak preview állapotban van.

A megoldás, hogy az adott webhelyet compability mode-ban jelenítjük meg. Erre egyik lehetőség, hogy felvesszük a webhelyet a Compatibility List-re a Tools –> Compatibility View Settings ablakban:

Ez nálam annyira nem jött be, mert csak a top-level domain kerül be a listába. Így aztán kihasználtam, hogy az első jelölőnégyzet szerint az intranet oldalak alapértelmezés szerint kompatibilitási nézetben jelennek meg, és felvettem az OWA címét az Intranet zónába tartozó webhelyekhez a Tools –> Internet Options –> Security –> Local intranet –> Sites –> Advanced ablakban.

Fórum bejegyzések szerint hasonló probléma van az Office 365-tel és néhány népszerű weboldallal, például a GitHubbal is.

 

Technorati-címkék: Internet Explorer,Windows 8,Exchange