[ASP.NET] Webformulieren met inlogfunctie

[Haan]

Er is mij gevraagd een inschrijfformulier op te leveren, waarbij de gebruiker optioneel in kan loggen. Als de gebruiker inlogt, moeten NAW gegevens uit een CRM systeem worden opgehaald en alvast worden ingevuld. Als je niet wenst in te loggen, moet je dat dus zelf nog doen.

Laten we eerst even voorop stellen dat ik nog nooit een webform heb gebouwd met inlog functionaliteit..
Ik weet dat er allerlei standaard controls in ASP.NET zitten voor authenticatie, die volgens mij wel goed kunnen werken. Maar de standaard ASP.NET controls stoppen de accountgegevens in een eigen database, is dat op een eenvoudige manier te verplaatsen naar een CRM systeem? En hoe zou dat dan werken met het ophalen van de NAW gegevens? Als een gebruiker inlogt, is dan ergens de gebruikersnaam uit te lezen waarmee ik die gegevens verder ophaal?

Nu wordt mij ook nog van 'hogerhand' opgedrongen om hiervoor een Microsoft Live ID te gebruiken als authenticatieprovider. Ik (en anderen) met mij hebben hier echter geen goed gevoel bij, want je kan je voorstellen dat lang niet iedereen erg enthousiast wordt om met een Live ID in te moeten loggen. Maar misschien zitten hier nog voordelen aan die ik misschien over het hoofd zie? Het neemt natuurlijk wel het account beheer uit handen, maar van wat ik er zo snel van heb gezien na wat aanmodderen, is het niet zo heel simpel aan te praat te krijgen.

Kortom, veel vragen.. Hopelijk kunnen jullie me een beetje verder op weg helpen

[Woy]

Je kunt gewoon diverse eigen providers maken, en die d.m.v. configuratie gebruiken.

MSDN: MembershipProvider Class (System.Web.Security)

[keesdewit]

Je kunt je applicatie ook "claims aware" maken en binnen de applicatie eigen database gebruikers gebruiken.

http://msdn.microsoft.com/en-us/security/aa570351

[Haan]

Om hier even een schop tegen te geven, ik heb nu gewoon de standaard ASP.NET controls gebruikt, met de SQL Express database (default configuratie). Daar heb ik aan toegevoegd dat bij het registreren van een nieuw account een call naar het CRM systeem gaat om te checken of de gebruiker al bestaat, en daarna een call om de nieuwe user ook daar aan te maken.
Nu wordt het even verder puzzelen om wat extra velden (voornaam, achternaam e.d.) bij het registreren in te kunnen vullen, en bij het inloggen de gegevens weer uit te lezen. Maar dat gaat volgens mij wel lukken. Ik zat vanmorgen te kijken naar ProfileProviders, maar volgens mij is dat niet persé nodig (nogal een bult werk om een custom provider te schrijven..)

[Grijze Vos]

Een custom provider schrijven is echt heel veel werk, dat kan ik beamen. (En Ragnax ook, die heeft hem hier op het werk namelijk geschreven.)

[R4gnax]

Grijze Vos schreef op maandag 07 maart 2011 @ 14:30:
Een custom provider schrijven is echt heel veel werk, dat kan ik beamen. (En Ragnax ook, die heeft hem hier op het werk namelijk geschreven.)

Amen. Membership en role providers zijn niet de meest prettige code om te kloppen. Zeker niet als je rechten management ook op artifact niveau wilt beheren, zoals inderdaad destijds geïmplementeerd. Het is ook typisch een stuk code waarvoor je goede unit test coverage wilt hebben, want fouten kruipen er vrij snel in.

[Haan]

Mijn code werkt nu opzich prima, na inloggen kan ik netjes een aantal velden vullen met data die uit het CRM systeem komt Ik zit alleen nog met het volgende:
Ik heb een masterpage met daarop de login controls en webforms die in twee mappen staan en van de masterpage gebruik maken. Dus ik heb, laten we zeggen, twee webforms: "mysite/folder1/form.aspx" en "mysite/folder2/form.aspx".
Als je nu op de login link klinkt vanaf een form, wordt je netjes doorgestuurd naar het login form, maar deze redirect niet meer terug naar de pagina waar je vandaan kwam. En ik heb me scheel gezocht, maar kan niet vinden hoe je in kan stellen dat je terug wordt geredirect naar de pagina waar je vandaan kwam.
Hoe zou ik dat aan moeten pakken?

edit:
hetzelfde geldt overigens voor mijn pagina voor aanmaken nieuw account (mbv CreateUserWizard)

[ Voor 6% gewijzigd door Haan op 09-03-2011 14:39 ]

[Cloud]

Als je naar de Login.aspx pagina (of hoe die ook heet) redirect, meteen de ReturnUrl parameter zetten:

code:

~/Login.aspx?ReturnUrl=/mysite/folder2/form.aspx

In de Login.aspx.cs staat dan na de succesvolle authenticatie nog een:

C#:

FormsAuthentication.RedirectFromLoginPage(..., ...);

Althans zo werkt het bij ons, maar wij gebruiken niet de gehele Membership-shizzle van Microsoft. Dus misschien kan het nog eenvoudiger. Het meegeven van die ReturnUrl parameter gaat bij ons trouwens automatisch als je een pagina opvraagt waarvoor je ingelogd moet zijn.

[Haan]

Maar het probleem is dus dat die returnUrl afhankelijk is van het formulier vanaf waar je gaat inloggen.

[Cloud]

Misschien begrijp ik je verkeerd, maar die locatie kun je toch gewoon opvragen?

C#:

// Stel de volledige URL is: "http://www.jouwsite.nl/mysite/folder2/form.aspx"
string localpath = Request.Url.LocalPath;

// localpath geeft dan: "/mysite/folder2/form.aspx"

Dan is het alleen nog een kwestie van die link naar Login.aspx goed opbouwen.

[Haan]

OK, maar dan moet ik vanuit de desbetreffende pagina de login control die op de Master page staat bijwerken? (ik heb voor het grootste deel gewoon de standaard template die bij VS2010 zit overgenomen, dus misschien dat er ook handigere manieren zijn voor wat ik wil)

[ Voor 42% gewijzigd door Haan op 09-03-2011 15:41 ]

[Cloud]

Nee in principe hoeft dat niet. Op het moment dat ASP.NET de Request afhandelt zijn de betrokken Master en Content pages eigenlijk één geheel geworden. De bovenstaande code zou je dus ook prima op de Master page uit kunnen voeren, omdat daar je Login controls ook staan. Zo hoef je verder niet aan de Content pagina's te komen.

[Haan]

Ik word er een beetje moe van.. Op de Master page staat dus een LoginView, met een AnonymousTemplate en LoggedInTemplate. Het stomme is dat controls die in die templates staan, niet bekend zijn in de code-behind van de pagina Dus had ik het opgelost met een FindControl(), dat werkte 1 keer, en nu blijft dat ook steeds null
Maar die eerste keer dat het werkte, gebeurde er nog steeds helemaal niets na het inloggen. Dus ik wou een Response.Redirect(Request.QueryString["ReturnUrl"]) proberen, maar dat kan ik nu dus niet meer testen

[update]
Uiteindelijk de oorzaak en oplossing gevonden: http://forums.asp.net/p/1552199/3808482.aspx

De LoginView rendert alleen de anonymous template of de loggedin template. Als je dus al bent ingelogd is de anonymous template niet beschikbaar. Dus nu heb ik eerst een check of Membership.GetUser() null is, dan zet ik de ReturnUrl voor de login pagina en dat werkt (met de Response.Redirect).

Nu nog uitvissen hoe je de boel gedeployed krijgt zonde SQL exceptions te krijgen bij het raadplegen van de authenticatie database

[ Voor 33% gewijzigd door Haan op 09-03-2011 17:11 . Reden: oplossing gevonden ]

[Haan]

Nog even een kickje

Opzich werkt alles nu wel, er komt alleen het volgende punt als feedback van de testers: als je eerst het formulier invult en daarna een account aan gaat maken, is daarna het formulier leeg.
Dat is opzich logisch, want je wordt eerst geredirect naar de login pagina. Als je nog geen account had kan je daar doorklikken naar de registratiepagina en als je door het proces bent gelopen wordt je weer geredirect naar de NAW pagina. Als je wel al een account had, kan je meteen inloggen, maar is ook de data de je eventueel al had ingevuld verdwenen.

De enige oplossing hiervoor die ik hiervoor zelf kan verzinnen is om alle velden die bewaard moeten blijven in de Session te stoppen, maar dat is wel wat omslachtig. Zijn er nog andere / betere alternatieven?

edit;
Ik zie nu dat ook bij een refresh de waarde van een TextBox al meteen verdwijnt Ik kan in ieder geval geen event vinden waar ik op in kan grijpen waarbij die waarde er nog is.. (OnLoad, OnUnLoad, OnPreRender, OnPreInit etc.)

Waardes opslaan bij klikken op de login link is ook geen optie, want de Login control zit in een masterpage, dus die heeft geen idee welke velden er opslagen zouden moeten worden.

[ Voor 21% gewijzigd door Haan op 11-04-2011 08:54 ]

[gorgi_19]

Je kan ook je registratiepagina buiten je authenticatie houden (zodat deze altijd beschikbaar is) en serverside gaan bekijken of je moet redirecten of niet.

[Haan]

Die snap ik niet helemaal geloof ik. De registratiepagina staat natuurlijk buiten de authenticatie (het is immers nogal onhandig als je in zou moeten loggen om een nieuw account aan te maken ;-) ).

Maar links- of rechtsom komt er een moment dat je in gaat loggen, waarbij velden die je eventueel al in had gevuld, leeg worden gemaakt (wat dus sowieso al bij iedere refresh van de pagina gebeurt). Wat volgens mij wel gaat werken (maar wat een k* klus gaat worden) is voor iedere invoer control (textboxes, dropdowns e.d.) het onchange event af te vangen en dan de waarde in de Session stoppen..