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

Skip to content

[Security] Deprecate returning stringish objects from Security::getUser #27943

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
Jul 18, 2018
Merged

[Security] Deprecate returning stringish objects from Security::getUser #27943

merged 1 commit into from
Jul 18, 2018

Conversation

ro0NL
Copy link
Contributor

@ro0NL ro0NL commented Jul 13, 2018

Q A
Branch? master
Bug fix? yes-ish
New feature? no
BC breaks? no
Deprecations? yes
Tests pass? yes
Fixed tickets #...
License MIT
Doc PR symfony/symfony-docs#...

$user can also be an object implementing __ toString. Here we want only true user objects...

@ro0NL ro0NL changed the title Update Security.php [Security] Check for UserInterface in Security::getUser() Jul 13, 2018
@chalasr chalasr added this to the 3.4 milestone Jul 13, 2018
@chalasr chalasr requested a review from weaverryan July 13, 2018 15:07
@ro0NL
Copy link
Contributor Author

ro0NL commented Jul 13, 2018

Im also wondering if it's better to throw, rather then silently ignoring "non users" by returning null. To clarify the intend here.

Copy link
Member

@xabbuh xabbuh left a comment

Choose a reason for hiding this comment

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

a test would be nice

@stof
Copy link
Member

stof commented Jul 13, 2018

well, throwing for anonymous token would be a big BC break, and would make this API much less developer-friendly

@ro0NL
Copy link
Contributor Author

ro0NL commented Jul 13, 2018

You're right. On 2nd thought i think the null default is fine indeed. There's no UserInterface available which is what we asked for, but it doesn't mean you're "logged out" per se in case of null.

@weaverryan
Copy link
Member

I’m following the logic. But, was this to solve some specific issue?

It’s looks like a BC break to me, unfortunately.

@ro0NL
Copy link
Contributor Author

ro0NL commented Jul 13, 2018

We had some discussion on slack about the inconsistency between the documented @return and the actual return (any object). Basically it causes confusion about the intend...

But no real issue :) it will just crash if this class is (ever) updated to have type declarations (#27944). To me that smells a violation.

And yes, we can do an upgrade path with deprecations but i also think it qualifies a bugfix (otherwise the bugfix would be to update to @return object|null, which AFAIK was not the intend here ...)

@weaverryan
Copy link
Member

Bug fix: that’s a good argument for the behavior change. I’d still prefer a deprecation and a merge into 4.2... after all, the bug isn’t currently hurting any functionality. So, waiting until 4.2 does not cause any issues.

@chalasr
Copy link
Member

chalasr commented Jul 14, 2018

+1 for a BC layer

@ro0NL ro0NL requested review from dunglas, lyrixx and sroze as code owners July 15, 2018 09:10
@ro0NL ro0NL changed the base branch from 3.4 to master July 15, 2018 09:11
@ro0NL ro0NL changed the title [Security] Check for UserInterface in Security::getUser() [Security] Deprecate returning stringish objects from Security::getUser Jul 15, 2018
@ro0NL
Copy link
Contributor Author

ro0NL commented Jul 15, 2018

Done.

@@ -46,6 +46,11 @@ public function getUser()
return null;
}

if (!$user instanceof UserInterface) {
@trigger_error(sprintf('Accessing the user object "%s" that is not an instance of "%s" from "%s()" is deprecated since Symfony 4.2. Use "getToken()->getUser()" instead.', get_class($user), UserInterface::class, __METHOD__), E_USER_DEPRECATED);
Copy link
Member

Choose a reason for hiding this comment

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

...is deprecated since Symfony 4.2, use...

Copy link
Member

@weaverryan weaverryan left a comment

Choose a reason for hiding this comment

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

Changelog entries could use a period at the end, but just that nit pick :)

@@ -46,6 +46,11 @@ public function getUser()
return null;
}

if (!$user instanceof UserInterface) {
@trigger_error(sprintf('Accessing the user object "%s" that is not an instance of "%s" from "%s()" is deprecated since Symfony 4.2, use "getToken()->getUser()" instead.', get_class($user), UserInterface::class, __METHOD__), E_USER_DEPRECATED);
Copy link
Member

@xabbuh xabbuh Jul 16, 2018

Choose a reason for hiding this comment

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

$user may not be an object here: is_object($user) ? get_class($user) : $user

Ah no, we check that just before.

@lyrixx
Copy link
Member

lyrixx commented Jul 16, 2018

I like the idea 👍

@fabpot
Copy link
Member

fabpot commented Jul 18, 2018

Thank you @ro0NL.

@fabpot fabpot merged commit 8c410da into symfony:master Jul 18, 2018
fabpot added a commit that referenced this pull request Jul 18, 2018
…Security::getUser (ro0NL)

This PR was squashed before being merged into the 4.2-dev branch (closes #27943).

Discussion
----------

[Security] Deprecate returning stringish objects from Security::getUser

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yes-ish
| New feature?  | no
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | #...   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

`$user` can also be an object implementing `__ toString`. Here we want only true user objects...

Commits
-------

8c410da [Security] Deprecate returning stringish objects from Security::getUser
@ro0NL ro0NL deleted the patch-2 branch July 18, 2018 05:07
This was referenced Nov 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants