Konfiguracja akcji

Ta sekcja pliku konfiguracyjnego zawiera definicję oraz konfigurację wszystkich akcji w twojej aplikacji.

Każda z akcji zawarta jest w tagu akcji. Opcje takie jak "name" oraz "inherit-from" pojawiają się bezpośrednio w tymże tagu. Wszystkie dopasowania są z kolei w tagu dopasowań.

<action>
 <name>NameOfYourAction</name>
 <inherit-from>NameOfAnotherAction</inherit-from>
 <action-config>
 <required-roles>FirstRole SecondRole</required-roles>
 </action-config>
 <matches>
 <contains>/phiend-doc/pages/view-action-source</contains>
 </matches>
</action>

Tagi dozwolone dla poszczególnych akcji opisane są poniżej.

To nazwa twojej akcji. Każda z akcji musi mieć niepowtarzalną nazwę. Nazwa ta używana jest w wielu miejscach:

• Kiedy akcja ta pochodzi ( inherit-form), jest niejako "odziedziczona" po innej akcji.
• Plik konfiguracyjny tej akcji wytworzony przez parser będzie nosił nazwę <action-name>.config.php.
• Plik klasy dla twojej akcji (w podkatalogu actions/ głównego katalogu kodu) musi być nazwany <action-name>.class.php.
• Twoja klasa akcji musi nosić nazwę dokładnie taką samą, jak twoja akcja
• Kiedy łączysz akcje w łańcuch, musisz dostarczyć Phiend'owi nazwę akcji, która będzie wykonana w następnej kolejności.

Ta opcja nie jest zwykła opcją. Nie jest ona tak naprawdę używana przez Phiend'a. Raczej poleca on parserowi, żeby konfiguracja tej konkretnej akcji została skopiowana z jakiejś innej akcji. Wszystkie akcje zawarte w tagu action-config mogą pochodzić od innych akcji, być niejako po nich "odziedziczone". W przeciwieństwie do innych opcji.

Kiedy akcja B pochodzi od (zostaje odziedziczona) akcji A, akcja A musi zostać określona przed akcją B. Odziedziczenie może również zostać połączone w łańcuch- np. akcja C może być "odziedziczona" po akcji B.

Wszystkie akcje zawarte w tagu action-config zostają "odziedziczone", niezależnie od tego, czy zostały naprawdę napisane, czy przyjęte domyślnie. Jednak jeśli jedna z twoich akcji zostaje "odziedziczona" po innych i potem przedefiniowuje niektóre opcje, te opcje, które ty napisałeś nadpisują te, które zostały "odziedziczone". Na przykład:

<action>
 <name>ActionA</name>
 <action-config>
 <accept-sid>true</accept-sid>
 <required-roles>RoleA RoleB</required-roles>
 </action-config>
 <matches>
 <contains>/phiend-doc/pages/view-phiend-source</contains>
 </matches>
</action>
<action>
 <name>ActionB</name>
 <inherit-from>ActionA</inherit-from>
 <action-config>
 </action-config>
 <matches>
 <contains>/phiend-doc/pages/view-action-source</contains>
 </matches>
</action>
<action>
 <name>ActionC</name>
 <inherit-from>ActionA</inherit-from>
 <action-config>
 <required-roles>RoleC</required-roles>
 </action-config>
 <matches>
 <contains>/phiend-doc/pages/view-session</contains>
 </matches>
</action>

Jest równoznaczne z:

<action>
 <name>ActionA</name>
 <action-config>
 <accept-sid>true</accept-sid>
 <required-roles>RoleA RoleB</required-roles>
 </action-config>
 <matches>
 <contains>/phiend-doc/pages/view-phiend-source</contains>
 </matches>
</action>
<action>
 <name>ActionB</name>
 <inherit-from>ActionA</inherit-from>
 <action-config>
 <accept-sid>true</accept-sid>
 <required-roles>RoleA RoleB</required-roles>
 </action-config>
 <matches>
 <contains>/phiend-doc/pages/view-action-source</contains>
 </matches>
</action>
<action>
 <name>ActionC</name>
 <inherit-from>ActionA</inherit-from>
 <action-config>
 <accept-sid>true</accept-sid>
 <required-roles>RoleC</required-roles>
 </action-config>
 <matches>
 <contains>/phiend-doc/pages/view-session</contains>
 </matches>
</action>

Notatka

Opcja ta może przyjąć tylko dwie wartości: logic lub view. Aby zapoznać się lepiej z tematem rodzajów akcji zobacz "Rodzaje akcji".

Jeśli taka opcja jest podana, powie to Phiend'owi, jaką akcję należy wykonać, jeśli dana akcja nie zostanie spełniona. Niespełnienie jest najczęściej spowodowane niemożnością uwierzytelnienia użytkownika, to znaczy na przykład, kiedy użytkownik nie posiada wystarczających praw, aby uzyskać dostęp do akcji. Jeśli nie zostanie podana żadna akcja zastępcza, Phiend nie będzie w stanie kontynuować łańcucha akcji i zakończy go, drukując na ekranie wiadomość o błędzie. Tak więc zawsze powinieneś uwzględniać tę opcję, jeśli twoja akcja wymaga uwierzytelnienia.

Ten tag może pojawić się kilka razy, w ramach pojedynczego tagu action. Używa się go w celu zaopatrzenia tej akcji we własne parametry.

Jest to lista ról, jakie musi posiadać użytkownik, aby uzyskać dostęp do danej akcji. Role powinny być przedzielone odstępami. Jeśli potrzebujesz więcej informacji na ten temat przeczytaj "Czym są role użytkownika?".

Jeśli ustawiona jest jako true, akcja ta wyloguje użytkownika. Jeśli sesja istnieje dla danego użytkownika, zostanie całkowicie wymazana. Zaleca się dostarczenie linku wylogowującego z twojej aplikacji. Jeśli sesja użytkownika zostaje usunięta, nie może być ona przejęta. Ponadto, jeśli użytkownik nie wyloguje się z twojej aplikacji, może mieć pozostawione "ciasteczko" na swojej przeglądarce, a serwer nie zakończy sesji, co zasadniczo znaczy, że na serwerze zostanie bezużyteczny plik. Na szczęście PHP posiada kolektor zbędnych sesji, który co jakiś czas usuwa nie zużyte sesje.

Jeśli akcja wymusza wylogowanie się, nie powinna wymagać żadnych ról. Po oczyszczeniu sesji, użytkownik nie będzie w stanie się uwierzytelnić. Ponadto bezcelowe byłoby zmuszanie użytkownika, aby się wylogował (i w ten sposób utracił informacje o swojej tożsamości) a zaraz potem ponownie się uwierzytelniał.

Ustawienie jej jako true pozwoli danej akcji na zalogowanie użytkownika, kiedy hasła otrzymywane są przez POST'a. Twoja klasa akcji nie musi nic robić z zainicjowanymi wartościami, nie musi nawet wiedzieć, że użytkownikowi powiodło się uwierzytelnienie. Wszystko to obsługuje Phiend.

Jeśli opcja ta ustawiona jest jako true, Phiend będzie szukał zmiennych POST'a o nazwach login oraz password. Jeśli obie zostaną znalezione, Phiend założy, że połączą one nazwę i hasło użytkownika, który próbuje się zalogować. Wtedy sterowniki uwierzytelnienia zostaną zapytane o konkretną nazwę i hasło użytkownika, aby sprawdzić, czy taki użytkownik w ogóle istnieje. Jeśli tak, wyszukane zostają role, które posiada.

Zmienne POST'a muszą mieć nazwy: login oraz password - to nie podlega konfiguracji. Mało celowe jest dodawanie do nich "ponadplanowego" kodu, jeśli nie ma żadnego powodu, aby nie wywoływać w ten sposób swojego pola formularza.

Notatka

Ustawienie jej jako true pozwoli danej akcji na uwierzytelnienie już zalogowanych użytkowników i otwarcie ważnej sesji. Jeśli używasz uwierzytelnienia, ta opcja zdecydowanie powinna być włączona dla większości twoich akcji. Inaczej użytkownicy będą musieli wpisywać swoje hasło na każdej stronie.

Phiend używa standardowych mechanizmów obsługi sesji. Znaczy to, że sesje będą kontrolowane przy pomocy cookies lub poprzez dodanie do każdego linka identyfikatora sesji. Przebieg tego jest zarządzany przez dyrektywy session.use_cookies oraz session.use_trans_sid w twoim pliku konfiguracyjnym.

Sesja jest ważna, jeśli spełnione są następujące warunki:

• Identyfikator sesji jest przesyłany przez wyszukiwarkę, albo przez cookie jako GET lub zmienną POST'a. Nazwa sesji musi być taka sama, jak wartość opcji session-name
• Sesja odpowiadająca identyfikatorowi sesji istnieje na serwerze.
• Sesja zawiera nazwę użytkownika. Dlatego też opcja force-logout nie powinna być używana z opcją accept-sid - usuwa ona skład aktualnej sesji, wskutek czego staje się ona bezużyteczna.
• Nazwa użytkownika jest ważna. Aby to sprawdzić Phiend wysyła zapytania do sterowników uwierzytelnienia. Hasło nie jest tu dostępne, tak więc sterownik musi być w stanie uwierzytelnić użytkownika jedynie poprzez jego nazwę.

Notatka

Ustaw tę opcję jako true, jeśli dana akcja ma być udostępniona tylko poprzez używanie protokołu HTTPS. Więcej informacji znajdziesz pod "use-redirects" w "Podstawowa konfiguracja Phiend'a".

Ten tag powinien zawierać dopasowania twoich akcji. Dopasowania są regułami, które mapują żądanie do konkretnej akcji. Są różne rodzaje dopasowań, a każde z nich ma własny tag, który może być tu umieszczony. Więcej informacji o dopasowaniach pod "Rozpoczynanie łańcucha: dopasowania akcji".