Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Integracja systemów, czyli przechowywanie danych userów
DeyV
post
Post #1





Grupa: Zarząd
Postów: 2 277
Pomógł: 6
Dołączył: 27.12.2002
Skąd: Wołów/Wrocław




W końcu doszło do tego, że nie mogę już dużej odwlekać zabrania się za tą pracę, a że nie mam pomysłu na to, jak zrobić to "dobrze", stąd chciałbym usłyszeć Wasze opinie.

Zadanie polega na integracji bazy użytkowników w kilku zupełnie różnych systemach.
Jest to forum, wiki, eZ i jeszcze chyba mantis. (nie trudno się domyślać, na czyje potrzeby (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) )
Problem wydawałoby sie - banalny - w końcu chodzi tylko o to, by można się było raz zalogować, i być zalogowanym od razu we wszystkich tych systemach (działających na różnych subdomenach) oraz by wszędzie działały te same hasła i loginy.

Niestety - mimo że każdy z tych systemów jest napisany obiektowo - i każdy ma jakąś klasę typu User, zajmującą się tego typu zadaniami - to jednak sposób przechowywania tych informacji, a także ich obsługa - jest mocno zróżnicowana.
Dodatkowo - każdy z tych systemów przechowuje różne specyficzne dla siebie, ustawienia profilu.
Dodatkowo - jak już wcześniej zauważyłem - każdy z nich działą w innych subdomenach, co może (choć chyba nie musi) nieco utrudniać przenoszenie się identyfikatora sesji.

Jak można to rozwiązać?
1. przygotować osobny mechanizm, któy będzie zawierał wszystkie dane użytkownika, w którym użytkownik będzie się logował, przypominal sobie hasła, konfigurował wszystkie ustawienia itp.
Teraz jednak ciąg dalszy może wyglądać tak:
a ) nasz mechanizm podczas tworzenia nowego użytkownika tworzy odpowiednie konta we wszystkich systemach do niego podpiętych, podczas aktualizacji danych - aktualizuje je również w odpowiednich działach.
Natomiast poszczególne systemy mają albo wyłączone panele konfiguracyjne, albo panele, które podczas zapisywania niektórych danych - zapisują je również w naszym mechaniźmie.
- zamiast automatycznego tworzenia wszystkich profili, użytkownik, podczas pierwszego wejścia na np. forum może zostać poproszony o uzupełnienie niezbędnych danych.

b ) centralny mechanizm staje się jedynym miejscem przechowywania danych użytkownika, wszystkie pozostałe systemy mają całkowicie wyłączoną możliwość przechowywania i edycji tych ustawień. Przez cały czas muszą więc odwoływać się do centrali. W przypadku niektórych z nich - np. forum, wymagałoby to chyba bardzo dużych zmian.

2. rozbudować największy z istniejących mechanizmów - najprawdopodobniej forum, tak by pozwalało na konfiguracę również innych programów.
poziom trudności - spory.
Co więcej - traci się intuicyjność, bo skąd użytkownik ma wiedzieć, że aby zmienić ilość tematów wyświetlanych na wiki, musi wejść na forum?
Utrudnia to również logowanie do poszczególnych systemów, bo zawsze należy zaczynać od forum.

Czy są jeszcze jakieś inne rozwiązania?
Najlepiej takie, ktore by maksymalnie obniżyły konieczność ingerencji w poszczególne systemy (bo to, jak wiadomo - znacznie obniża możliwości ich aktualizacji...)
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi
hawk
post
Post #2





Grupa: Zarejestrowani
Postów: 521
Pomógł: 0
Dołączył: 3.11.2003
Skąd: 3city

Ostrzeżenie: (0%)
-----


Hmm, łatwo mogę powiedzieć, jak to powinno wyglądać w idealnym świecie, w którym autorzy forum, wiki, itd. myślą chociaż trochę o reuse...

Ustawienia użytkownika to jedno, uwierzytelnianie to drugie. Każdy system ma swoje ustawienia, i to jest jego wewnętrzna sprawa. Załóżmy że w każdym systemie jest klasa User. Generalnie odpowiedzialna będzie ona za 2 rzeczy:
- sprawdzenie, kim jest użytkownik
- wyciągnięcie jego indywidualnych ustawień
Chodzi o to, żeby rozdzielić te 2 rzeczy, a następnie podmienić pierwszy krok. W idealnym systemie nie byłoby problemu, bo baza danych nie byłaby "wbudowana" w klasę User.

Jeżeli jedno z drugim jest zrośnięte, to... źle. Można spróbować napisać coś dziedziczącego z klasy User, z przeciążoną metodą odpowiedzialną za uwierzytelnianie (jeżeli taka metoda w ogóle jest). Niestety, nową klasę User bardzo trudno jest wepchnąć do systemu w miejsce starej, bo mało kto słyszał o Dependency Injection (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) .

Nawet gdyby się udało, pozostaje problem zmiany hasła w profilu i konieczności podmiany kodu w tym miejscu.
----------------------
Przyszło mi też do głowy coś innego. A gdyby tak replikować (np. w cronie, raz na dobę) użytkowników na wszystkie, niezależne bazy? Przyjmując domyślne ustawienia takie, jakie tworzą się przy zakładaniu konta. W razie potrzeby można też zreplikować powtarzające się dane, w zależności od konkretnej bazy. Trochę chałupnicza metoda, ale...
Zamiast crona można też użyć np. triggerów w bazie danych - wtedy mamy real-time zamiast raz na dobę. Ale triggery działające na różnych bazach mogą przekraczać możliwości zastosowanego DBMS. No chyba że mamy Oracle - definiujemy łącze między bazami i po kłopocie (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .
---------------------
Co do cookie - można teoretycznie wysłać cookie z wpisanym php.pl zamiast forum.php.pl i powinno się wysyłać wszędzie. Tyle mówi teoria.
Go to the top of the page
+Quote Post

Posty w temacie


Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 4.10.2025 - 20:43