Mam małą zagwozdkę. W różnych systemach, różnie to rozwiązywałem, jednak chciałbym poznać wasze zdanie na ten temat.
Załóżmy taką sytuację. Jest serwis, w którym istnieje kilka grup użytkowników oraz różne zasoby. Oczywistym jest, że różne grupy mają różny poziom dostępu. Jeśli jakiś użytkownik, który nie ma uprawnień, próbuje dostać się do pewnego zasobu, otrzymuje komunikat błędu. Jaki powinien być ten komunikat?
1. 404 - nie ma takiej strony?
2. Wyświetlić stronę z informacją o braku dostępu do zasobu?
3. Wyświetlić formularz logowania?

a moze wyswietlic podstrone z informacja o braku uprawnien do przegladania tej strony + link do formularza logowania?

zależy od typu zawartości - czasami wystarczy redirect na /login (bo po logowaniu będzie ok), czasami potrzebny będzie komunikat z okrojoną zawartością strony (np. "profil tylko dla przyjaciół"), a czasami kombinacja obu: redirect z komunikatem.

Do takich komunikatów bardzo przydają się tzw. flash_messages (msg w sesji defaultowo żyjące 1 przeładowanie).

ja po prostu ograniczam takiemu użytkownikowi możliwość przejścia do podstron / uruchamiania funkcji do takich na jakie ma uprawnienia. tzn. cały interfejs jest dynamiczny i wyświetla tylko te elementy, które są niezbędne dla danego użytkownika. moje doświadczenia wskazują, że nawet jak sto razy user po kliknięciu w przycisk "edytuj" albo "usuń" widzi komunikat "niestety, masz uprawnienia tylko do przeglądania" to i tak klika kolejny raz... a jak w ogóle nie widzi przycisków " edytuj" i "usuń" to go nic nie korci

Tak, ale w wypadku gdy użytkownik straci sesję lub podąży za linkiem z gady-gadu, jakiegoś forum przedstawiającym krok po kroku co ma zrobić to jeśli nie jest zalogowany(a jest to konieczne) to trzeba wykonać jakąś akcję.

Najłatwiej przekierować na podstronę logowania z zachowaniem adresu url skąd użytkownik przyszedł i razem z id wiadomości którą trzeba wyświetlić petentowi.

@nevt: słusznie, ale jak napisałem wyżej wszystko zależy od kontentu i nie ma jednej słusznej odpowiedzi. Trzymając się tego przykładu z profilem to muszę userowi wyświetlić stronę z profilem i pozbawioną jakiś tam informacji z komunikatem dlaczego nie ma pełnego wglądu i z menu np. z zaproszeniem do kontaktów (bo jakbym mu odciął wczytanie profilu to nie miałby nawet jak kogoś zaprosić do kontantu).

To jest oczywiste, ale są przypadki, że ktoś kombinuje z linkami, podmienia adres, itp. W takiej sytuacji nie ma możliwości ukrycia przycisku.

W kontrollerze

[PHP] pobierz, plaintext 
<?php
try
{
	// sprawdzane zasoby
	$object = new Object();
 
	// sprawdzenie uprawnień odczytu do obiektu, $this->client to obiekt bieżącego użytkownika
	$this->client->read($object,true);
 
	// dalszy kod tzn. reszta danych, logiki
 
}
catch(AccesExcepton $e)
{
	// kod obsługi braku dostępu
}
?>
[PHP] pobierz, plaintext 

w szablonie

[PHP] pobierz, plaintext 
<?php
if($client->read($object)) 
{
	// wyświetl przycisk
}
?>
[PHP] pobierz, plaintext 

Zapis
Client::read($object, $throw = false)
to metoda, w której drugi parametr decyduje czy wygenerować wyjątek - czy zwrócić false/true
($client to obiekt użytkownika)

Jeżeli ktoś ma lepszy sposób, chętnie poczytam

...jeszcze coś mi do głowy przyszło : można napisać klase do tworzenia przycisków (linki i kontrola uprawnień byłaby w jednym miejscu)

[PHP] pobierz, plaintext 
<?php
$object->deleteButton($user);
?>
[PHP] pobierz, plaintext 

Klasa ta gdzieś była by dziedziczona np. model ->klasa_linki_uprawnienia -> klasa_właściwa ($object)

luźna myśl.....

@jastu
Tak się składa, że robię na ZF, więc mój kod wygląda nieco inaczej
Chodzi mi o uwagi mniej praktyczne

Mhh, ja wyświetłam zawsze brak uprawnień. Sprawdzam to w trakcie odczytywania z adresu akcji i metody. Jeśli user ma prawa, to mu się wyświetli, jeśli nie to nie. A jak z linkami?
if($this->getPlugin('Access')->can('Akcja', 'Model')) { wyswietl odpowiedni link }
Jeśli chodzi o co wyświetlić userowi co nie, to w templatce zwykła ifka moim zdaniem starcza. Nie ma tutaj co kombinować. Aha, taka myśl mi przyszła, żeby sprawdzać referera. Jak z naszej strony, to link do logowania (mówię tutaj, np o edytuj linku), a jak bez referera to 404.

Ja daje formularz logowania z 403, zapamietuje akcje i po zalogowaniu wracam ...

Aczkolwiek czasami lepiej zrobić 404 (tzn. dokładnie tą samą akcję jaką dajesz w przypadku 404) - dla różnych krytycznych zasobów. Szczególnie jeżeli np. coś po zalogowaniu dostępne tylko dla pewnej niewielkiej podgrupy osób które mogą się zalogować. Wtedy lepiej nie zdradzać co istnieje w serwisie a co nie.

Ja mam to rozwiązane tak. Mam klasę ACLConfiguration, która zawiera wykaz (w postaci tablicy) akcji i wymaganych uprawnień z parametrami. Do jednej akcji może być przypisane kilka uprawnień ale posiadanie tylko jednego z nich pozwala na uruchomienie akcji. W kontrolerze sprawdzam czy user jest zalogowany i jeżeli akcja, którą chce odpalić znajduje się w klasie ACLConfiguration to sprawdzam czy posiada odpowiednie uprawnienia. Jeśli nie to jest przekierowany na stronę logowania. Oczywiście user nie widzi przycisków jeśli nie ma uprawnień. Manipulowanie linkami nic nie da.Sprawdza się w 100%.