Rozwiązanie problemu z dostępem Opcje

[mma]

Witam!
Od pewnego czasu poznaje mvc i natrafiłem na ciekawy tutorial na http://www.phpit.net/article/simple-mvc-php5/ .
Bardzo mi podeszło to co tam jest przedstawione - myśle, że na początek jest idealne. I, że będe to mugł (mvc) wykorzystywać jako podstawe w kolejnych aplikacjach PHP.

Ale do rzeczy, przechodząc przez ten tutorial - przerabiając cześciowo itp. , zastanawia mnie jeden fakt...
Jak zrobić dosęp do panelu administracyjnego , chciałbym to zrobić w ruterze no i właśnie, nie za bardzo wiem który z pomysłów wybrać.
Mam dwa pomysły na dzień dzisiejszy - jeden to sytuacja w którym sprawdzany jet czy podkatalog w sciezce jest katalogiem administracyjnym
np:

[PHP] pobierz, plaintext 
<?php
//$parts - cześci ścieżki np admin/index, admin =>[0] index=>[1]
if ($parts[0] == ADMIN_FOLDER) {
			if (!($this->_registry->auth->isLoggedIn() && $this->_registry->user->isAdmin()))
				$this->redirect('index');
		}
?>
[PHP] pobierz, plaintext 

Powyższa sytuacja zdaje się być dobra gdy użytkownika zaogowany to admin i nikt więcej.

Drugie rozwiązanie to system praw zapisywanych/odczytywanych z bazy danych (zserializowana tabela).

W ruterze wykonywana by była funkcja mapująca (ja to tak widze) - sprawdzająca otrzymaje prawa z powiązaniami prawo - kontroler.

Jeśli ktoś się zastanawia o co mi chodzi, to chodzi o to czy ma ktoś jakies inne pomysły na rozwiązanie tego zadania, które można by tak w około >80% używać w przyszłości.
Pozdrawiam.

[Sedziwoj]

Liczyłem że zostanie skrytykowana (pozytywnie lub nie) metoda autoryzacji dostępu do treści w kodzie akcji, może się jeszcze doczekam.
Co do metody isAuthorized() to trochę jednak mnie zastanawia, ponieważ czasem zanim dostaniem się do danych nam potrzebnych do autoryzacji musimy wydobyć inne, a wtedy metoda nie robi tylko tego co powinna. Do tego sprawdzenia

[PHP] pobierz, plaintext 
<?php
if ($user->hasCredential('Admin.Post')) {
	return true;
}
...
$obj->getAuthor()->getId() == $user->getAttribute('user_id');
?>
[PHP] pobierz, plaintext 

powinny być nie na tym poziomie, tylko obiekt autoryzacji to powinien wiedzieć, przekazujemy autora i mamy boolean, nie obchodzi nas czy ma dostęp bo jest adminem czy dlatego że jest autorem.
Do tego nie wiemy co mamy robić kiedy ktoś nie ma dostępu do treści, przy edycji to jest raczej oczywiste, przy podanym przeze mnie przykładzie dostępu do artykułu już nie. Ponieważ nie chcemy nic robić więcej niż wyświetlić inny szablon. Oczywiście ta metoda mogła by go zmienić i zwrócić true ale to moim zdanie mijanie się z celem.

Sam nie jestem do niczego przekonany, więc chętnie wysłucham wszelkich konstruktywnych uwag.

[splatch]

Liczyłem że zostanie skrytykowana (pozytywnie lub nie) metoda autoryzacji dostępu do treści w kodzie akcji, może się jeszcze doczekam.
Co do metody isAuthorized() to trochę jednak mnie zastanawia, ponieważ czasem zanim dostaniem się do danych nam potrzebnych do autoryzacji musimy wydobyć inne, a wtedy metoda nie robi tylko tego co powinna.

[PHP] pobierz, plaintext 
<?php
if ($user->hasCredential('Admin.Post')) {
	return true;
}
...
$obj->getAuthor()->getId() == $user->getAttribute('user_id');
?>
[PHP] pobierz, plaintext 

Do tego sprawdzenia powinny być nie na tym poziomie, tylko obiekt autoryzacji to powinien wiedzieć, przekazujemy autora i mamy boolean, nie obchodzi nas czy ma dostęp bo jest adminem czy dlatego że jest autorem.

Nie sądzę byś miał tutaj rację:
- Skąd SecurityManager ma wiedzieć, że ta akcja operuje na takich czy też innych obiektach?
- W jaki sposób ma odczytywać obiekty? W końcu to nie jest brocha SM.
- Co jeśli SecurityManager ma się zachowywać różnie w zależności od akcji? To znaczy są zmiany w sposobie dostępu do tego obiektu.

Osobiście pracuję w kodzie, w którym to SecurityManager ma wiedzieć czy ktoś ma dostęp do obiektu i wierz mi, jest sieczka. Są cztery klasy, każda gromada metod statycznych tylko po to by sprawdzić isUserAuthorizedForApprove(Application, Client, User). Do tego urosły wielkie utile, które są głównie używane w owych managerach.

Do tego nie wiemy co mamy robić kiedy ktoś nie ma dostępu do treści, przy edycji to jest raczej oczywiste, przy podanym przeze mnie przykładzie dostępu do artykułu już nie. Ponieważ nie chcemy nic robić więcej niż wyświetlić inny szablon.

To co przemawia za tym by ten kod był właśnie w akcji to to, że akcja wie z czego będzie korzystać i z nikim innym nie musi się tym dzielić. Mylisz się twierdząc, że akcja nie wie jak zachować się w przypadku błędu z dostępem do obiektu. Może albo wywalić wyjątek, powiedzmy new UnauthorizedObjectAccessException(object $type) a jego obsługę zrzucić na kark FrontController-a albo przekierować na odpowiednią stronę (tu dodajemy metodę do interfejsu).

[PHP] pobierz, plaintext 
<?php
interface SecureAction extends Action {
	public function getCredentials();
}
 
interface CustomAuthorizationAction extends SecureAction {
	public function isAuthorized(RequestDataHolder $rd);
	public function getAuthErrorView();
}
?>
[PHP] pobierz, plaintext 

W skrajnym wypadku można wywalić CustomAuthorizationAction i pójść w abstrakcje:

[PHP] pobierz, plaintext 
<?php
abstract class CustomAuthorizationAction extends AbstractAction implements SecureAction {
 
	public final function execute(RequestDataHolder $rd) {
		if ($this->isAuthorized($rd)) { // user ma prawa do potrzebnych obiektów
			return $this->doExecute($rd);
		}
		return $this->getAuthErrorView();
	}
 
	protected abstract doExecute(RequestDataHolder $rd);
	protected abstract getAuthErrorView();
}
?>
[PHP] pobierz, plaintext 

Oczywiście nie jest to jedyne rozwiązanie, fakt faktem zgłoszone uwagi wymagały rozbudowania przykładu podanego na początku. Inny pomysł jaki przyszedł mi do głowy to tworzenie delegatów, które by się przekazywało do SecureManagera.