Identyfikacja użytkowników w aplikacjach sieciowych |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
Identyfikacja użytkowników w aplikacjach sieciowych |
14.10.2011, 15:09:04
Post
#1
|
|
Grupa: Moderatorzy Postów: 36 519 Pomógł: 6308 Dołączył: 27.12.2004 |
Na wniosek nasty, który mam nadzieję rozwinie ten wątek
-------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
14.10.2011, 17:03:05
Post
#2
|
|
Grupa: Zarejestrowani Postów: 634 Pomógł: 14 Dołączył: 27.05.2006 Skąd: Berlin Ostrzeżenie: (0%) |
To może najpierw zaczniemy od małej sądy?
1. W jaki sposób identyfikujecie użytkoniwków swoich aplikacji? 2. Jeśli macie już istniejącąbazę użytkowników (np. intranet czy partnerska organizacja) to jak importujecie lub dajecie tym użytkownikom dostęp do Waszej aplikacji? 3. Gdzie i jakie dane o użytkownikach przechowujecie i w jaki sposób? 4. Jak udostępniacie swoich użytkoników partnerskim organizacjom? Zapraszam do dyskusji - dzięki nospor! |
|
|
26.11.2011, 22:09:23
Post
#3
|
|
Grupa: Zarejestrowani Postów: 190 Pomógł: 2 Dołączył: 30.11.2009 Ostrzeżenie: (10%) |
@nasty
1. Prosty system sesji oparty albo o sesje php'owe [w celu przechowywania stałego SID'a lub 'sid' w ciasteczkach], dane o sesjach przechowuję w bazie danych i potem pobieram po id sesji 2. Prosty ACL, chociaż nawet prostym nie można tego nazwać, w tabeli users jest kolumna group_id i każdy może mieć przypisaną jedną grupę [można łatwo rozwinąć aby było kilka ale trzeba się pobawić potem z uprawnieniami kilku grup dla jednego użytkownika], w tabeli groups_acl sa kolumny acl_group, acl_can_view_cos, acl_can_cos_tam, pobieram te dane i robią kesz co by nie trzeba było bazy obciążać kolejnym bzdetem [$acl = array( grupa => array( ACL ) ) i potem w łatwy i zdaje mi się, że szybki sposób można pobrać info o uprawnieniach 3. Baza danych, session_id, session_start, session_last, session_location, session_user -> pierwsza i ostatnia kolumna najważniejsza [po nazwach można się domyślić do czego służą ;p] 4. --- ja to robię w taki sposób [mniej więcej], jak na razie nie napotkałem żadnych problemów ale na pewno są lepsze rozwiązania. |
|
|
3.01.2012, 01:06:48
Post
#4
|
|
Grupa: Zarejestrowani Postów: 64 Pomógł: 0 Dołączył: 3.02.2009 Ostrzeżenie: (0%) |
A może lepiej byłoby trzymać sesję client-side? Wiem że wydaje się to głupie, ale gdyby użyć algorytmu który by szyfrował sesję, taką sesję trzymał po stronie usera,a po połączeniu deszyfrował - miało by to sens?
Tym bardziej, że kusi praktycznie usunięcie problemu ,,sticky sessions" , jak mamy np. parę równoległych maszyn. Pozdrawiam |
|
|
5.01.2012, 08:06:48
Post
#5
|
|
Grupa: Zarejestrowani Postów: 634 Pomógł: 14 Dołączył: 27.05.2006 Skąd: Berlin Ostrzeżenie: (0%) |
A Zastanawialiście się kiedyś o tym, żeby wyeliminować kwestię autentykacji użytkowników w Waszych aplikacjach i wydelegowania tego procesu innym instytucjom? Mowa to o Claims-Based Identity.
|
|
|
26.05.2012, 10:36:32
Post
#6
|
|
Grupa: Zarejestrowani Postów: 1 568 Pomógł: 192 Dołączył: 7.03.2005 Skąd: Warszawa Ostrzeżenie: (0%) |
Identyfikacja użytkownika za pomocą driver-a LDAP. Niestety nie mam środowiska testowego, żeby przetestować na IIS 7.5 możliwość zrobienia logowania poprzez KERBEROS-a.
-------------------- |
|
|
30.06.2013, 20:56:40
Post
#7
|
|
Grupa: Zarejestrowani Postów: 160 Pomógł: 6 Dołączył: 13.01.2012 Skąd: Bytom Ostrzeżenie: (0%) |
Co lepsze:
tabela sessions sid, session_timeout, session_data (zserializowana tablica) następnie klasa Sessions pobiera sesję z bazy po sid, sprawdza session_timeout, następnie z session_data wyciąga user_id do którego należy sesja, pobiera użytkownika i zapisuje wiersz w tablicy ew. tworzy obiekt User lub takie coś sid, session_timeout, session_user, session_data to samo co wyżej, z tym, że sesja pobiera po sid i dołącza użytkownika z bazy w jednym zapytaniu (LEFT JOIN)? -------------------- |
|
|
2.07.2013, 08:14:59
Post
#8
|
|
Grupa: Zarejestrowani Postów: 559 Pomógł: 93 Dołączył: 4.03.2008 Skąd: Olsztyn Ostrzeżenie: (0%) |
1. System na sesjach, ustalony czas trwania sesji i wylogowanie po tym czasie lub przedłużenie sesji.
2. Rozbudowany ACL gdzie user ma prawa podstawowe zależne od roli (admin, moderator itp) następnie od grupy(może być kilka) i ostatecznie od uprawnień dla danego usera(mają one pierwszeństwo ponad prawami roli i grupy) 3. Tabela w bazie zawiera osobno informacje o acl, osobno o użytkowniku i osobno o jego profilu, w momencie zalogowania dane usera są łączone z jego profilem. 4. --- -------------------- |
|
|
11.07.2013, 20:23:36
Post
#9
|
|
Grupa: Zarejestrowani Postów: 472 Pomógł: 7 Dołączył: 7.12.2005 Skąd: Gliwice Ostrzeżenie: (0%) |
Nie będę tutaj powielał najczęstszych odpowiedzi, którymi zapewne mogą być sesja + ciastko + user w bazie, więc opiszę jak to robię przy okazji połączeń z serwisami poprzez API.
1. OAuth2 w których do tokena dostępowego zabindowany jest User. 2. Podpięcie aktualnej bazy użytkowników to kwestia dodania kolejnego klienta uwierzytelniającego dane z zewnętrznego. Jeśli istnieje zewnętrzna baza użytkowników z możliwością autoryzacji - istnieje sam system autoryzacji dostępu. Najprostszym zatem jest - autoryzacja użytkownika w swoim "naturalnym" środowisku, a następnie przyznanie mu dostępu do naszego serwisu. 3. Baza danych, niepotrzebne są jakiekolwiek pola z saltem, hashem hasła (bo takowe nie istnieje) etc. 4. Nawet pomiędzy większymi elementami wewnątrz jednego projektu - 3 stopniowa autoryzacja, którą zapewnia OAuth. Ogromnym plusem jest tutaj łatwość wpięcia autoryzacji typu stateless (zero ciastek) do już istniejącej bazy użytkowników, i w drugą stronę - dopięcia standardowego logowania do istniejącego systemu. -------------------- Silesian PHP User Group - www.spug.pl
Symfony2, OAuth2, budowanie API - masz pytania? Pisz! |
|
|
26.06.2014, 16:44:11
Post
#10
|
|
Grupa: Zarejestrowani Postów: 160 Pomógł: 6 Dołączył: 13.01.2012 Skąd: Bytom Ostrzeżenie: (0%) |
Jaki jest aktualny trend w sesjach? Jakaś klasa opakowywująca sesje PHPowe w settery i gettery + jakieś dodatki, czy może handler zapisywania sesji do bazy a może kompletny, w 100% własny sposób na sesje, gdzie w ciasteczku sami zapisujecie SID i potem pobieracie sesję z bazy, jak rozwiązują to frameworki, jak jest najlepiej to rozwiązać?
-------------------- |
|
|
28.06.2014, 22:32:09
Post
#11
|
|
Grupa: Zarejestrowani Postów: 532 Pomógł: 24 Dołączył: 15.04.2011 Skąd: Kalisz Ostrzeżenie: (0%) |
Z tego co wiem, to nowe Symfony używa sesji PHPowej, ale opakowanej ładnie w klasę. Próbowałem napisać własny mechanizm sesji, ale jest to "droga przez mękę" i nikomu tego nie polecam. Nie warto wymyślać koła na nowo, skoro jest ono już wymyślone (de facto ja zacząłem tak robić, ale poszedłem po rozum do głowy). Chodzi mi o natywną sesję PHP. Oczywiście, trzeba ją troszkę dostosować, poprawić, zabezpieczyć, ale jak już się to zrobi to nie ma nic lepszego.
W aplikacji firmowej używamy sesji PHP, ale opakowanej ładnie w klasę, a dodatkowo dane trzymamy w bazie danych. Są to jednak zawsze dwa zapytania więcej do DB, ale można dzięki temu zapisywać i pobierać statystyki na temat aktywnych użytkowników itp. Ważne jest by zabezpieczyć domyślną sesję PHP przed atakami, a reszta to już inwencja własna |
|
|
15.07.2014, 13:26:25
Post
#12
|
|
Grupa: Zarejestrowani Postów: 99 Pomógł: 22 Dołączył: 14.12.2007 Skąd: Wyszków Ostrzeżenie: (0%) |
W swoich aplikacjach korporacyjnych robię autoryzację po Kerberosie w domenie ActiveDirectory (wcześniej apache2 i IIS, teraz nginx). Sama aplikacja PHPowa, napisana w SF2 - gdzie napisałem własną paczkę do obsługi autoryzacji via Kerberos, zarządza tylko poszczególnymi uprawnieniami dla nazw użytkowników. Wynika to z tego, że nie mamy wjazdu na LDAPowe grupy uprawnień.
Rozwiązanie bardzo wygodne dla developera i co najważniejsze - dla użytkownika. |
|
|
7.10.2014, 16:41:11
Post
#13
|
|
Grupa: Zarejestrowani Postów: 66 Pomógł: 1 Dołączył: 22.06.2009 Skąd: Londyn, UK Ostrzeżenie: (0%) |
Czytam ten topic, i zauważyłem ze niektórym z was brakuje fundamentalnej wiedzy na temat uwierzytelniania i autoryzacji.
Używacie ciągle slow autentykacja i autoryzacja w tym samym kontekście. Nie ma czegoś takiego jak autentykacja, jest uwierzytelnianie czyli w naszym świecie, proces zidentyfikowania użytkownika, nie ważne czy jego konto jest nie aktywne, zbanowane czy bóg wie co jeszcze, uwierzytelniłeś użytkownika ponieważ byleś wstanie na podstawie jego requestu dojść do obiektu konta lub jakiejkolwiek innej reprezentacji usera. Autoryzacja zarazem to proces gdzie przydzielasz użytkownikowi jakieś możliwości dostępu, czyli jeśli dochodzisz do etapu sprawdzenia czy to konto jest zbanowane lub nie aktywne, lub czy ma dostęp do tego obiektu, to jest własnie autoryzacja. A co do samego procesu używanego prze zemnie, zależy to od kontekstu, jeśli jest to API, to OAuth lub BasicAuth, w innych przypadkach, po prostu ciasteczka. |
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 22:27 |