Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Security] added SecurityContextInterface::getUser() #2816

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 8, 2011
Merged

[Security] added SecurityContextInterface::getUser() #2816

merged 1 commit into from
Dec 8, 2011

Conversation

kriswallsmith
Copy link
Contributor

This changes helps the common use case of fetching the current user and better complies with the Law of Demeter.

Before (still works):

$token = $context->getToken();
$user = $token ? $token->getUser() : null;

After:

$user = $context->getUser();

The fine print:

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~

This changes helps the common use case of fetching the current user and better complies with the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter).

Before (still works):

    $token = $context->getToken();
    $user = $token ? $token->getUser() : null;

After:

    $user = $context->getUser();
/**
* Returns the current user, if one exists.
*
* @return mixed Returns either an object which implements __toString(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or the most common case: an object implementing the UserInterface (which does not enforce the __toString method anymore)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just copied this comment from elsewhere.

On Dec 8, 2011, at 8:58 AM, Christophe Coevoet
[email protected]
wrote:

@@ -89,4 +89,18 @@ public function setToken(TokenInterface $token = null)
{
$this->token = $token;
}
+

  • /**
  • \* Returns the current user, if one exists.
    
  • *
    
  • \* @return mixed Returns either an object which implements __toString(),
    

or the most common case: an object implementing the UserInterface (which does not enforce the __toString method anymore)


Reply to this email directly or view it on GitHub:
https://github.com/symfony/symfony/pull/2816/files#r280409

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then this place is outdated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stof: a plain string is still possible for the user correct? UserInterface is just the only object alloewd?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, they are allowed. this is done for anonymous ones for instance. Both described solutions described in the phpdoc here are right but the third one (and most common) is missing

objects with a __toString method can still be used in the token too. But this can only be used with some weird way to get the user. An implementation of UserProviderInterface must return an instance of UserInterface.

fabpot added a commit that referenced this pull request Dec 8, 2011
Commits
-------

41872cd [Security] added SecurityContextInterface::getUser()

Discussion
----------

[Security] added SecurityContextInterface::getUser()

This changes helps the common use case of fetching the current user and better complies with the [Law of Demeter][1].

Before (still works):

    $token = $context->getToken();
    $user = $token ? $token->getUser() : null;

After:

    $user = $context->getUser();

The fine print:

```
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
```

[1]: http://en.wikipedia.org/wiki/Law_of_Demeter
@fabpot fabpot merged commit 41872cd into symfony:master Dec 8, 2011
@schmittjoh
Copy link
Contributor

Such a method is better implemented in your application where you can make more assumptions about the user. This general method will result in the same bug reports (especially for anonymous users) that we had before I deliberately removed it. Clear -1 from my POV.

@jmikola
Copy link
Contributor

jmikola commented Dec 10, 2011

@schmittjoh brings up a good point here about anonymous users being returned. I remember now why it was removed in the first place.

A small cookbook article could explain to users how to plug in their own SecurityContext with such a method implemented based on their specific needs.

@stof
Copy link
Member

stof commented Dec 10, 2011

btw, in the master branch, there is now a getUser shortcut in the base controller to make it easier for people using it to access the user.

@kriswallsmith
Copy link
Contributor Author

I'm not sure what to say… not building one part of the system properly
because we assume users won't understand another part of the system
suggests a flaw in the design. I don't know what the right answer is,
so I opted for consistency here.

On Dec 10, 2011, at 12:39 PM, Christophe Coevoet
[email protected]
wrote:

btw, in the master branch, there is now a getUser shortcut in the base controller to make it easier for people using it to access the user.


Reply to this email directly or view it on GitHub:
#2816 (comment)

@schmittjoh
Copy link
Contributor

I don't understand your message. Which parts are you referring to? What
inconsistency did this fix?

I have a similar method in my application, but the implementation is
slightly different (and much more useful) than your general implementation.
I also don't think that it belongs to the interface, and with regards to
the Law Of Demeter that you mentioned, your patched has increased coupling
of the objects instead of reducing it (the SecurityContext wasn't aware of
users before, now it is).

For reference, I'm using this implementation:

    /**
     * @return User|null
     */
    public function getUser()
    {
        if (null === $token = $this->getToken()) {
            return null;
        }
        $user = $token->getUser();

        return $user instanceof User ? $user : null;
    }

On Sat, Dec 10, 2011 at 10:03 PM, Kris Wallsmith <
[email protected]

wrote:

I'm not sure what to say not building one part of the system properly
because we assume users won't understand another part of the system
suggests a flaw in the design. I don't know what the right answer is,
so I opted for consistency here.

On Dec 10, 2011, at 12:39 PM, Christophe Coevoet
[email protected]
wrote:

btw, in the master branch, there is now a getUser shortcut in the
base controller to make it easier for people using it to access the user.


Reply to this email directly or view it on GitHub:
#2816 (comment)


Reply to this email directly or view it on GitHub:
#2816 (comment)

fabpot added a commit that referenced this pull request Dec 30, 2011
@fabpot
Copy link
Member

fabpot commented Dec 30, 2011

Based on the feedback, I have reverted this PR and made the Controller::getUser() method implementation similar to the one in GlobalVariables::getUser() (see eef8a3c). So, in a controller or in a template, the developer has an easy access to the user object.

@fabpot
Copy link
Member

fabpot commented Dec 30, 2011

revert is here: a78437b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants