Konfiguracja kontroli dostępu
*****************************

.[perex]
Przegląd opcji konfiguracyjnych dla Nette Security.

Jeśli nie używasz całego frameworku, tylko tej biblioteki, przeczytaj, [jak wczytać konfigurację|bootstrap:].

W konfiguracji możesz zdefiniować listę użytkowników i utworzyć w ten sposób [prosty authenticator|authentication] (`Nette\Security\SimpleAuthenticator`). Ponieważ hasła podawane są w konfiguracji jawnym tekstem, to rozwiązanie nadaje się wyłącznie do celów testowych.

```neon
security:
	# pokazać panel użytkownika w Tracy Bar?
	debugger: ...  # (bool) domyślnie auto (włączone, gdy Tracy jest aktywne)

	users:
		# nazwa: hasło
		johndoe: 'secret123'

		# nazwa, hasło, role i inne dane dostępne w tożsamości
		janedoe:
			password: 'secret123'
			roles: [admin]
			data: ...
```

Zamiast hasła jawnym tekstem możesz podać jego [hash |passwords]; jest rozpoznawany automatycznie. Ponieważ zarówno hasła, jak i hashe mogą zawierać znaki o specjalnym znaczeniu w NEON, zalecamy zawsze zamykać je w cudzysłowach. .{data-version:3.2.6}

```neon
security:
	users:
		johndoe: '$2y$12$8aeofxuRALu4iNeaBHyLpuxf3xxKQdEreSaNLkQUiIfUmAv6cRHLa'
```

Poza tym możesz zdefiniować role i zasoby, tworząc podstawę dla [autoryzatora|authorization] (`Nette\Security\Permission`):

```neon
security:
	roles:
		guest:
		registered: [guest]  # registered dziedziczy po guest
		admin: [registered]  # a admin dziedziczy po registered

	resources:
		article:
		comment: [article]   # zasób dziedziczy po article
		poll:
```

I wreszcie reguły dostępu. Każda reguła to trójka roli, zasobu i uprawnienia; pominięta albo `null`owa pozycja oznacza "wszystko", a sam ciąg pozwala albo zabrania roli wszystkiego. .{data-version:3.2.6}

```neon
security:
	rules:
		allow:
			- [guest, article, view]              # rola, zasób, uprawnienie
			- [registered, comment, [add, edit]]  # lista oznacza wiele wartości
			- [admin]                             # admin może wszystko
		deny:
			- [banned, comment, add]
```

Jeśli potrzebujesz bardziej złożonych reguł, na przykład warunków weryfikowanych callbackiem (asercji), zarejestruj własny autoryzator, jak pokazuje [Autoryzacja |authorization]. Gdy to zrobisz, definiuj role, zasoby i reguły w tym autoryzatorze, a nie tutaj, inaczej skończysz z dwiema konkurującymi usługami `Nette\Security\Permission`.


Magazyn użytkownika
-------------------

Możesz skonfigurować, jak przechowywać informację o zalogowanym użytkowniku:

```neon
security:
	authentication:
		# czas nieaktywności, po którym użytkownik zostanie wylogowany
		expiration: 30 minutes        # (string) domyślnie nieustawione

		# gdzie przechowywać informację o zalogowanym użytkowniku
		storage: session              # (session|cookie) domyślnie session

		# zachować tożsamość dostępną po wylogowaniu i wygaśnięciu
		persistIdentity: true         # (bool) domyślnie true
```

Jeśli jako magazyn wybierzesz `cookie`, możesz ustawić także te opcje:

```neon
security:
	authentication:
		# nazwa cookie
		cookieName: userId            # (string) domyślnie userid

		# domeny, które mogą przyjąć cookie
		cookieDomain: 'example.com'   # (string|domain)

		# ograniczenie przy dostępie cross-origin
		cookieSamesite: None          # (Strict|Lax|None) domyślnie Lax
```


Usługi DI
---------

Do kontenera DI dodawane są te usługi:

| Nazwa                   | Typ                                | Opis
|-------------------------|------------------------------------|---------------------------
| `security.authenticator`| [api:Nette\Security\Authenticator] | [authenticator |authentication]
| `security.authorizator` | [api:Nette\Security\Authorizator]  | [autoryzator |authorization]
| `security.passwords`    | [api:Nette\Security\Passwords]     | [hashowanie haseł |passwords]
| `security.user`         | [api:Nette\Security\User]          | bieżący użytkownik
| `security.userStorage`  | [api:Nette\Security\UserStorage]   | [magazyn |#Magazyn użytkownika]