ASP.Net MVC 3 C# CustomMemberShipProvidor

[KennethDC]

Even ter inleiding. Ik heb een website waar gebruikers zich op moeten kunnen registreren. De gegevens die nodig zijn wijken namelijk af van de default membership provisor dus het is normaal dat ik de custom membership provisor gebruik. Echter slaag ik daar niet helemaal in.

Zo heb ik de volgende dingen al gedaan:

-De providor aangepast in de Web.config
-CustomMembershipProvidor aangemaakt in Infrastructure die overerft van MembershipProvidor die op zijn beurt de userRepository bevat, een klasse die alle users via een DbSet bijhoudt van het type User, een zelf gemaakte klasse in het model.
-CustomMembershipUser aangemaakt in Infrastructure die overerft van MembershipUser

Maar nu zit ik wat vast. Ik zou helemaal niet weten wat ik verder moet doen om uiteindelijk een gebruiker zich te kunnen doen registreren met de volgende parameters (Naam, voornaam, telefoon, email (dit zal gebruikt worden om uiteindelijk zich ook aan te melden) en paswoord). En hoe spreek ik die MembershipProvidor ook aan in de view? Zo werkt @MembershipProvidor.MinRequiredPasswordLength niet om bijvoorbeeld te tonen hoeveel karakters er minimum vereist zijn.

[rickjehh]

Misschien moet je eerst zelf eens op zoek gaan m.b.v. de oh zo bekende zoekmachine? klik.

[KennethDC]

En dat had ik ook al gedaan. Enkel ben ik er vaak niet veel wijzer uit geraakt ook al heb ik enkele stukken en brokken er aan kunnen doen toevoegen. Het is dan ook nog niet lang dat ik hiermee bezig ben dus heel veel kennis heb ik er ook nog niet van.

[HansvDr]

Ik gebruik altijd de gewone standaard membership en maak 1 tabel extra waar ik naast de UserId alle extra gegevens in opsla.

Kun je het niet op die manier oplossen?

[KennethDC]

Maar dan is dat toch nutteloos want dan werk je met verschillende tabellen voor dezelfde informatie nee? Maar is het wel mogelijk via MembershipUser meer informatie door te sturen van de gebruiker? Want in geen enkel voorbeeld zie ik dat eigenlijk gebeuren.

[HansvDr]

Niet zozeer dezelfde informatie, enkel het UserId. Voor de rest sla ik in mijn extra tabel alleen de zaken op die membership niet heeft.

Ik vind het een makkelijke oplossing en heb het al heel vaak toegepast. Voel je vrij om het anders te doen..

[Haan]

1. het is een providEr
2. de code die je gebruikt, is volledig onafhankelijk van het type MembershipProvider dat je gebruikt, zolang dit een provider is die netjes de functies implementeert die een membership provider typisch nodig heeft (ValidateUser, ResetPassword, GetUser, e.d.)*.

Dit is allemaal standaard ASP.NET framework functionaliteit, dus staat verder los van het feit dat jij ASP.NET MVC gebruikt.


* Een custom MembershipProvider zelf goed bouwen is veel werk, zie bijvoorbeeld deze pagina voor een goed voorbeeld op MSDN.

[ Voor 19% gewijzigd door Haan op 11-04-2012 14:51 ]

[D-Raven]

Je zou eens naar user profiles moeten kijken. MSDN: Cutting Edge: Personalization and User Profiles in ASP.NET 2.0

[KennethDC]

Haan schreef op woensdag 11 april 2012 @ 14:49:
1. het is een providEr
2. de code die je gebruikt, is volledig onafhankelijk van het type MembershipProvider dat je gebruikt, zolang dit een provider is die netjes de functies implementeert die een membership provider typisch nodig heeft (ValidateUser, ResetPassword, GetUser, e.d.)*.

Dit is allemaal standaard ASP.NET framework functionaliteit, dus staat verder los van het feit dat jij ASP.NET MVC gebruikt.


* Een custom MembershipProvider zelf goed bouwen is veel werk, zie bijvoorbeeld deze pagina voor een goed voorbeeld op MSDN.

Gelukkig heb ik het in mijn project wel juist getypt. Maar het probleem waar ik voornamelijk mee zit is dat ik mijn zelf gemaakte CreateUser met mijn eigen parameters niet kan aanspreken via Membership in mijn AccountController. Daar zit ik dus wat mee vast. Al de overige dingen zouden normaliter correct moeten werken.

[Haan]

Je moet je houden aan de parameters van CreateUser, daar kan je niet opeens andere velden aan toevoegen, of je moet het hele standaard Membership van ASP.NET niet gebruiken en alles zelf doen. Maar dat wil je niet en is ook niet nodig.
In jouw geval is het gebruik van Profiles zoals Deathraven aangeeft waarschijnlijk wel een goede optie, of je moet een deel van de velden in de MembershipUser opslaan en de rest handmatig in een andere tabel (eigenlijk wat HansvDr al zei)

[Grijze Vos]

Je wilt helemaal niks wijzigen aan Membership, je wilt de Profile provider veranderen. (Of de gewone profile provider gebruiken, maar die is imho ruk.)

[ Voor 27% gewijzigd door Grijze Vos op 12-04-2012 08:41 ]

[D-Raven]

Grijze Vos schreef op donderdag 12 april 2012 @ 08:41:
Je wilt helemaal niks wijzigen aan Membership, je wilt de Profile provider veranderen. (Of de gewone profile provider gebruiken, maar die is imho ruk.)

Seconded.

Wat ik eigenlijk altijd doe is zelf met een aparte tabel met UserProperties werken. Maar dan moet ik zeggen dat ik nog niet met een systeem heb gewerkt waarbij het mogelijk moest zijn om dynamisch properties aan gebruikers toe te voegen. (wat dan natuurlijk meestal veel verder gaat dan alleen extra gegevens opslaan)