Zarządzanie użytkownikami (członkostwo)

0

Witam.
Na wstępie powiem że nie mam zbyt wiele doświadczenia w programowaniu ASP.NET /C#.
Posiadam pewien problem.
Chciałem stworzyć aplikacje webowa, której główną funkcja będzie zarządzanie użytkownikami. Do ich zarządzania chciałbym zastosować członkostwo i zarządzanie rolami. Problem w tym że nie do końca rozumiem/wiem czy stosując to uda mi sie dość do celu.
Od razu piszę ze nie pytam Was o jakiś gotowy kod, tylko o nakierowanie mnie co mam robić w danej sytuacji:
Problem w zastosowaniu członkostwa i ról widzę taki że generują sobie oni swoje własne tabele, z własną zawartością i relacjami, które nie do końca mi odpowiadają (przynajmniej tak myślę). Potrzebuję np dodatkowej tabeli i relacji z utworzonymi w członkostwie użytkownikami (aby każdego dodanego użytkownika administrator mógł przypisać do odpowiednich projektów, które opisane będą w tej tabeli).
Czy da się jakoś dostosować/dodać do wygenerowanych tabel bazy danych (członkostwa) nowe tabele i utworzyć po między nimi relacje ? (wątpię, ale zapytać nie zaszkodzi ;) )

Zastanawiam się nad 2 możliwościami wyjścia:

  1. Napisanie własnego niestandardowego modelu dostawcy SqlMembershipProvider, do własnej bazy danych <- nie mam pojęcia jak to praktycznie zrobić, wiem tylko że musze zaimplementować funkcje zdefiniowane w interfejsie dostępu do klasy bazowej MembershipProvider. (będę wdzięczny gdyby ktoś mógł mi to na przykładzie jakimś opisać)
    Lub.
  2. Nie stosować członkostwa i zarządzania rolami. Stworzyć własną bazę z odpowiednimi relacjami, opakowanie wszystkiego w klasy, użycie ADO.NET. Ale myślę ze jest to wymyślanie koła od początku.

Co mi poradzicie w takiej sytuacji ?
Bardzo dziękuję za wszelką pomoc

0

Napisanie własnych MembershipProvider, UserProvider, RoleProvider, które dziedziczą po abstrakcyjnych klasach o tych nazwach miało by sens, jeżeli używałbyś rzeczywiście jako takiego logowania tych użytkowników. Wtedy, ożywając gotowych kontrolek z ASP.NET, kontrolki te bardzo ładnie współpracują z powyższymi klasami.

Abstrakcyjna MembershipProvider ma jednak swoje wady. Między innymi z góry narzucona struktura funkcji, (jak na przykład głupie przypominanie hasła). Co prawda da się ją łatwo dostosować do swoich potrzeb, implementując swoją klasę, jednak struktura zostaje i może zniechęcić.

Więc, jeśli Ci użytkownicy nie będą logowani na stronie, a twoim celem jest jedynie zbierać o nich dane - nie potrzebujesz klas Membership.

0

oczywiście użytkownicy będą logować na stronie, będą tam mieli jak by swoje "biurka" . Hmm np. do zadań administratorów systemu należeć będzie tworzenie nowych userów, przydzielanie im ról oraz zadań do wykonania z których w danym terminie będą musieli się wywiązać.
Więc sądzisz ze własny dostawca byłby tu dobrym rozwiązaniem ? Mógłbyś mi może podpowiedzieć gdzie znajdę jakieś info na temat tworzenia takich dostawców, lub dać jakiś przykład ?
(Wiem że to dużo kodu nie zdziwię się gdy odmówisz )
Dzięki za każdą pomoc

0

Mam do Ciebie jeszcze kilka pytań. Czy jeśli napisał bym własną SqlMembershipProvider, musiał bym również napisać własne zarządzanie rolami, czy mógłbym skorzystać już z istniejącego (bo jak najbardziej mi odpowiada). Myślę ze tak, ale wolę zapytać.
Poza tym wpadłem na pomysł aby podejrzeć jak jest zbudowany SqlMembershipProvider i na jego podstawie zrobić własnego dostawcę... Mógłbym prosić o lokalizacje tego pliku, bo nie mogę go znaleźć :-/

0

Działa. Wszystko jest świetnie opisane w dokumentacji MSDN.
Jeśli kogoś interesuje ta sprawa oto link: http://msdn.microsoft.com/en-us/library/ms366730(VS.80).aspx

1 użytkowników online, w tym zalogowanych: 0, gości: 1