W mojej aplikacji system logowania stworzyłem na bazie SessionController oraz delegate do modelu User w modelu Session. Pełen kod aplikacji znajduje się na githubie.
I teraz tak - logowanie samo w sobie działa. Ale po zarejestrowaniu użytkownika chciałem wykonać zalogowanie go, więc użyłem pod udanej rejestracji (a właściwie to po aktywacji konta, UsersController#set_activation):
Niewielka to rada z Twojej strony. Za ten odcinek muszę zapłacić, więc no… raczej odmówię.
Natomiast nie zmienia to faktu, że ten błąd nie do końca rozumiem, ale musi być przecież na niego jakieś rozwiązanie. I nie, szybki kurs railsów nie jest rozwiązaniem. Chcę się czegoś także nauczyć, a nie tylko rozwiązać problem za pomocą gemu devise.
Przestudiowałem po raz trzeci w swoim życiu tę zakładkę guides.rubyonrails.org. Wyciągnąłem z tego taki wniosek, że powinienem wykonać przekierowanie do tego kontrolera, a nie go wywoływać. Czy to by było poprawne rozwiązanie tego problemu?
(oprócz tego stwierdziłem, że będę używał wyjątków do obsługi wszelakich błędów tj. nie znaleziono postu lub nie zgadzają się uprawnienia)
Nie - tu nie chodzi o ‘przekierowanie’, ale o to, ze wewnatrz akcji set_activation chcesz (w przypadku poprawnego sprawdzenia kodu itp.) wykonac te sama logike, ktora jest wykonywana we wspomnianym SessionsController
A jesli okazuje sie, ze wykonanie (tej wspolnej logiki) wymaga ‘powielenia/skopiowania’, to znaczy, ze powinna byc ona przeniesiona do jakiejs 3-ciej klasy.
Dodatkowo zamiast dodawac metody zwiazane z ‘aktywacja’ do kontrolera Users moglbys zrobic osobny kontroler Activations lub UserActivations (i rozdzielic Userow od ich Aktywacji)
Chodzi o to, że w pewnym momencie trudno jest iść do przodu samemu - nie wiedząc, w jaki sposób rozwiązywać problemy natury koncepcji i ułożenia kodu.
Uważam, że zastosowanie gotowców - gemów nie nauczy mnie zbyt wiele.
No dobrze, czyli jeśli akcję zalogowania muszę wykonać w kontrolerze sesji (sesji zalogowania w tym przypadku) oraz w kontrolerze aktywacji /kontrolerze użytkownika, to przeniesienie tej akcji do zupełnie nowej klasy przecież nie rozwiąże mojego problemu. W jakiś sposób będę musiał wtedy tę akcję wywołać (jeśli nie w klasie SessionsController to w jakiejś klasie X), X.new.metoda zwróci wtedy ten sam błąd, który miałem na początku. Wywołanie/przekierowanie z set_activation to akcji logowania wydawało mi się… najbardziej oczywiste i przynajmniej zgodne z DRY.
Ja wiem, że to są pytania początkującego, tylko że wszędzie gdzie próbuję znaleźć informacje na ten temat - używa się gemów. Wszędzie gemy. A staram się czegoś nauczyć (wymyślając koło na nowo). Jeśli ktoś zna coś darmowego, prezentującego poprawnie wykonany system logowania, to chętnie się z tym zapoznam. Wyżej podane filmy dotyczące autoryzacji poruszają inny problem (z którym też będę się musiał zmierzyć. ale później). Z góry mówię, że całe to SessionsController też wziąłem z jakiegoś poradnika (ale nie pamiętam już jakiego, ponieważ było to pewien czas temu).
To typowy problem - uzywanie gemów “z definicji”, czesto bez rozumienia co w ogole taki gem robi i po co (i pod jakimi zalozeniami). Jesli czas pozwoli, pokaże Ci co mam na mysli (pod postacią prostego Pull Requesta w Twoim projekcie)
Ludzie bardzo często mylą “authentication” z “authorization”, często im się wydaje że to to samo i pytani o jedno dają link do drugiego
To pierwsze to sprawdzenie czy ten z kim się komunikujemy, jest rzeczywiście tym, za kogo się podaje, nie jestem pewien czy po polsku stosowane słowo autentykacja naprawdę występuje w słowniku polskim.
To drugie polega na sprawdzeniu czy dana “osoba”* ma prawo robić cokolwiek z danym zasobem. Po polsku to po prostu autoryzacja.
I chociaż te dwie sprawy są ze sobą bardzo często ściśle powiązane, to są to dwie różne sprawy i implementacja jednego nie musi być wcale również implementacją drugiego i bardzo często nie jest.
, Zrób lepiej tak jak wyżej pisali zaimplementuj gotowe gemy, no chyba że sam jakiś piszesz 