Dzisiaj po problemach z prądem przywitała nas niemiła niespodzianka. Serwer jednego z naszych klientów nie podniósł się – jak się okazało wystąpił jakiś problem z ciągłością danych na dyskach i system nie był w stanie się uruchomić.

W takiej sytuacji rozpoczęliśmy oczywiście od poszukiwania rozwiązania w google i znaleźliśmy.

Tak więc jeżeli i Ciebie powita komunikat podobny do:

Starting file system checks :
...
Automatic file system check failed; help!
Oct. 30 20:14:53 init: /bin/sh on /etc/rc terminated abnormally, going to
single user mode

Uruchom po prostu polecenie: fsck -y

Zaczekaj aż fsck naprawi ewentualne błędy a następnie wykonaj reboot.

Prezentujemy kolejny wpis z serii Symfony2. Tym razem rozwiązujemy problem rozróżnienia adresów logowania w przypadku gdy chcemy umożliwić logowanie użytkownikom i administratorowi.

Zwykły użytkownik będzie logował się poprzez adres /login

Administrator będzie logował się poprzez adres /admin/login

Zaczynamy od konfiguracji w pliku security.yml .

Przykładowy plik konfiguracyjny powinien wyglądać w sposób następujący:


firewalls:
admin_login:
pattern: ^/admin/login$
anonymous: ~

login:
pattern: ^/login$
anonymous: ~

admin_secured_area:
pattern: ^/admin
form_login:
check_path: /admin/login_check
login_path: /admin/login
default_target_path: /admin
logout:
path: /admin/logout
target: /admin/login

secured_area:
pattern: ^/
form_login:
check_path: /login_check
login_path: /login
default_target_path: /
logout:
path: /logout
target: /login

access_control:
- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/admin/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/admin, roles: ROLE_ADMIN }
- { path: ^/, roles: ROLE_USER }


W naszym przypadku cały dostęp do strony wymaga podania hasła przez usera mającego uprawnienia użytkownika (ROLE_USER). W przypadku przejścia do panelu administratora wymagane są uprawnienia administratora (ROLE_ADMIN). Omówmy teraz po kolei definicje w pliku konfiguracyjnym.

firewall:admin_login oraz firewall:login definiują adresy wyświetlenia formularza logowania i jednocześnie udostępniają te adresy użytkownikom anonimowym.

admin_secured_area określa definicję adresów w przypadku których wymagane jest logowanie do panelu administracyjnego.

secured_area określa definicję adresów w przypadku których wymagane jest logowanie zwykłego użytkownika.

access_control określa warunki autentyfikacji użytkownika po przejściu przez firewall. Czyli w przypadku adresów logowania użytkownik nie musi posiadać żadnych uprawnień, jednak w przypadku wszystkich adresów rozpoczynających się od /admin musi mieć uprawnienia ROLE_ADMIN, a w przypadku pozostałych adresów ma to być ROLE_USER.

Ok, tyle jeżeli chodzi o konfigurację w security.yml . Teraz kolejna ważna rzecz – routing.

Przechodzimy do naszego pliku z konfiguracją routingu adresów logowania/wylogowania i definiujemy adresy wykorzystane w konfiguracji security.yml. W naszym przypadku plik taki wygląda w sposób następujący:

admin_login_check:
pattern: /admin/login_check
prefix: /admin
admin_login:
pattern: /admin/login
defaults: { _controller: LmSecurityBundle:Security:adminLogin }
admin_logout:
pattern: /admin/logout
prefix: /admin

login:
pattern: /login
defaults: { _controller: LmSecurityBundle:Security:login }
login_check:
pattern: /login_check
logout:
pattern: /logout

Definicje wyglądają w obu przypadkach w sposób podstawowy. Na wyróżnienie zasługuje zastosowanie definicji prefix. Jest ona tutaj kluczowa, ponieważ pomaga Symfony w przekierowaniu /admin/login_check na /login_check i umożliwia poprawne zalogowanie.

I to w zasadzie wszystko, z tymi informacjami można w sposób swobodny wybudować podział dostępu pomiędzy backend i frontend ( w definicji starego symfony 1.* )

Wraz z rozwojem aplikacji chcielibyśmy, aby pliku konfiguracyjne routingu odpowiedzialne za dostęp do bundle były przechowywane we właściwym bundle. Aby to osiągnąć trzeba dokonać kilku prostych modyfikacji.  Modyfikacji te analogicznie należy zastosować we wszystkich wykorzystywanych środowiskach.

Załóżmy, że chcemy wstępnie zastąpić plik routing.yml plikiem routing.php . Jak zrobić, aby Symfony zainteresowało się tym drugim?

Przechodzimy do konfiguracji app/config/config.yml i w sekcji framework zmieniamy

router:          { resource: “%kernel.root_dir%/config/routing.yml” }

na

router:          { resource: “%kernel.root_dir%/config/routing.php” }

Czyścimy cache i od teraz routing będzie pobierany z pliku routing.php .

Ale co wpisać w routing.php, aby pobierał on pliki yml z katalogów bundle? Oto przykładowy kod pliku:


use Symfony\Component\Routing\RouteCollection;

$collection = new RouteCollection();

$collection->addCollection($loader->import("@LmSecurityBundle/Resources/config/routing.yml"));
$collection->addCollection($loader->import("@LmUserBundle/Resources/config/routing.yml"));

return $collection;


Po zdefiniowaniu w ten sposób lokalizacji pliku yml będzie on pobierany i interpretowany. Dzięki czemu możemy jeszcze bardziej wykorzystać bundle jako niezależne paczki.

Należy pamiętać, aby w przypadku routing_dev.php poza lokalizacjami plików bundle dodać jeszcze :

$collection->addCollection($loader->import(”routing_dev.yml”));

Aby doczytywane były elementy typu pasek debug.

Oto kolejna krótka porada z cyklu Symfony2 i Twig.

Na pewno nie jeden raz trafi nam się sytuacja gdy będziemy chcieli skorzystać ze zmiennych przekazywanych poprzez GET/POST/URL .

Jak w Twig dostać się do tych zmiennych bez ich jawnego deklarowania w akcji?

To proste (aczkolwiek znowu próżno szukać tego w dokumentacji) – w szablonie korzystamy z wywołania:

app.request.attributes.get('nazwa_zmiennej_z_url')