You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: readme.md
+15-19Lines changed: 15 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -61,7 +61,6 @@ $user->logout();
61
61
62
62
Simple, right?
63
63
64
-
.[note]
65
64
Logging in requires users to have cookies enabled - other methods are not safe!
66
65
67
66
Besides logging the user out with the `logout()` method, it can be done automatically based on specified time interval or closing the browser window. For this configuration we have to call `setExpiration()` during the login process. As an argument, it takes a relative time in seconds, UNIX timestamp, or textual representation of time.
Expiration must be set to value equal or lower than the expiration of [sessions].
76
+
Expiration must be set to value equal or lower than the expiration of sessions.
79
77
80
78
The reason of last logout can be obtained by method `$user->getLogoutReason()`, which returns one of these constants: `IUserStorage::INACTIVITY` if time expired or `IUserStorage::MANUAL` when the `logout()` method was called.
81
79
82
-
To make the example above work, we in fact have to create an object that verifies user's name and password. It's called **authenticator**. Its trivial implementation is the class [api:Nette\Security\SimpleAuthenticator], which in its constructor accepts an associative array:
80
+
To make the example above work, we in fact have to create an object that verifies user's name and password. It's called **authenticator**. Its trivial implementation is the class Nette\Security\SimpleAuthenticator, which in its constructor accepts an associative array:
83
81
84
82
```php
85
83
$authenticator = new Nette\Security\SimpleAuthenticator(array(
@@ -89,7 +87,7 @@ $authenticator = new Nette\Security\SimpleAuthenticator(array(
89
87
$user->setAuthenticator($authenticator);
90
88
```
91
89
92
-
If the login credentials are not valid, authenticator throws an [api:Nette\Security\AuthenticationException]:
90
+
If the login credentials are not valid, authenticator throws an Nette\Security\AuthenticationException:
93
91
94
92
```php
95
93
try {
@@ -103,22 +101,21 @@ try {
103
101
}
104
102
```
105
103
106
-
We usually configure authenticator inside a [config file |configuring], which only creates the object if it's requested by the application. The example above would be set in `config.neon` as follows:
104
+
We usually configure authenticator inside a config file, which only creates the object if it's requested by the application. The example above would be set in `config.neon` as follows:
We will create a custom authenticator that will check validity of login credentials against a database table. Every authenticator must be an implementation of [api:Nette\Security\IAuthenticator], with its only method `authenticate()`. Its only purpose is to return an [identity | #identity] or to throw an `Nette\Security\AuthenticationException`. Framework defines few error codes, that can be used to determine the reason login was not successful, such as self-explaining `IAuthenticator::IDENTITY_NOT_FOUND` or `IAuthenticator::INVALID_CREDENTIAL`.
118
+
We will create a custom authenticator that will check validity of login credentials against a database table. Every authenticator must be an implementation of Nette\Security\IAuthenticator, with its only method `authenticate()`. Its only purpose is to return an identity or to throw an `Nette\Security\AuthenticationException`. Framework defines few error codes, that can be used to determine the reason login was not successful, such as self-explaining `IAuthenticator::IDENTITY_NOT_FOUND` or `IAuthenticator::INVALID_CREDENTIAL`.
122
119
123
120
```php
124
121
use Nette\Security as NS;
@@ -151,7 +148,7 @@ class MyAuthenticator implements NS\IAuthenticator
151
148
}
152
149
```
153
150
154
-
Class `MyAuthenticator` communicates with the database using [Nette\Database |database]layer and works with table `users`, where it grabs `username` and hash of `password` in the appropriate columns. If the password check is successful, it returns new identity with user ID and role, which we will mention [later | #roles];
151
+
Class `MyAuthenticator` communicates with the database using Nette\Database layer and works with table `users`, where it grabs `username` and hash of `password` in the appropriate columns. If the password check is successful, it returns new identity with user ID and role, which we will mention later;
155
152
156
153
This authenticator would be configured in the `config.neon` file like this:
157
154
@@ -165,12 +162,12 @@ common:
165
162
Identity
166
163
--------
167
164
168
-
Identity presents a set of user information, as returned by autheticator. It's an object implementing [api:Nette\Security\IIdentity] interface, with default implementation [api:Nette\Security\Identity].
165
+
Identity presents a set of user information, as returned by autheticator. It's an object implementing Nette\Security\IIdentity interface, with default implementation Nette\Security\Identity.
169
166
Class has methods `getId()`, that returns users ID (for example primary key for the respective database row), and `getRoles()`, which returns an array of all roles user is in. User data can be access as if they were identity properties.
170
167
171
168
Identity is not erased when the user is logged out. So, if identity exists, it by itself does not grant that the user is also logged in. If we would like to explicitly delete the identity for some reason, we logout the user by calling `$user->logout(true)`.
172
169
173
-
Service `user` of class [api:Nette\Security\User] keeps the identity in session and uses it to all authorizations.
170
+
Service `user` of class Nette\Security\User keeps the identity in session and uses it to all authorizations.
174
171
Identity can be access with `getIdentity` upon `$user`:
175
172
176
173
```php
@@ -217,7 +214,7 @@ As you already know, logging user out does not erase his identity. Therefore the
217
214
Authorizator
218
215
------------
219
216
220
-
Authorizator decides, whether the user has permission to take some action. It's an implementation of [api:Nette\Security\IAuthorizator] interface with only one method `isAllowed()`. Purpose of this method is to determine, whether given role has the permission to perform certain *operation* with specific *resource*.
217
+
Authorizator decides, whether the user has permission to take some action. It's an implementation of Nette\Security\IAuthorizator interface with only one method `isAllowed()`. Purpose of this method is to determine, whether given role has the permission to perform certain *operation* with specific *resource*.
221
218
222
219
-**role** is a user attribute - for example moderator, editor, visitor, registered user, administrator, ...
223
220
-**resource** is a logical unit of the application - article, page, user, menu item, poll, presenter, ...
@@ -253,15 +250,14 @@ if ($user->isAllowed('file', 'delete')) { // is user allowed to delete a resourc
253
250
}
254
251
```
255
252
256
-
.[note]
257
253
Do not confuse two different methods `isAllowed`: one belongs to the authorizator and the other one to the `User` class, where first argument is not `$role`.
258
254
259
255
Because user may have many roles, he is granted the permission only if at least one of roles has the permission. Both arguments are optional and their default value is *everything*.
260
256
261
257
262
258
Permission ACL
263
259
--------------
264
-
Nette Framework has a complete authorizator, class [api:Nette\Security\Permission] which offers a light weight and flexible ACL((Access Control List)) layer for permission and access control. When we work with this class, we define roles, resources and individual privileges. Roles and resources may form hierarchies, as shown in the following example:
260
+
Nette Framework has a complete authorizator, class Nette\Security\Permission which offers a light weight and flexible ACL((Access Control List)) layer for permission and access control. When we work with this class, we define roles, resources and individual privileges. Roles and resources may form hierarchies, as shown in the following example:
265
261
266
262
-`guest`: visitor that is not logged in, allowed to read and browse public part of the web, ie. articles, comments, and to vote in a poll
0 commit comments