Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit6da1df6

Browse files
committed
[symfony#3357] Many many changes thanks to@wouterj and@xabbuh
1 parent110e22b commit6da1df6

File tree

4 files changed

+69
-64
lines changed

4 files changed

+69
-64
lines changed
Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
1-
After Symfony calls ``createToken``, it willthen call ``supportsToken`` on
2-
yourclass (and any other authentication listeners)to figure out who should
3-
handleit. Thisis just a wayto allow several authentication mechanismsto
4-
be usedfor the same firewall (that way, you canfor instance firsttryto
5-
authenticate the user via a certificateor an API keyand fall backto a
6-
form login).
1+
After Symfony calls ``createToken()``, it will then call ``supportsToken()``
2+
onyourclass (and any other authentication listeners) to figure out who should
3+
handlethe token. This is just a way to allow several authentication mechanisms
4+
tobe used for the same firewall (that way, you canfor instance firsttry
5+
toauthenticate the user via a certificateor an API keyand fall back to
6+
aform login).
77

88
Mostly, you just need to make sure that this method returns ``true`` for a
9-
token that has been created by ``createToken``. Your logic should probably
10-
look exactly like this example.
9+
token that has been created by ``createToken()``. Your logic should probably
10+
look exactly like this example.

‎cookbook/security/api_key_authentication.rst‎

Lines changed: 46 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ allows you to implement such a scheme really easily.
2020

2121
Your exact situation may differ, but in this example, a token is read
2222
from an ``apikey`` query parameter, the proper username is loaded from that
23-
value, and then a User object is created::
23+
value and then a User object is created::
2424

2525
// src/Acme/HelloBundle/Security/ApiKeyAuthenticator.php
2626
namespace Acme\HelloBundle\Security;
@@ -59,7 +59,9 @@ value, and then a User object is created::
5959
public function authenticateToken(TokenInterface $token, UserProviderInterface $userProvider, $providerKey)
6060
{
6161
$apiKey = $token->getCredentials();
62-
if (!$username = $this->userProvider->getUsernameForApiKey($apiKey)) {
62+
$username = $this->userProvider->getUsernameForApiKey($apiKey)
63+
64+
if (!$username) {
6365
throw new AuthenticationException(
6466
sprintf('API Key "%s" does not exist.', $apiKey)
6567
);
@@ -91,10 +93,10 @@ probably differ:
9193
1. createToken
9294
~~~~~~~~~~~~~~
9395

94-
Early in the request cycle, Symfony calls ``createToken``. Your job here
96+
Early in the request cycle, Symfony calls ``createToken()``. Your job here
9597
is to create a token object that contains all of the information from the
9698
request that you need to authenticate the user (e.g. the ``apikey`` query
97-
parameter). If that information is missing, throwingthe
99+
parameter). If that information is missing, throwinga
98100
:class:`Symfony\\Component\\Security\\Core\\Exception\\BadCredentialsException`
99101
will cause authentication to fail.
100102

@@ -106,11 +108,11 @@ will cause authentication to fail.
106108
3. authenticateToken
107109
~~~~~~~~~~~~~~~~~~~~
108110

109-
If ``supportsToken`` returns ``true``, Symfony will now call ``authenticateToken``.
111+
If ``supportsToken()`` returns ``true``, Symfony will now call ``authenticateToken()``.
110112
One key part is the ``$userProvider``, which is an external class that helps
111113
you load information about the user. You'll learn more about this next.
112114

113-
In this specific example, the following things happen in ``authenticateToken``:
115+
In this specific example, the following things happen in ``authenticateToken()``:
114116

115117
#. First, you use the ``$userProvider`` to somehow look up the ``$username`` that
116118
corresponds to the ``$apiKey``;
@@ -119,18 +121,18 @@ In this specific example, the following things happen in ``authenticateToken``:
119121
#. Finally, you create an *authenticated token* (i.e. a token with at least one
120122
role) that has the proper roles and the User object attached to it.
121123

122-
The goal is ultimately to use the ``$apiKey`` to find or create a User object.
123-
*How* you do this (e.g. query a database) and the exact class for your User
124-
object may vary. Those differences will be most obvious in your user provider.
124+
The goal is ultimately to use the ``$apiKey`` to find or create a ``User``
125+
object. *How* you do this (e.g. query a database) and the exact class for
126+
your ``User`` object may vary. Those differences will be most obvious in your
127+
user provider.
125128

126129
The User Provider
127130
~~~~~~~~~~~~~~~~~
128131

129-
The ``$userProvider`` can be any user provider (see
130-
:doc:`how to create a custom user provider</cookbook/security/custom_provider>`).
132+
The ``$userProvider`` can be any user provider (see:doc:`/cookbook/security/custom_provider`).
131133
In this example, the ``$apiKey`` is used to somehow find the username for
132-
the user. This work is done in a ``getUsernameForApiKey`` method, which is
133-
created entirely custom forour use-case (i.e. this isn't a method that's
134+
the user. This work is done in a ``getUsernameForApiKey()`` method, which
135+
iscreated entirely custom forthis use-case (i.e. this isn't a method that's
134136
used by Symfony's core user provider system).
135137

136138
The ``$userProvider`` might look something like this::
@@ -140,14 +142,16 @@ The ``$userProvider`` might look something like this::
140142

141143
use Symfony\Component\Security\Core\User\UserProviderInterface;
142144
use Symfony\Component\Security\Core\User\User;
145+
use Symfony\Component\Security\Core\User\UserInterface;
146+
use Symfony\Component\Security\Core\Exception\UnsupportedUserException;
143147

144148
class ApiKeyUserProvider extends UserProviderInterface
145149
{
146150
public function getUsernameForApiKey($apiKey)
147151
{
148152
// Look up the username based on the token in the database, via
149153
// an API call, or do something entirely different
150-
$username =//...
154+
$username = ...;
151155

152156
return $username;
153157
}
@@ -174,7 +178,7 @@ The ``$userProvider`` might look something like this::
174178

175179
public function supportsClass($class)
176180
{
177-
return$class ==='Symfony\Component\Security\Core\User\User';
181+
return 'Symfony\Component\Security\Core\User\User' === $class;
178182
}
179183
}
180184

@@ -183,23 +187,23 @@ The ``$userProvider`` might look something like this::
183187
Read the dedicated article to learn
184188
:doc:`how to create a custom user provider</cookbook/security/custom_provider>`.
185189

186-
The logic inside ``getUsernameForApiKey`` is up to you. You may somehow transform
190+
The logic inside ``getUsernameForApiKey()`` is up to you. You may somehow transform
187191
the API key (e.g. ``37b51d``) into a username (e.g. ``jondoe``) by looking
188192
up some information in a "token" database table.
189193

190-
The same is true for ``loadUserByUsername``. In this example, Symfony's core
194+
The same is true for ``loadUserByUsername()``. In this example, Symfony's core
191195
:class:`Symfony\\Component\\Security\\Core\\User\\User` class is simply created.
192196
This makes sense if you don't need to store any extra information on your
193197
User object (e.g. ``firstName``). But if you do, you may instead have your *own*
194198
user class which you create and populate here by querying a database. This
195-
would allow you to have custom data on the User object.
199+
would allow you to have custom data on the``User`` object.
196200

197-
Finally, just make sure that ``supportsClass``return ``true`` for User
198-
objects with the same class as whatever user you return in ``loadUserByUsername``.
201+
Finally, just make sure that ``supportsClass()``returns ``true`` for User
202+
objects with the same class as whatever user you return in ``loadUserByUsername()``.
199203
If your authentication is stateless like in this example (i.e. you expect
200204
the user to send the API key with every request and so you don't save the
201205
login to the session), then you can simply throw the ``UnsupportedUserException``
202-
exception in ``refreshUser``.
206+
exception in ``refreshUser()``.
203207

204208
..note::
205209

@@ -212,9 +216,10 @@ Configuration
212216
-------------
213217

214218
Once you have your ``ApiKeyAuthentication`` all setup, you need to register
215-
it as a service and use it in ``security.yml``. First, register it as a service.
216-
This assumes that you have already setup your custom user provider as a service
217-
called ``your_api_key_user_provider`` (see:doc:`/cookbook/security/custom_provider`).
219+
it as a service and use it in your security configuration (e.g. ``security.yml``).
220+
First, register it as a service. This assumes that you have already setup
221+
your custom user provider as a service called ``your_api_key_user_provider``
222+
(see:doc:`/cookbook/security/custom_provider`).
218223

219224
..configuration-block::
220225

@@ -260,8 +265,8 @@ called ``your_api_key_user_provider`` (see :doc:`/cookbook/security/custom_provi
260265
array(new Reference('your_api_key_user_provider'))
261266
));
262267
263-
Now, activate it in the ``firewalls`` section of``security.yml`` using the
264-
``simple_preauth`` key:
268+
Now, activate it in the ``firewalls`` section ofyoursecurity configuration
269+
using the``simple_preauth`` key:
265270

266271
..configuration-block::
267272

@@ -395,32 +400,31 @@ configuration or set it to ``false``:
395400
Storing authentication information in the session works like this:
396401

397402
#. At the end of each request, Symfony serializes the token object (returned
398-
from ``authenticateToken``), which also serializes the User object (since
399-
it's set on a property on the token);
400-
#. On the next request the token is deserialized and the deserialized User
401-
object is passed to the ``refreshUser`` function of the user provider.
403+
from ``authenticateToken()``), which also serializes the``User`` object
404+
(sinceit's set on a property on the token);
405+
#. On the next request the token is deserialized and the deserialized``User``
406+
object is passed to the ``refreshUser()`` function of the user provider.
402407

403-
The second step is the important one: Symfony calls ``refreshUser`` and passes
408+
The second step is the important one: Symfony calls ``refreshUser()`` and passes
404409
you the user object that was serialized in the session. If your users are
405410
stored in the database, then you may want to re-query for a fresh version
406411
of the user to make sure it's not out-of-date. But regardless of your requirements,
407-
``refreshUser`` should now return the User object::
412+
``refreshUser()`` should now return the User object::
408413

409414
// src/Acme/HelloBundle/Security/ApiKeyUserProvider.php
410415

411416
// ...
412-
413417
class ApiKeyUserProvider extends UserProviderInterface
414418
{
415419
// ...
416420

417421
public function refreshUser(UserInterface $user)
418422
{
419-
// $user is the User that you set in the token inside authenticateToken
423+
// $user is the User that you set in the token inside authenticateToken()
420424
// after it has been deserialized from the session
421425

422426
// you might use $user to query the database for a fresh user
423-
$id = $user->getId();
427+
//$id = $user->getId();
424428
// use $id to make a query
425429

426430
// if you are *not* reading from a database and are just creating
@@ -431,12 +435,12 @@ of the user to make sure it's not out-of-date. But regardless of your requiremen
431435

432436
..note::
433437

434-
You'll also want to make sure that your User object is being serialized
435-
correctly. If your User object has private properties, PHP can't serialize
438+
You'll also want to make sure that your``User`` object is being serialized
439+
correctly. If your``User`` object has private properties, PHP can't serialize
436440
those. In this case, you may get back a User object that has a ``null``
437441
value for each property. For an example, see:doc:`/cookbook/security/entity_provider`.
438442

439-
Only Authenticating forcertain URLs
443+
Only Authenticating forCertain URLs
440444
------------------------------------
441445

442446
This entry has assumed that you want to look for the ``apikey`` authentication
@@ -445,12 +449,13 @@ really need to look for authentication information once the user has reached
445449
a certain URL (e.g. the redirect URL in OAuth).
446450

447451
Fortunately, handling this situation is easy: just check to see what the
448-
current URL is before creating the token in ``createToken``::
452+
current URL is before creating the token in ``createToken()``::
449453

450454
// src/Acme/HelloBundle/Security/ApiKeyAuthenticator.php
451455

452456
// ...
453457
use Symfony\Component\Security\Http\HttpUtils;
458+
use Symfony\Component\HttpFoundation\Request;
454459

455460
class ApiKeyAuthenticator implements SimplePreAuthenticatorInterface
456461
{
@@ -477,8 +482,8 @@ current URL is before creating the token in ``createToken``::
477482
}
478483
}
479484

480-
This usesa handy:class:`Symfony\\Component\\Security\\Http\\HttpUtils`
481-
class tosee if the current URL matches the URL you're looking for. In this
485+
This usesthe handy:class:`Symfony\\Component\\Security\\Http\\HttpUtils`
486+
class tocheck if the current URL matches the URL you're looking for. In this
482487
case, the URL (``/login/check``) has been hardcoded in the class, but you
483488
could also inject it as the third constructor argument.
484489

‎cookbook/security/custom_authentication_provider.rst‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ How to create a custom Authentication Provider
88

99
Creating a custom authentication system is hard, and this entry will walk
1010
you through that process. But depending on your needs, you may be able
11-
tousesolve your problem in a simpler way using these documents:
11+
to solve your problem in a simpler way using these documents:
1212

1313
*:doc:`/cookbook/security/custom_password_authenticator`
1414
*:doc:`/cookbook/security/api_key_authentication`

‎cookbook/security/custom_password_authenticator.rst‎

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
..index::
22
single: Security; Custom Password Authenticator
33

4-
How tocreate a Custom Form Password Authenticator
4+
How toCreate a Custom Form Password Authenticator
55
==================================================
66

77
Imagine you want to allow access to your website only between 2pm and 4pm
@@ -97,12 +97,12 @@ But first, you can find out more about what each method in this class does.
9797
1) createToken
9898
~~~~~~~~~~~~~~
9999

100-
When Symfony begins handling a request, ``createToken`` is called, where
100+
When Symfony begins handling a request, ``createToken()`` is called, where
101101
you create a:class:`Symfony\\Component\\Security\\Core\\Authentication\\Token\\TokenInterface`
102-
object that contains whatever information you need in ``authenticateToken``
102+
object that contains whatever information you need in ``authenticateToken()``
103103
to authenticate the user (e.g. the username and password).
104104

105-
Whatever token object you create here will be passed to you later in ``authenticateToken``.
105+
Whatever token object you create here will be passed to you later in ``authenticateToken()``.
106106

107107
2) supportsToken
108108
~~~~~~~~~~~~~~~~
@@ -112,20 +112,20 @@ Whatever token object you create here will be passed to you later in ``authentic
112112
3) authenticateToken
113113
~~~~~~~~~~~~~~~~~~~~
114114

115-
If ``supportsToken`` returns ``true``, Symfony will now call ``authenticateToken``.
116-
Your job here is tochecks that the token is allowed to log in by first
117-
getting the User object via the user provider and then, by checking the password
115+
If ``supportsToken`` returns ``true``, Symfony will now call ``authenticateToken()``.
116+
Your job here is tocheck that the token is allowed to log in by first
117+
getting the``User`` object via the user provider and then, by checking the password
118118
and the current time.
119119

120120
..note::
121121

122-
The "flow" of how you get the User object and determine whether or not
122+
The "flow" of how you get the``User`` object and determine whether or not
123123
the token is valid (e.g. checking the password), may vary based on your
124124
requirements.
125125

126126
Ultimately, your job is to return a *new* token object that is "authenticated"
127-
(i.e. it has at least 1 role set on it) and which has the User object inside
128-
of it.
127+
(i.e. it has at least 1 role set on it) and which has the``User`` object
128+
insideof it.
129129

130130
Inside this method, an encoder is needed to check the password's validity::
131131

@@ -137,8 +137,8 @@ Inside this method, an encoder is needed to check the password's validity::
137137
);
138138

139139
This is a service that is already available in Symfony and the password algorithm
140-
is configured in``security.yml`` under the ``encoders`` key. Below, you'll
141-
see how to inject that into the ``TimeAuthenticator``.
140+
is configured inthesecurity configuration (e.g. ``security.yml``) under
141+
the ``encoders`` key. Below, you'llsee how to inject that into the ``TimeAuthenticator``.
142142

143143
.. _cookbook-security-password-authenticator-config:
144144

@@ -191,8 +191,8 @@ Now, configure your ``TimeAuthenticator`` as a service:
191191
array(new Reference('security.encoder_factory'))
192192
));
193193
194-
Then, activate it in the ``firewalls`` section of``security.yml`` using
195-
the ``simple_form`` key:
194+
Then, activate it in the ``firewalls`` section ofthesecurity configuration
195+
usingthe ``simple_form`` key:
196196

197197
..configuration-block::
198198

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp