[MVC] "Globalny" kontroler Opcje

[markonix]

Takie krótkie pytanie.
Czy np. jeżeli mam globalną akcje wylogowania to czy należy stworzyć odpowiedni kontroler "wylogowanie" czy jest coś w stylu globalnego kontrolera?
W starych aplikacjach gdzieś w pliku głównym (czyli taki globalny) np. umieszczało się:

[PHP] pobierz, plaintext 
if (isset($_POST['logout'])) // wylogowanie i ewentualne przekierowanie
[PHP] pobierz, plaintext 

Jak to najlepiej powinno wyglądać w MVC?

Ten post edytował markonix 28.03.2012, 22:02:08

[mortus]

Może ten artykuł co nieco Ci rozjaśni. Ogólnie przechowywaniem informacji o zalogowanym użytkowniku "zajmuje się" odrębna klasa (w ZF jest to klasa Zend_Auth, będąca w dodatku singletonem), przy czym obiekt tej klasy przeważnie przechowywany jest w rejestrze/sesji (Zend_Registry). Sprawdzaniem, czy użytkownik jest zalogowany i określeniem jego uprawnień (choć to odrębna kwestia) zajmują się natomiast pluginy. Logowanie i wylogowywanie to zadanie odpowiedniego kontrolera.

Ten post edytował mortus 28.03.2012, 22:19:28

[markonix]

Za autoryzację mam odpowiedzialną klase (singleton), a samo weryfikowanie dostępu sprawdzam na początku kodu kontrolera (za pomocą metody klasy autoryzacji).
Chyba zrobię po prostu kontroler wylogowania i nie będę się nad tym głowił.

Jednakże kwestia "globalnego kontrolera" wydaje mi się, że do mnie wróci.
Przykładowo system referencyjny:
- w linku url xyz.pl/ref=ktos
W kontrolerze indeks mogę sprawdzić czy jest utworzona zmienna GET i z tym działać.
Ale jak to zrobić uniwersalnie aby xyz.pl/podstrona/ref=ktos także działało i każda kolejna podstrona (obojętnie który kontroler).

[hind]

I tu rozwiązaniem były by pluginy, które odpowiednio sprawdzały by requesta.

[markonix]

Hmm, pluginy w jakim sensie?
Rozszerzenia kontrolera? Jakieś hooki?

[CuteOne]

Właśnie... jakie pluginy?

@makonix tak wyglądają(w dużym skrócie) ścieżki działania dla różnych żądań:
dla żądania "xyz.pl/podstrona/ref=ktos"
FrontController -> Router -> Kontroler ZZZ -> Akcja HUHU

dla żądania "xyz.pl/ref=ktos"
FrontController -> Router -> Kontroler XXX -> Akcja HAHA

innymi słowy Router odpalony przez FC odpala(lub przekazuje ich nazwy dalej) kontroler i akcję dopasowując parametry url do tych, które posiada z jakiegoś źródła(baza danych, plik xml/ini/.php itp.). Więcej o FrontControllerze i routingu dowiesz się przeglądając źródła np. Zenda

[by_ikar]

Ja znowu mam inne pytanie, które jeszcze tutaj nie padło. Pytanie: po co ci globalne wylogowanie? Nie może być ono w jednym miejscu? Robisz sobie jeden kontroler, w którym logujesz i wylogowujesz, i tylko kierujesz na odpowiednie adresy w odpowiednich linkach. W linku do logowania kierujesz na /login a w linku do wylogowania kierujesz na /logout i to wszystko. Nie musisz kombinować z jakimiś globalnie dołączanymi pluginami czy innym ustrojstwem bo i po co? A przy wylogowaniu, sprawdzasz z jakiego adresu dana osoba przybyła i jeżeli ta wartość nie jest pusta, to przekieruj po wylogowaniu na ten adres. Jeżeli jest pusta, to przekieruj na stronę główną. I nic więcej nie trzeba kombinować

[markonix]

Ja znowu mam inne pytanie, które jeszcze tutaj nie padło. Pytanie: po co ci globalne wylogowanie? Nie może być ono w jednym miejscu? Robisz sobie jeden kontroler, w którym logujesz i wylogowujesz, i tylko kierujesz na odpowiednie adresy w odpowiednich linkach. W linku do logowania kierujesz na /login a w linku do wylogowania kierujesz na /logout i to wszystko. Nie musisz kombinować z jakimiś globalnie dołączanymi pluginami czy innym ustrojstwem bo i po co? A przy wylogowaniu, sprawdzasz z jakiego adresu dana osoba przybyła i jeżeli ta wartość nie jest pusta, to przekieruj po wylogowaniu na ten adres. Jeżeli jest pusta, to przekieruj na stronę główną. I nic więcej nie trzeba kombinować

Przykład z wylogowaniem sam w końcu zdementowałem
Lepszym przykładem jest system referencyjny.
W ostatnim zdaniu chyba Ci chodziło aby przekierowywać po ZALOGOWANIU na pożądaną stronę (adres ten przekazuje w linku, podobnie jak w WP).

O FrontController jeszcze nie zdążyłem przeczytać, wrócę do tego.

[mortus]

Właśnie... jakie pluginy?

@makonix tak wyglądają(w dużym skrócie) ścieżki działania dla różnych żądań:
dla żądania "xyz.pl/podstrona/ref=ktos"
FrontController -> Router -> Kontroler ZZZ -> Akcja HUHU

dla żądania "xyz.pl/ref=ktos"
FrontController -> Router -> Kontroler XXX -> Akcja HAHA

innymi słowy Router odpalony przez FC odpala(lub przekazuje ich nazwy dalej) kontroler i akcję dopasowując parametry url do tych, które posiada z jakiegoś źródła(baza danych, plik xml/ini/.php itp.). Więcej o FrontControllerze i routingu dowiesz się przeglądając źródła np. Zenda

@CuteOne: Sprawa systemu referencyjnego ma niewiele wspólnego z routing-iem, więcej z FrontController-em, według przykładu, który zaprezentowałeś zarówno akcja HUHU, jak i akcja HAHA musiałaby implementować kod sprawdzający, czy w adresie URL znajduje się parametr ref. Co więcej każda inna akcja w każdym innym kontrolerze musiałaby implementować dokładnie taki sam kod, co w ogóle mija się z celem. Jedynym słusznym rozwiązaniem jest plugin uruchamiany przez FrontController jeszcze przed "przetworzeniem" żądania. Działało by to mniej więcej tak:
1. wysyłamy żądanie, które odbiera FrontController,
2. FrontController uruchamia plugin, który sprawdza, czy w adresie/żądaniu występuje parametr ref i podejmuje odpowiednią akcję,
3. FrontController na podstawie żądania pobiera informacje od Routera i uruchamia odpowiedni kontroler i odpowiednią akcję.

Gwoli wyjaśnienia, chodzi o to, że jeden i ten sam identyfikator referencji może być przesłany jako parametr zarówno przy wejściu na stronę główną, jak i na każdą inną podstronę.

EDIT:
Podsumowując kwestię logowania i wylogowywania... obie akcje (bo powinny to być raczej akcje, aniżeli kontrolery) powinien realizować jeden i ten sam kontroler autoryzacji. To co się stanie po zalogowaniu, czy też po wylogowaniu można zrealizować na wiele sposobów.

Ten post edytował mortus 2.04.2012, 09:26:47

[marcio]

Podsumowując kwestię logowania i wylogowywania... obie akcje (bo powinny to być raczej akcje, aniżeli kontrolery) powinien realizować jeden i ten sam kontroler autoryzacji. To co się stanie po zalogowaniu, czy też po wylogowaniu można zrealizować na wiele sposobów.

Zalezy jak jest zbudowana aplikacja, w symfony bodajze kazda akcja to osobny plik ja mam frontcontroller/controller i kazdy ma x akcji...

@CuteOne: Sprawa systemu referencyjnego ma niewiele wspólnego z routing-iem, więcej z FrontController-em, według przykładu, który zaprezentowałeś zarówno akcja HUHU, jak i akcja HAHA musiałaby implementować kod sprawdzający, czy w adresie URL znajduje się parametr ref. Co więcej każda inna akcja w każdym innym kontrolerze musiałaby implementować dokładnie taki sam kod, co w ogóle mija się z celem. Jedynym słusznym rozwiązaniem jest plugin uruchamiany przez FrontController jeszcze przed "przetworzeniem" żądania. Działało by to mniej więcej tak:
1. wysyłamy żądanie, które odbiera FrontController,
2. FrontController uruchamia plugin, który sprawdza, czy w adresie/żądaniu występuje parametr ref i podejmuje odpowiednią akcję,
3. FrontController na podstawie żądania pobiera informacje od Routera i uruchamia odpowiedni kontroler i odpowiednią akcję.

O wiele lepszym wyjscie bylby system trigger-ow/event-ow niz plugin-y, bo jako tako plugin to czesc aplikacji ktora rozszerza dany modul/komponent o jakas funkscjonalnosc ktora jest transparentna(jawna) dla uzytkownika.

Tak jak mowi @by_ikar Uwierzytelnianie powinno byc jedno w jednym miejscu

Ten post edytował marcio 2.04.2012, 09:57:17

[mortus]

Zalezy jak jest zbudowana aplikacja, w symfony bodajze kazda akcja to osobny plik ja mam frontcontroller/controller i kazdy ma x akcji...

Fakt, niemniej jednak, chodziło mi o to samo, o czym pisałem w pierwszej mojej odpowiedzi, a co może bardziej precyzyjnie określił by_ikar.

O wiele lepszym wyjscie bylby system trigger-ow/event-ow niz plugin-y, bo jako tako plugin to czesc aplikacji ktora rozszerza dany modul/komponent o jakas funkscjonalnosc ktora jest transparentna(jawna) dla uzytkownika.

Najprawdopodobniej taki system trigger-ów/event-ów miałem na myśli, bo zdaje się, że zasada działania byłaby taka sama i użytkownik nie wiedziałby, że taki event jest w tle wykonywany (choć mógłby się domyślać). Tyle, że ja nazwałem to pluginem, co może rzeczywiście nie jest trafnym określeniem.

[by_ikar]

Zalezy jak jest zbudowana aplikacja, w symfony bodajze kazda akcja to osobny plik ja mam frontcontroller/controller i kazdy ma x akcji...

Nie musi być w osobnym pliku, ale może. Tak samo jak w zendzie i wielu innych frameworkach. Jest kontrole/moduł i w nim są akcje.

W ostatnim zdaniu chyba Ci chodziło aby przekierowywać po ZALOGOWANIU na pożądaną stronę (adres ten przekazuje w linku, podobnie jak w WP).

A dlaczego miałbyś nie przekierowywać również po wylogowaniu? Powiedzmy że prawie cała aplikacja ma dostęp publiczny, są tylko pewne elementy które wymagają uwierzytelnienia. Jak chociażby posty na forum. Po wylogowaniu przeniesie cię do działu w którym byłeś, lub do tematu który czytałeś. A można to zrobić w bardzo różny sposób. Podałem w sumie tylko przykład domyśliłem się z tym "globalnym" wylogowaniem, że właśnie chodziło o powrót do poprzedniej strony na której się było, więc podałem jak można to jeszcze inaczej zrobić.

[markonix]

A dlaczego miałbyś nie przekierowywać również po wylogowaniu? Powiedzmy że prawie cała aplikacja ma dostęp publiczny, są tylko pewne elementy które wymagają uwierzytelnienia.

Akurat aplikacja którą tworzę ma jedną publiczną stronę - strone logowania stąd gdzie kolwiek bym nie przeniósł wyświetliło by się i tak okno logowania
Oczywiście przykład z forum jest słuszny i wylogowanie także może przkierowywać do strony poprzedniej. Wydaje mi się, że jednak parametr GET jest pewniejszy, a przy logowaniu bardziej słuszny bo np. gdy użytkownik często wchodzić będzie na jakąś konkretną podstronę to będzie miał ją w historii. Jeszcze lepszym sposobem od strony usera jest po prostu nie parametr w linku ale normalna strona: adres.pl/akcja, która wyświetla po prostu okno logowania zamiast strony docelowej (bez przekierowania, include + exit z najprostszym, strukturalnym podejściu).