A következő címkéjű bejegyzések mutatása: authentikáció. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: authentikáció. Összes bejegyzés megjelenítése

2015. szeptember 15., kedd

HTTPS-re átirányítás, Form authentication és duplázódott URL paraméterek

Rendszeresen előfordult, hogy a felparaméterezett linkre bejelentkezést követően hibát dobott az ASP.NET codebehind, mondván, hogy nem megfelelő egy vagy több paraméter formátuma. A belépést követően megnézve a linket jogos volt a hibaüzenet, mivel duplázódott mindegyik paraméter, emiatt a QueryString vesszővel összefűzve adta vissza őket.

Ezt a duplázódást a Form authentication csinálta. Védett tartalom elérésekor átirányít a beléptető oldalra, és közben elteszi egy ReturnUrl paraméterbe az eredeti link URL kódolt változatát. Azért, hogy a beléptető oldalon is elérhetők legyenek a paraméterek anélkül, hogy az egész linket fel kéne dolgozni, melléteszi külön a paramétereket is, Ennek hatására a paraméterek kétszer fognak szerepelni: URL kódolva és anélkül.  

A probléma ott folytatódott, hogy nem volt a ReturnUrl tartalma URL kódolva. Kiderült, hogy a HTTP kérések HTTPS-re való átirányítása hibásan történt az ősosztály Page.OnLoadjában.

Az alábbi kód bár kézen fekvőnek tűnik, nem az elvártnak megfelelően működik, az URI.ToString() dekódolva adja vissza az URL-t:
Response.Redirect(Request.Url.ToString().Insert(4,"s"))

Egy lehetséges megoldás a helyes átirányításra:
Request.Url.Scheme + "s://" + Request.Url.Authority + Request.RawUrl;

A HTTPS-re való átirányítás után így már megmaradt a helyesen kódolt URL, azaz a ReturnUrl-ben benne volt a teljes eredeti hivatkozás és a Form authentication által hozzáfűzött paraméterlista is elérhető volt. Ennek ellenére a sikeres belépést követően mégis benne maradt az URL-ben a duplázott paraméterlista.

A user validálás után volt a másik hiba: az URL egyszerűen szét volt bontva a ReturnUrl mentén. Nem csak a ReturnUrl tartalmát adta vissza, hanem mindent, ami utána volt, így a duplázott paraméterlistát is.


--
A Form authenticationről bővebben:
http://blogs.msdn.com/b/vijaysk/archive/2008/01/24/anatomy-of-forms-authentication-return-url.aspx

2010. március 12., péntek

SSIS gyorstalpaló, tranzakció kezelés, MSDTC

Nemrég egy újabb olyan problémával találkoztam, aminek ha csak sejtem is a megoldását, egy nap bosszúságot megelőzök vele. Ezt szeretném most megosztani.

Amiről szó van, az a Microsoft SQL Server SSIS csomagja, és annak tranzakció kezelése. Mint ismert, az SSIS az őt megelőző DTS leváltására szolgál, teljesen más lett az egész. A 2005-ös SQL server óta beszélünk SSIS-ről, előtte volt a DTS.
Pár szóban röviden:
A Sokan használtak DTS-t, mert része volt az SQL Server programcsomagnak (ingyenes volt). De ha megnézzük, nem használták másra mint az SQL utasításokat futtattak egymás után. Minden transzformációt SQL-ben oldottak meg, és a DTS csupán egy valamiféle workflow engine volt. Az SSIS-ben már más a helyzet, real-time lehet adatokat transzormálni, ciklusokat kezel, eseményeket lehet felvenni, ellenőrző pontokat stb. Amivel fejleszteni kell, az meg nem más, mint a Visual Studio maga. Ez annyira nem triviális, mert úgy van, hogy ha van fent visual studio, akkor az sql server telepítése közben csak hozzáadja a megfelelő projekt típusokat, egyebeket, ha nincs fent visual studio, akkor pedig feltelepíti az egészet. És ugyan az SQL server 2005 alatt van a program filesban, és Business Intelligence Developement Studio néven fut, de lényegében ugyanaz. Fejlesztésről és áttekintésről itt olvashatunk.
Az egész cucc telepítése önmagában megér egy misét, főleg ha ha a gépen van már sqql server is meg visual studio is.
Ha már van fent sql server, akkor ezt az útmutatót kell követni, ha új sql server telepítünk, akkor ezt.

Megjegyzés: Az sql 2005-höz való SSIS csomagokat VS2005-el kell fejleszteni, sql 2008-hoz pedig VS2008-al. Legalábbis az msdn szerint, nekem egy VS2005-el gyártott csomagot sikerült importálni SQL2008-ra is, talán mert csak kompatibilis cuccok voltak benne.

Megjegyzés: 2008-hoz a telepítési útmutató:
Considerations for Installing Integration Services

SSIS tranzakció
Nah, de ami miatt ezt a bejegyzést írom, az a tranzakció kezelés. Alászaladtam, elolvastam néhány fórumot, hogy hogyan kell tranzakcióba tenni amit szeretnék, és nem működött. Elvileg nem nagy ördöngősség, kell egy connection (esetemben ADO .NET), létre kell hozni egy szekvencia konténert, és abba betenni amit tranzakcióban szeretnénk futtatni, majd beállítani a szekvencia TransactionOption property-jét Required-re. Ami belül van, azoknak meg ugyanezt a property-jét Supported-re, és kész is van, gondoltam én naív. Ám első futtatáskor ezt a hibaüzenetet kaptam:
[Execute SQL Task] Error: Failed to acquire connection "TestConnection". Connection may not be configured correctly or you may not have the right permissions on this connection.
Kis guglizás után rájöttem, hogy nem csak nekiesni kell mint tót az anyjának, ugyanis a BI környezet a tranzakció kezeléshez az MSDTC-t (Distributed Transaction Coordinator) használja.

MSDTC konfig
Engedélyezni, konfigurálni, futtatni kell, a "kliensen" is amin az SSIS fut (persze ez is egy sql server), és azon az SQL serveren is, amin végrehajtana valamit. Engedélyezni/futtatni pedig a service-eknél lehet, kell futnia a "Distributed Transaction Coordinator" nevű sevice-nek.

Ha ez megvan, akkor jön a java. Control Panel/Administrative Tools/Component Management ablakban nyissuk le a Component Services/Computers/My Computer/Distributed Transaction Coordinator elérési útvonalakat. Ekkor egy ilyen ablakot látunk.


Ezután ha a Local DTC ikonra jobb egérgombbal ha kiválasztjuk a Properties menüt, akkor megjelenik a konfig ablak.



Ha a képen látható beállítások megvannak, minden gépen amire az SSIS átnyúl, és amelyiken fut, akkor minden oké. Gondoltam én, megint.
De még mindig ugyanazt a hibaüzenetet kapom. Na, ekkor végigbogarásztam az MSDN-en az MSDTC toubleshooting-ot. Rájöttem, hogy mi a problémám. Az SQL szerver, mit el akartam érni az én local gépemről, domain-ban van. Az én local gépem meg nincs. Elméletileg ha a No Authentication Required van bepipálva, akkor szerintem működnie kellene, de nem megy, így hát gondoltam hogy megpróbálom valahogy úgy, hogy egyik gép sincs domainben. Virtuális gépen (laptopomon vmware gép) futott az SSIS, átnyúlt a host-ra (laptopom), és lám, így sem megy. Hiba ugyanaz. Na, akkor próba csak local gépen. Nem megy, hiba ugyanaz.
Ekkor ötlött fel bennem az, hogy mivan, hogyha az MSDTC miatt ez nem is működik SQL authentikációval? Gyorsan kipróbáltam, átállítottam NT-re, és minden rendben. Működik a tranzakció, rollback-el, commit-ol, szép és jó. Csak erről vajmi keveset írnak, hogy egy domain usert kell használni a connection-höz.


Eddigi nyomozásom eredménye tehát ez, még próbálkozom kideríteni az igazságot. Ha jutok még valamire, megoszom amint tudom. Nem valami szép megoldás, hogy domain user kell, és annak a domain usernek kell adni tárolt eljárás futtatás jogot, ha éppen azt akarok hívni az egyik step-ben, ami a szekvencia konténerben van.