11. januar 2005 - 22:56Der er
9 kommentarer og 1 løsning
Mest hensigtmæssige måde at bygge et login system op..
Hej folkens
Jeg har nu set lyset og er igang med at converterer fra classic ASP til ASP.net ( hvorfor har jeg dog ikke set lyset for nu? *dummeslag til mig*)
Nåh, men jeg sidder her og har læst et par bøger omkring ASP.net, og er nu gået igang med lidt ASP.net 2.0 ( hold kæft master pages er jo genialt), men der er nogle ting som jeg stadig ikke har helt fat i, da jeg nok stadig har den "gamle" måde at gøre tingene på i tankerne..
Login system:
I classic ASP ville jeg køre et database request som tjekker om min bruger nu eksisterer, derefter ville jeg oprette xx-antal sessions med mine forskellige brugeroplysninger og så er den skid slået, men i ASP.net ser det ud til at man skal gøre det på en lidt anderledes måde..
Sådan som jeg har forstået det, så benytter man mig af de indbyggede Authentication-funktioner og i dette tilfælde bliver det så Forms Authentication der skal benyttes. Umiddelbart ville jeg konfiguerer min web.config fil til kræve auth i et bestemt dir, som så redirecter til min login.aspx der så kører noget ligende:
If txtUser.Text = "test" Then FormsAuthentication.RedirectFromLoginPage(txtUser.Text, chkPersistLogin.Checked)........... end if Så er man logget ind, men jeg syntes der mangler de muligheder man havde i ASP.
- Hvordan gemmer man flere brugeroplysninger? Benytter man stadig sessions? Findes der en smartere måde?
- Hvordan laver man autologin? Efter hvad jeg kan se, man kan lave noget "PersistLogin", men hvad indebærer dette? og hvordan man kan få indflydelse i "slagets gang"?
- Hvordan kan man lave så sit indhold ændre sig efter om personen er logget ind eller ej?
Eks:
<% if not Session("Logged_in") = true then %> .... <% else %> .. <% end if %>
Håber I kan hjælpe mig, da der er nogle ting som I kan se jeg lige skal have slået på plads :-)
når du er logget ind med Forms Authentication kan du tjekke på User.Identity på Page-objectet.
Ang. at udvide dit user-object, kan det sagtens gøres så du ikke skal gemme alt muligt i forskellige sessions-keys, men kan gemme det hele i et enkelt User-object.
Ahh dejligt, så det kunne lade sig gøre, men hvad er fordelen ved at udvide user objectet? Er der stor forskel i hukommelses forbruget når man sammenligner brug af sessions og så en udvidelse af user-objectet?
Umiddelbart er sessions meget lettere at "bruge" med det samme, kræver mindre linier kode, men hva er ulempen ved sessions i forhold til user-objectet?
fordelene ved et userobject er at du får lavet din kode strongtyped. Intellisense kan direkte hjælpe dig når du skriver kode, og Compileren kan finde evt. stavefejl.
Ang. hukommelse er der selvfølgelig lidt mere overhead ved at oprette et object i hukommelsen, men tiden du sparer når du udvikler, og mindre risiko for fejl, vil jeg mene er vigtigere.
Men hvad er så konklusionen er det IPrincipal der bør nedarves fra til en custom made object? Så man ved login opretter et sådan og siger Page.User = MyOwnUser?
Jeg har selv nedarvet fra IPrincipal da jeg finder det nemmest. Og ja, i global.asax har jeg så denne kode:
protected void Application_AuthenticateRequest(Object sender, EventArgs e) { if (Context.User.Identity.IsAuthenticated) { if (!(Context.User is SitePrincipal)) { // ASP.NET's regular forms authentication picked up our cookie, but we // haven't replaced the default context user with our own. Let's do that // now. We know that the previous context.user.identity.name is the e-mail // address (because we forced it to be as such in the login.aspx page) SitePrincipal newUser = new SitePrincipal( Context.User.Identity.Name ); Context.User = newUser; } } }
Nevermind har fået det til at virker nu. Så jeg vil arbejde på at udvide IPrinciple, men hvordan nedarver du lige et interface ;o), det skal vel implementeres ;o)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
