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

[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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
fabpot merged 1 commit intosymfony:masterfromro0NL:patch-2
Jul 18, 2018
Merged

Conversation

@ro0NL
Copy link
Contributor

@ro0NLro0NL commentedJul 13, 2018
edited
Loading

QA
Branch?master
Bug fix?yes-ish
New feature?no
BC breaks?no
Deprecations?yes
Tests pass?yes
Fixed tickets#...
LicenseMIT
Doc PRsymfony/symfony-docs#...

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

sstok and Kocal reacted with heart emoji
@ro0NLro0NL changed the titleUpdate Security.php[Security] Check for UserInterface in Security::getUser()Jul 13, 2018
@chalasrchalasr added this to the3.4 milestoneJul 13, 2018
@chalasrchalasr requested a review fromweaverryanJuly 13, 2018 15:07
@ro0NL
Copy link
ContributorAuthor

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

@xabbuhxabbuh 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

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

@ro0NL
Copy link
ContributorAuthor

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
ContributorAuthor

ro0NL commentedJul 13, 2018
edited
Loading

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

+1 for a BC layer

@ro0NLro0NL changed the base branch from3.4 tomasterJuly 15, 2018 09:11
@ro0NLro0NL changed the title[Security] Check for UserInterface in Security::getUser()[Security] Deprecate returning stringish objects from Security::getUserJul 15, 2018
@ro0NL
Copy link
ContributorAuthor

Done.

}

if (!$userinstanceof 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

@weaverryanweaverryan 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 :)

}

if (!$userinstanceof 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

@xabbuhxabbuhJul 16, 2018
edited
Loading

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

I like the idea 👍

@fabpot
Copy link
Member

Thank you@ro0NL.

@fabpotfabpot merged commit8c410da intosymfony:masterJul 18, 2018
fabpot added a commit that referenced this pull requestJul 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
@ro0NLro0NL deleted the patch-2 branchJuly 18, 2018 05:07
This was referencedNov 3, 2018
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@xabbuhxabbuhxabbuh approved these changes

@fabpotfabpotfabpot approved these changes

@weaverryanweaverryanweaverryan approved these changes

@chalasrchalasrchalasr approved these changes

@dunglasdunglasAwaiting requested review from dunglas

@lyrixxlyrixxAwaiting requested review from lyrixx

@srozesrozeAwaiting requested review from sroze

Assignees

No one assigned

Projects

None yet

Milestone

3.4

Development

Successfully merging this pull request may close these issues.

8 participants

@ro0NL@stof@weaverryan@chalasr@lyrixx@fabpot@xabbuh@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp