Temat: Logowanie do programu - dyskusja

Witam, Chciałbym poznać wasze zdanie na temat sposobu logowania użytkowników do programu (np. tworzonego przez nas). Osobiście widziałem takie rozwiązania:

1. Tabela users w bazie danych gdzie było wszystko. Dane użytkownika + hasło w jawnej postaci. Wszyscy pracują na 1 użytkowniku SQL.

2. Tabela users w bazie danych gdzie było wszystko. Dane użytkownika + hasło ale hasło zakodowane. Wszyscy pracują na 1 użytkowniku SQL.

3. Tabela users w bazie danych. Tabela zawiera login w postaci nazwy użytkownika SQL + dadatkowe inforamcje np. pełne imie i nazwisko użytkownika. Każdy użytkownik w programie ma swojego użytkownika na serwerze SQL. 1 metoda moim zdaniem paranoja. 2 metoda też słaba czemu jeden użytkownik SQL na np. 100 osób ??

Osobiście stosuję 3 metodę.
1 użytkownik w programie = 1 użytkownik na serwerze SQL. Hasło jest przechowywane na serwerze SQL. Co myślicie ?? PozdrawiamJacek Łapiński edytował(a) ten post dnia 06.04.11 o godzinie 13:08

Temat: Logowanie do programu - dyskusja

A po co tak komplikujesz sprawę? Piszesz ACLa, i logujesz wszystkie operacje użytkownika (jeżeli chcesz się zabezpieczyć, bo rozumiem że to jest celem tworzenia osobnych userów dla każdego użytkownika programu)

Temat: Logowanie do programu - dyskusja

To zalezy od kontekstu... ;)

Jesli aplikacja jest jedna z wielu w srodowisku, w ktorym ma byc uruchomiona i istnieje juz jakies repozytorium danych o uzytkownikach (np. katalog LDAP), to po co powielac zrodla informacji, skoro mozna miec wszystko w jednym miejscu i tym samym miec scentralizowanie zarzadzanie uprawnieniami/uzytkownikami?
(Byc moze zintegrowane z jakims systemem workflow.) W takiej sytuacji wybralbym uwierzytelnianie uzytkownikow w oparciu o ten istniejacy juz mechanizm, a nie tworzyl konta/tabele w instancji bazy dla aplikacji.

W przypadku aplikacji, ktora jest jedna jedyna w "swoim srodowisku", wyboru nie ma zbyt duzego i takie repozytorium sensownie miec przy aplikacji. Nie tworzylbym dedykowanych uzytkownikow na bazie, tylko tabelke z danymi do uwierzytelnienia (login, skrot hasla). Aplikacja korzystalaby z puli polaczen, a operacje bylyby wykonywane w imieniu uzytkownika (co byloby audytowane).
Plusy jakie widze:
* w przypadku tworzenia nowego uzytkownika w aplikacji nie trzeba by tworzyc konta na bazie (tym samym posiadanie uprawnien do tworzenia uzytkownikow bazodanowych nie jest potrzebne)
* nie trzeba nadawac grantow na N tabelek, pakietow, procedur (co prawda mozna miec role na bazie i ograniczac w ten sposob liczbe grantow - jednak rola bazodanowa nie przeklada sie na role biznesowa, np. rola "RAPORTY_FINANSOWE", ktora rozumiana jest jako rola pozwalajaca na wykonywanie okreslonego zbioru raportow)
* uzytkownik nie mialby bezposredniego dostepu do bazy, a jedynie przez aplikacje

Temat: Logowanie do programu - dyskusja

Jacek Łapiński:
Witam, Chciałbym poznać wasze zdanie na temat sposobu logowania użytkowników do programu (np. tworzonego przez nas). Osobiście widziałem takie rozwiązania:

1. Tabela users w bazie danych gdzie było wszystko. Dane użytkownika + hasło w jawnej postaci. Wszyscy pracują na 1 użytkowniku SQL.

2. Tabela users w bazie danych gdzie było wszystko. Dane użytkownika + hasło ale hasło zakodowane. Wszyscy pracują na 1 użytkowniku SQL.

3. Tabela users w bazie danych. Tabela zawiera login w postaci nazwy użytkownika SQL + dadatkowe inforamcje np. pełne imie i nazwisko użytkownika. Każdy użytkownik w programie ma swojego użytkownika na serwerze SQL. 1 metoda moim zdaniem paranoja. 2 metoda też słaba czemu jeden użytkownik SQL na np. 100 osób ??

Osobiście stosuję 3 metodę.
1 użytkownik w programie = 1 użytkownik na serwerze SQL. Hasło jest przechowywane na serwerze SQL. Co myślicie ?? PozdrawiamJacek Łapiński edytował(a) ten post dnia 06.04.11 o godzinie 13:08

Wszystko ma swoje plusy i minusy.
Ad1. Jak ktoś już ma dostęp do bazy tak że może przejrzeć tabelkę z userami to niezależnie czy jest ono zakodowane czy nie, czy użytkownik łączy się na bazę przy uwierzytelnianiu użytkownikiem bazodanowym czy nie z reguły może namieszać tak na hasłach ze zaloguje się na dowolnego usera.
A po co 100 użytkowników na bazie? Ja znam jeszcze taką metodę że do uwierzytelniania wykorzystywany jest użytkownik bazodanowy ale połączenie na bazę jest już robione z jednego użytkownika. Trochę na około ale tak ktoś wymyślił.

Temat: Logowanie do programu - dyskusja

W moim przypadku jest to system coś RPMo podobny.

Czyli mam określoną listę ludzi która będzie korzystać z programu.
Pytam bo na uczelni gość zawsze nam wkładał, że trzymanie haseł tabeli bazy danych jest najgorszym co można zrobić. Ale biorąc pod uwagę fakt, że zakładając dla każdego usera programu, usera SQLowego można przez pomyłkę (niedopatrzenie w dawaniu uprawnień) dać mu możliwość zalogowania się do bazy danych i namieszania w danych jednak skłaniał bym się na jednego użytkownika SQL w bazie z odpowiednimi uprawnieniami.

Jeszcze jedno pytanko. Mając aplikację desktop gdzie trzymacie hasło dla użytkownika SQL ?? Zakładam, że program się uruchamia, pobieram dane użytkowników z bazy (muszę się w tym momencie połączyć i odczytać dane). Może hasło rozrzucić po programie i potem je składać ??

Pozdrawiam i dzięki za odpowiedzi.

Temat: Logowanie do programu - dyskusja

Jacek Łapiński:
Jeszcze jedno pytanko. Mając aplikację desktop gdzie trzymacie hasło dla użytkownika SQL ?? Zakładam, że program się uruchamia, pobieram dane użytkowników z bazy (muszę się w tym momencie połączyć i odczytać dane). Może hasło rozrzucić po programie i potem je składać ??

Moim zdaniem, w przypadku kiedy bedzie to appka desktopowa, nie powiniens komunikowac sie bezposrednio z baza tylko zrobic do tego webservice i pobierac dane poprzez niego.

Temat: Logowanie do programu - dyskusja

nie zakładasz chyba każdego konta ręcznie?
to można ładnie opakować logika np. w PHP i zakładać z poziomu formularza

kolejna kwestia loginy i tak są przechowywane w tabeli to czy to będzie twoja tabela czy systemowa MySQL to kwestia względna

Temat: Logowanie do programu - dyskusja

Jacek Łapiński:
Jeszcze jedno pytanko. Mając aplikację desktop gdzie trzymacie hasło dla użytkownika SQL ?? Zakładam, że program się uruchamia, pobieram dane użytkowników z bazy (muszę się w tym momencie połączyć i odczytać dane). Może hasło rozrzucić po programie i potem je składać ??

Możesz użyć osobnego użytkownika DBMS tylko dla procesu uwierzytelniania.
Użytkownik taki nie musi mieć dostępu do wszystkich obiektów, wystarczy dostęp do tabeli skrótów haseł lub najlepiej procedury która z niej korzysta.
A po uwierzytelnieniu (ale tylko jeśli zakończyło się sukcesem) można podesłać z serwera właściwe hasło do bazy.Piotr L. edytował(a) ten post dnia 25.10.11 o godzinie 21:06

Temat: Logowanie do programu - dyskusja

Przemysław R.:
kolejna kwestia loginy i tak są przechowywane w tabeli to czy to będzie twoja tabela czy systemowa MySQL to kwestia względna

Tylko, że loginy w MySQL mogą mieć maksymalnie 16 znaków, więc jak będziesz chciał zrobić system, gdzie login = adres e-mail, to klops.

A np. w MS SQL 2000 można założyć maksymalnie 16367 kont.

Znajdź też hosting, który pozwoli Ci na nieograniczoną liczbę kont na bazie :)

Temat: Logowanie do programu - dyskusja

Maciej W.:

Jacek Łapiński:
Jeszcze jedno pytanko. Mając aplikację desktop gdzie trzymacie hasło dla użytkownika SQL ?? Zakładam, że program się uruchamia, pobieram dane użytkowników z bazy (muszę się w tym momencie połączyć i odczytać dane). Może hasło rozrzucić po programie i potem je składać ??

Moim zdaniem, w przypadku kiedy bedzie to appka desktopowa, nie powiniens komunikowac sie bezposrednio z baza tylko zrobic do tego webservice i pobierac dane poprzez niego.

A o co to robić, jeżeli nie ma takiej wyraźniej potrzeby?
Żeby było trendy czy żeby było woooooooooooooooooooooolnoooooooooooooooo?
Wypas rada - nie ma co.

Temat: Logowanie do programu - dyskusja

Daniel "wloochacz" Grabowski:
A o co to robić, jeżeli nie ma takiej wyraźniej potrzeby?

Narazie jest problem i autor szuka rozwiazania.

Daniel "wloochacz" Grabowski:
Żeby było trendy czy żeby było woooooooooooooooooooooolnoooooooooooooooo?

Doooh, glupie pytanie. Przeciez wiadomo ze trendy juz i tak nie bedzie bo musialby uzyc jakiegos NoSQL ;)

Daniel "wloochacz" Grabowski:
Wypas rada - nie ma co.

No to moze podziel sie z nami swoja wiedza i doswiadczeniem, ja sie chetnie naucze czegos nowego. No chyba ze cos sie zmienilo i grupy sa teraz od tego zeby pisac "LOLOLOLO ale glupia rada!!!!11one"?Maciej W. edytował(a) ten post dnia 07.04.11 o godzinie 23:12

Temat: Logowanie do programu - dyskusja

Maciej W.:

Daniel "wloochacz" Grabowski:
A o co to robić, jeżeli nie ma takiej wyraźniej potrzeby?

Narazie jest problem i autor szuka rozwiazania.

Daniel "wloochacz" Grabowski:
Żeby było trendy czy żeby było woooooooooooooooooooooolnoooooooooooooooo?

Doooh, glupie pytanie. Przeciez wiadomo ze trendy juz i tak nie bedzie bo musialby uzyc jakiegos NoSQL ;)

Bzdura - równie trendy jest Azure, a to wcale nie wyklucza SQL.

Daniel "wloochacz" Grabowski:
Wypas rada - nie ma co.

No to moze podziel sie z nami swoja wiedza i doswiadczeniem, ja sie chetnie naucze czegos nowego. No chyba ze cos sie zmienilo i grupy sa teraz od tego zeby pisac "LOLOLOLO ale glupia rada!!!!11one"?

Z choinki się urwałeś? Grupy zawsze do tego służyły...

A co do rady - na jaką cholerę, mając app desktopową - czyli klasyczną C/S mam ją przepisywać na WS?
To nie jest aplikacja webowa, nie jest to też SmartClient i nie jest dostępna w sieci rozległej - co więcej, nie ma potrzeby aby cześć logiki udostępniać na innych platformach.
A więc czemu miałaby służyć migracja do WS?
Bo Ty tak robisz?Daniel "wloochacz" Grabowski edytował(a) ten post dnia 14.04.11 o godzinie 14:12

Temat: Logowanie do programu - dyskusja

Moim zdaniem, w przypadku kiedy bedzie to appka desktopowa, nie powiniens komunikowac sie bezposrednio z baza tylko zrobic do tego webservice i pobierac dane poprzez niego.

A o co to robić, jeżeli nie ma takiej wyraźniej potrzeby?
Żeby było trendy czy żeby było woooooooooooooooooooooolnoooooooooooooooo?

Pewnie, że dobrze radzi.
Wyobraź sobie, że masz 1000 klientów i KAŻDY "gada" z bazą. Nagle okazuje się, że musisz zmienić strukturę bazy.... zmienisz naraz 1000 klientów?
Później okazało się, że baza nie wyrabia i bedzie kolejna zmiana i tak dalej...

Lepiej przykryć bazę jakimś api i zapewnić, że api się nie zmieni. To nie jest kwestia bycia trendy.

Temat: Logowanie do programu - dyskusja

Daniel "wloochacz" Grabowski:
A co do rady - na jaką cholerę, mając app desktopową - czyli klasyczną C/S mam ją przepisywać na WS?
To nie jest aplikacja webowa, nie jest to też SmartClient i nie jest dostępna w sieci rozległej - co więcej, nie ma potrzeby aby cześć logiki udostępniać na innych platformach.
A więc czemu miałaby służyć migracja do WS?

Np. żeby nie instalować sterownika bazy na stacji użytkownika.
Albo nie zmieniać tegoż sterownika po aktualizacji DBMS-a do wyższej wersji.
Albo żeby się nie zastanawiać jak driver bazy jest skonfigurowany na stacji użytkownika (patrz BDE).
Albo żeby ograniczyć bezpośredni dostęp do bazy.

Temat: Logowanie do programu - dyskusja

Piotr Likus:

Daniel "wloochacz" Grabowski:
A co do rady - na jaką cholerę, mając app desktopową - czyli klasyczną C/S mam ją przepisywać na WS?
To nie jest aplikacja webowa, nie jest to też SmartClient i nie jest dostępna w sieci rozległej - co więcej, nie ma potrzeby aby cześć logiki udostępniać na innych platformach.
A więc czemu miałaby służyć migracja do WS?

Np. żeby nie instalować sterownika bazy na stacji użytkownika.

Faktycznie - to jest naprawdę ogromny problem.
Skoro to jest problem, to po co app desktopowa?
Niech będzie webowa!

Albo nie zmieniać tegoż sterownika po aktualizacji DBMS-a do wyższej wersji.

No wiesz co... Stać Cię na więcej.

Albo żeby się nie zastanawiać jak driver bazy jest skonfigurowany na stacji użytkownika (patrz BDE).

BDE zdechło ile? 5 czy 10 lat temu?

Albo żeby ograniczyć bezpośredni dostęp do bazy.

A po co, skoro to najszybsza metoda na pobranie i przetwarzanie danych z bazy właśnie?

Wszystko pięknie ładnie - ale ja nie prosiłem o pomysły na wykorzystanie WS.
Sam mam ich napisanych troszkę i robią ciut ciekawsze rzeczy niż napisaliście.
Ale!
Chodziło o tę konkretną dyskusję w tym konkretnym kontekście.
App jest gotowa, działa i ma się dobrze. Kolega pyta o sposoby autoryzacji, a Wy mu proponujecie aby przepisał app na WS?

Temat: Logowanie do programu - dyskusja

Michał Gruchała:

Moim zdaniem, w przypadku kiedy bedzie to appka desktopowa, nie powiniens komunikowac sie bezposrednio z baza tylko zrobic do tego webservice i pobierac dane poprzez niego.

A o co to robić, jeżeli nie ma takiej wyraźniej potrzeby?
Żeby było trendy czy żeby było woooooooooooooooooooooolnoooooooooooooooo?

Pewnie, że dobrze radzi.
Wyobraź sobie, że masz 1000 klientów i KAŻDY "gada" z bazą. Nagle okazuje się, że musisz zmienić strukturę bazy.... zmienisz naraz 1000 klientów?

Nie - zmieniam odpowiednią encję w metadanych, która odpowiada za to w jaki sposób obiekty modelu dziedziny "gadają" z bazą danych.
Mam na myśli np. taki mapper jak MyBATIS

Później okazało się, że baza nie wyrabia i bedzie kolejna zmiana i tak dalej...

A co zrobisz jak Ci się owe WS zaczną nie wyrabiać a baza się nudzi i w nosie grzebie? Dostawisz kolejny serwer, a może cały klaster?
Prawda jest taka, że WS są bardzo wygodne i elastyczne.
Ale mają też wady - jedna z nich to potężny dodatkowy narzut.
WS jako zamiennik DAL'a nie zawierający żadnej logiki to zdecydowanie kiepski pomysł.

Lepiej przykryć bazę jakimś api i zapewnić, że api się nie zmieni. To nie jest kwestia bycia trendy.

Zgoda, tylko że to nie implikuje używania WS do tego celu.

Temat: Logowanie do programu - dyskusja

Daniel "wloochacz" Grabowski:

Piotr Likus:

Wszystko pięknie ładnie - ale ja nie prosiłem o pomysły na wykorzystanie WS.
Sam mam ich napisanych troszkę i robią ciut ciekawsze rzeczy niż napisaliście.
Ale!
Chodziło o tę konkretną dyskusję w tym konkretnym kontekście.
App jest gotowa, działa i ma się dobrze. Kolega pyta o sposoby autoryzacji, a Wy mu proponujecie aby przepisał app na WS?

A czytałeś coś więcej niż swoje wypowiedzi i komentarze do nich?

Albo żeby ograniczyć bezpośredni dostęp do bazy.

A po co, skoro to najszybsza metoda na pobranie i przetwarzanie danych z bazy właśnie?

BTW, C/S nie jest najszybszym sposobem na dostęp do danych z DBMS-u, jest wręcz przeciwnie, jest to jeden z najwolniejszych dostępów...Piotr L. edytował(a) ten post dnia 25.10.11 o godzinie 21:06

Temat: Logowanie do programu - dyskusja

Piotr Likus:

Daniel "wloochacz" Grabowski:

Piotr Likus:

Wszystko pięknie ładnie - ale ja nie prosiłem o pomysły na wykorzystanie WS.
Sam mam ich napisanych troszkę i robią ciut ciekawsze rzeczy niż napisaliście.
Ale!
Chodziło o tę konkretną dyskusję w tym konkretnym kontekście.
App jest gotowa, działa i ma się dobrze. Kolega pyta o sposoby autoryzacji, a Wy mu proponujecie aby przepisał app na WS?

A czytałeś coś więcej niż swoje wypowiedzi i komentarze do nich?

Czytałem - no i?
Bo nie rozumiem o co Ci chodzi.

Albo żeby ograniczyć bezpośredni dostęp do bazy.

A po co, skoro to najszybsza metoda na pobranie i przetwarzanie danych z bazy właśnie?

BTW, C/S nie jest najszybszym sposobem na dostęp do danych z DBMS-u, jest wręcz przeciwnie, jest to jeden z najwolniejszych dostępów...

OK - ciekawość bierze, jakie są te szybsze?
Skoro każda inna warstwa musi w jakiś sposób rozmawiać z bazą (i robi to korzystając z klienta bazy), a więc po co ten narzut jaki niosą ze sobą WS kiedy nie jest konieczny?

Temat: Logowanie do programu - dyskusja

Daniel "wloochacz" Grabowski:

BTW, C/S nie jest najszybszym sposobem na dostęp do danych z DBMS-u, jest wręcz przeciwnie, jest to jeden z najwolniejszych dostępów...

OK - ciekawość bierze, jakie są te szybsze?
Skoro każda inna warstwa musi w jakiś sposób rozmawiać z bazą (i robi to korzystając z klienta bazy), a więc po co ten narzut jaki niosą ze sobą WS kiedy nie jest konieczny?

Też jestem ciekawy, co jest szybsze od bezpośredniego dostępu (C/S) do bazy ?

Temat: Logowanie do programu - dyskusja

Daniel "wloochacz" Grabowski:

A co zrobisz jak Ci się owe WS zaczną nie wyrabiać a baza się nudzi i w nosie grzebie? Dostawisz kolejny serwer, a może cały klaster?

Elementy bezstanowe (workery obslugujace WS) mozna dokladac w nieskonczonosc, wiec nie ma z nimi problemu.
Co sie stanie, gdy baza przestanie wyrabiac?
Tu jest pies pogrzebany, baza, dane

Prawda jest taka, że WS są bardzo wygodne i elastyczne.

sa ;)

Ale mają też wady - jedna z nich to potężny dodatkowy narzut.

maja wady :)
potezny dodatkowy narzut - mocno zabrzmialo ... gdy mówimy o prostej "translacji" zlecenia HTTP na zapytanie SQL