Witam,
chce zainstalować sobie login_generator
gem install login_generatorale chce mi instalować zależności rails i rake. Railsy mam zainstalowane w pakietu Debiana. Czy mogę spokojnie wcisnąć Y przy instalowaniu tych zależności czy jakoś to omijać trzeba?
Rowniez zaczalem od instalacji Railsow z pakietow ale szybko zmienilem zdanie.
Szczerze mowiac nie pamietam gdzie pojawil sie pierwszy problem ale ogolnie rzecz biorac szybko zaczalem instalowac wszystko od poczatku przez gem.
Slusznie
Ja pomimo sugesti Adama takze zaczalem w repozytorium… Zaden z projektow mi nie ruszyl! ZADEN!
Wiec wszystko poszlo do smietnika i od nowa poprzez gemy stawialem.
A login_generator dziala pewnie - bawilem sie nim jakis czas i bylem zadowolony. Jednak po pewnym czasie zabraklo mi jakiejs funkcjonalnosci i znalazlem model_security_generator http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html Ma sporo zaawansowanych opcji autoryzacji - praktycznie nie musisz programowac kont uzytkownikiw i obslugi logowania. Mysle ze warto poswiecic mu chwilke.
Pozdrawiam
Polecam raczej pelna dystrybucje ruby z pakietow czyli
ruby1.8 ruby1.8-dev ri1.8 rdoc1.8 irb1.8 ruby1.8-elisp ruby1.8-examples libdbm-ruby1.8 libgdbm-ruby1.8 libtcltk-ruby1.8 libopenssl-ruby1.8 libreadline-ruby1.8
Sprobuj acts_as_authenticated. Jak potrzebujesz tez RBACa to acl_system (dziala “on top of” acts_as_authenticated).
Idac dalej z opcajami - RailsEngine, LoginEngine+UserEngine lub ActiveRBAC, no i wspomniany wyzej ModelSecurity.
Jeszcze troche popytam. Chciałbym umieścić w bazie informacje o użytkownikach. Czy można trzymać takie indormacje w tej samej tabeli co hasła i loginy, czy lepiej trzymać to w innej tabeli? Do logowana używam AAA.
ja trzymam takie dane w tej samej tabeli. nie ma potrzeby tworzyc nowej
W wiekszosci przypadkow jedna tabela powinna wystarczyc.
Mozna pomyslec o dodatkowej tabeli, gdy:
Odn. 2 - Gdyby ActiveRecord potrafil “lazy fetch” property problemu by nie bylo, bo tak jak z asocjacjami pobieralby je “on demand”. Niektore ormy to potrafia np Hibernate 3, ale 2 juz nie. Dosyc spotykany w takich przyp jes pattern: Lightweight Class http://www.hibernate.org/41.html- niestety w AR nie ma zastos. ze wzgl. na model dziedziczenia “table per class hierarchy” wiec pozostaje has_one - belongs_to.
Mozna by pomyslec o pluginie typu acts_as_lazy wprowadzajacy mozliwosc zdef. kt. properties maja byc zaladowane on demand, lub acts_as_lightweight - kt. dla odmiany ukrywalby has_one - belongs_to i wzbogacal klase o properties z zasocjowanej klasy tak zeby mialo sie wrazenie pracy z jednym obiektem.
A co jeżeli user loguje się zwykle jako “zwykły user ;-)” a w celu np. konfiguracji jako “administrator” ?
polecam jednak rozdzielić to na dwie tabele
[quote=valhallaman]A co jeżeli user loguje się zwykle jako “zwykły user ;-)” a w celu np. konfiguracji jako “administrator” ?
polecam jednak rozdzielić to na dwie tabele[/quote]
Wybacz ale nie rozumiem? Jakie to ma znaczenie? To jest kwestia logiki aplikacji. I zaplanowania roli administracyjnej. Uzytkownik to uzytkownik jako taki powinien byc trzymany w jednej tabeli. Jaki sens ma rozrzucanie logicznie tozsamych obiektow po roznych tabelkach? Jesli Cie dobrze zrozumialem, chcesz abym zakladal sobie dwa konta do frontendu i backendu? To chyba nie jest jednak dobry pomysl!
A ja myślę inaczaj … 
czasem ( a mam spore doświadczenie w tym kierunku … ;- ) ) zachodzi
potrzeba przetestowania pewnych ustawień, pomysłow itp. z różnych
pozycji - czy to zwykłego usera, czy admina, czy super-admina
a jeśli chodzi o przykład z życia wzięty :
na linuxa też nie powinno się zawsze logować jako root - root jest od
instalacji, konfiguracji i tak dalej
codzianną pracę powinno się prowadzić na koncie zwykłego usera
jest to praktyka stosowana od wielu lat - i się sprawdza
a gdzie tu rozrzucanie logicznie tożsamych obiektów ? … bo jakoś nie widzę …
logicznie to przyjmując możliwość posiadania więcej niż jednego konta
przez użytkownika, trzymanie osobno danych o kontach, a osobno o
posiadających je userach jest porawne - no chyba że kolega nie przyjmuje
do wiadomości takiej możliwości jak “jeden user - wiele kont”
ale niestety - wyjątek potwierdza regułę, a szewc dalej bez butów chodzi …
[quote=valhallaman]czasem ( a mam spore doświadczenie w tym kierunku … ;- ) ) zachodzi
potrzeba przetestowania pewnych ustawień, pomysłow itp. z różnych
pozycji - czy to zwykłego usera, czy admina, czy super-admina[/quote]
To jest oczywiste, ale testowanie pomyslow, ustawien to chyba jednak domena okresu projektowania i pracy developerskiej nad produktem. Wtedy chyba mozna zalozyc konta testowe, dowolna ich ilosc, tworzyc dowlna ilosc rol…
[quote=valhallaman]a jeśli chodzi o przykład z życia wzięty :
na linuxa też nie powinno się zawsze logować jako root - root jest od
instalacji, konfiguracji i tak dalej
codzianną pracę powinno się prowadzić na koncie zwykłego usera
jest to praktyka stosowana od wielu lat - i się sprawdza[/quote]
Blagam! “Nie mieszajmy logicznie dwoch systemow walutowych” To juz lekka przesada. To przed czym broni Cie rozdzielenie konta roota od konta uzytkownika w *nixach osiagasz dobrze konfigurujac Apache. Zgadzam sie ze w systemie operacyjnym taki podzial jest niezbedny, ale na stronie? Jaki to ma sens? Pozatym administrator strony to jednak nie to samo co administrator systemu. Konta administracyjne pozwalaja Ci zmieniac pewne ustawienai niedostepne dla edytorow/moderatorow i uzytkownikow frontendu. Jest to i tak wyraznie rozdzielone w logice strony - nie sadze zebys dawal mozliwosc zmiany nazwy strony “przy okazji” dodawania komentarza na forum czy artykulu! (zakladam ze uzywasz rol uzytkownikow - to znaczy nie kazdy uzytkownik ma dostep do backendu)
[quote=valhallaman]a gdzie tu rozrzucanie logicznie tożsamych obiektów ? … bo jakoś nie widzę …
logicznie to przyjmując możliwość posiadania więcej niż jednego konta
przez użytkownika, trzymanie osobno danych o kontach, a osobno o
posiadających je userach jest porawne - no chyba że kolega nie przyjmuje
do wiadomości takiej możliwości jak “jeden user - wiele kont”[/quote]
Twoj poprzedni post nie traktowal o rozdzieleniu osoby od konta, tylko o roli uzytkownika i administratora. Nadal twierdze ze konto to konto i nie ma sensu ich rozdzielac. Zgadzam sie ze przy gromadzeniu duzej ilosci danych o uzytkownikach warto rozdzielic informacje miedzy dwie tabele, ale tylko po to by nie “ciagnac” ich nadmiaru, by miec lekka tabelke uzywana “na codzien” przy logowaniu, typowej pracy oraz dane dodatkowe (w zaleznosci od potrzeb)
Jak wyobrazasz sobie prace administratora, ktory aby zaobserwowac wprowadzone zmiany musi przelogowac sie na konto uzytkownika? To absurd! Ja przyjmuje scenariusz jedno konto wiele rol, jest to zdecydowanie wygodniejsze dla uzytkownika, zapobiega gromadzeniu zbednych informacji, oraz pozwala elastycznie dobierac uprawnienia. I nadal podkreslam to logika aplikacji pozwala na kontrole zachowan, nie zas nadmiar kont czy ich rozbicie pomiedzy tabelki! Moze zamiast tworzyc tabelke dla administratorow warto uzyc flagi “is_admin”?
??? Jak wyobrazasz sobie prace administratora, ktory aby zaobserwowac wprowadzone zmiany musi przelogowac sie na konto uzytkownika? To absurd! ???
hmmm … no to mało Kolega widział … na szczęście nie ma jednej “jedynie słusznej”
metodologii rozwoju aplikacji
ok - powiem tak - pracowałem przy bardzo dużej ilości różnych systemów
i aplikacji - raz się ta metoda sprawdzała, innym razem nie była konieczna
Ja to rozwiązanie lubię i często stosuję - zwykle jednak się przydaje
aha - czasami bywa tak, że aplikacja, którą rozwijamy, jest też programem
używanym w codziennej pracy - dla bezpieczeństwa warto jednak mieć
osobno konto - nie muszę się wylogowywać z systemu za każdym razem,
gdy idę zrobić sobie kawę - zgraja współpracowników tylko na to czeka …
zgodzę się natomiast z pomysłem flagi “is_admin” - nie jest “absurdalny” …
heh - proponuję rozwinąć powyższą dyskusję w bardziej sprzyjających
warunkach … np. przy dobrym piwie 
- nie męcząc oczu i nerwów
“swpółforumowiczów”
bo zapomniałem :
??? To przed czym broni Cie rozdzielenie konta roota od konta uzytkownika w *nixach osiagasz dobrze konfigurujac Apache. ???
aplikacje/praca nie kończy się na www/apache
to po pierwsze
rozdzielenie roota/usera to znacznie większe zagadnienie w *nixach - nie tylko apache
( zwłaszcza nie apache )
hmmm … bo znowu zapomnę - jestem zwolennikiem całkowitego oddzielenia
części administracyjnej/monitorującej od reszty logiki aplikacji - oddzielenia
do tego stopnia, że leży ona nawet na innym serwerze ( a nawet w innym środowisku )
W tym wypadku nie ma innej możliwości jak osobe konta …