Två problem.

1. Du skapar en property på din usercontroll som heter katID och är av typen Int.

2. Har aldrig testat, men om du vill kunna det, så måste du kunna serializera det, eftersom forms auth använder sig av cookies. Tror nog att det skulle bli lite jobbigt. Varför inte bara lägga objektet i cachen med det cookiesID som används till forms auth.

- M

Angående 2:

Hur skulle den lösningen se ut?
Jag har ett objekt som heter userData med propertyn userID(int) och userGroupID(int[]).
Hur skulle ni lösa det med forms auth?

Om man skall lagra mer information i Forms Authentication än vad som är inbyggt så måste man bygga nya klasser som ärver FA-klasserna. Man skriver en klass som ärver System.Security.Principal.IIdentity som bygger ut den inbyggda funktionaliteten och innehåller userID, userGroup och annan userinfo man vill ha med i FA.
Men det är inga enkla grejor för detta måste du kunna Objekt-Orienterad programmering och så måste du förstå vad Forms Authentication verkligen gör och vilka klasser som används.

Alternativet med cache är helt enkelt att du skapar ditt objekt, lägger in det i cachen och på så sätt kan hämta det från alla sidor i sajten.
Om du inte vet hur man använder cachen rekommenderar jag att du går igenom exemplen om cache på http://asp.net/Tutorials/quickstart.aspx

Vilket alternativ är bäst?

Känns som om cache är snabbare om man vill ha ut användar information.

Är rätt så insatt i oop. Så efter en del klurande och lite så ska jag nog kunna fixa det alternativet.

Men frågan är vad som är bäst?

Man måste se till den applikation man bygger.
Cache är snabbare men om du har en stor sajt med tusentals användare så kan det bli mycket i cachen.
Det är en avvägning man får göra helt enkelt.

Då är nog Forms Authentication versionen bättre.

Om du har tid och ork så får du gärna förklara mer ingående hur det går till.

Sorry, det är en rätt stor grej. Du får sätta dig in i Forms Authentication, IPrincipal och IIdentity.

Men jag kan rekommendera boken "ASP.NET Website Programming Problem - Design - Solution" av Marco Bellinaso och Kevin Hoffman. Där har du en färdig lösning.

Om man ändå hande pengarna att köpa boken :)

Tack för hjälpen. Får sätta in mig i det så gott jag kan.

Men tack för hjälpen.

Du kan alltid ladda ner koden till boken från Wrox.
http://www.wrox.com/dynamic/books/download.aspx#0764543776
Vet inte om du får ut så mycket av det utan boken men ändå.

Och som jag sa, kolla MSDN. Det är faktiskt bästa referensen när det gäller .NET.

Tack för tipsen.

Håller på att läsa på MSDN.

Kan också rekommendera ovanstående bok, tycker det är lättare att förstå hur saker och ting hänger ihop när det redovisas med konkreta exempel.

Renholm, en fråga angående den boken.
Har du kört exemplen?
I PhilePage klassen, som används som Base till alla sidor så ligger det en test för att se att den inloggade användaren är satt till en customiserad principal.

If Context.User.Identity.IsAuthenticated Then
  If Not (TypeOf Context.User Is SitePrincipal) Then
    Dim newUser As New SitePrincipal(Context.User.Identity.Name)
    Context.User = newUser
  End If
End If

Den körs jämt. Jag la in en response.write("Ny user") innanför if-satsen och den skrivs alltid ut. Det borde den inte göra om Context.User redan är en SitePrincipal, eller hur?

Jag har kollat i Wrox forum och det är många som frågar men ingen som får riktiga svar.
Jag har löst det genom att ändra ovanstående till:

If Context.User.Identity.IsAuthenticated Then
  If Not (TypeOf Context.User Is SitePrincipal) Then
    If Session("UserPrincipal") Is Nothing Then
      Dim newUser As New SitePrincipal(Context.User.Identity.Name)
      Context.User = newUser
      Session("UserPrincipal") = newUser
    Else
      Context.User = Session("UserPrincipal")
    End If
  End If
End If

Då hämtar man inte data i databasen varenda gång.

Har aldrig testkört exakt den kod som fanns i boken utan byggde ett eget system med HttpModules. Vad jag har förståt måste Context.User sättas för varje Request då den inte är kvar mellan de olika requesten.

Ja, Context.User ligger aldrig kvar som en modifierad principal mellan de olika requesten. Lägga SitePrincipal i en Session funkar ju så man slipper gå till databasen varje gång i alla fall och om man behöver ett komplett UserObject så kan man skapa ett nytt med SitePrincipal från sessionen. Blir visserligen ett DB-anrop då men varje sida behöver ju inte all Userinfo utan endast det som är i SitePrincipal.
Nåja, vi får väl se var man hamnar sen, ändrar ju alltid något i varje iteration.

Beställde boken i (C#) version. Har VB versionen på hårddisken. Känns som om jag vill ha mer konkreta exempel.