Skip to content

Avoid toString in favor of getName in order to extract sid #6354

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

Closed
wants to merge 1 commit into from

Conversation

Atry
Copy link
Contributor

@Atry Atry commented Jan 7, 2019

There are some more sophisticated implementations of getName in AbstractAuthenticationToken, JwtAuthenticationToken and other Authentication classes.

There are some more sophisticated implementations of `getName` in `AbstractAuthenticationToken`  and other `Authentication` classes.
@Atry Atry changed the title Avoid toString in favor of getName for extract sid Avoid toString in favor of getName in order to extract sid Jan 7, 2019
@rwinch
Copy link
Member

rwinch commented Jan 7, 2019

Thanks for the PR! Can you please provide additional details on why you feel like this change is needed?

@rwinch rwinch added the status: waiting-for-feedback We need additional information before we can continue label Jan 7, 2019
@Atry
Copy link
Contributor Author

Atry commented Jan 8, 2019

When creating a resource server from spring-security-acl and spring-security-oauth2, you will have a JwtAuthenticationToken authentication, and by default store a sid of Jwt@12345678 in acl_sid table, which is a wrong behavior.

@Atry
Copy link
Contributor Author

Atry commented Jan 8, 2019

We have authentication.getPrincipal().toString(); for historical reason. The original code is written before the availability of getName, which is implemented since Spring Security 5.0.

@rwinch
Copy link
Member

rwinch commented Jan 8, 2019

Authentication has extended Principal and AbstractAuthentication has implemented getName since the Acegi days (i.e. Spring Security 1.0.x), so I don't think this is why it is implemented this way.

I think it does make sense to update the code as you suggested. However, I think we want a few changes:

  • Let's remove the UserDetails check since that is already done in AbstractAuthentication
  • Please add the necessary tests to ensure it works properly

@rwinch rwinch self-assigned this Jan 8, 2019
Copy link
Member

@rwinch rwinch left a comment

Choose a reason for hiding this comment

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

I see you pushed some changes. However, I don't see any tests or removal of the UserDetails bits above. Did something go wrong?

@Atry
Copy link
Contributor Author

Atry commented Jan 10, 2019 via email

@rwinch
Copy link
Member

rwinch commented Jan 14, 2019

Can you please add the requested changes?

@rwinch rwinch removed their assignment Jul 29, 2019
@eleftherias eleftherias self-assigned this Oct 15, 2019
@eleftherias
Copy link
Contributor

@Atry Can you please add the requested tests? They should check that the correct principal was set. They will be similar to the following tests.

assertThat("johndoe".equals(principalSid.getPrincipal())).isTrue();

@eleftherias
Copy link
Contributor

Merged via ea148d5.

@rwinch rwinch added in: acl An issue in spring-security-acl type: bug A general bug and removed status: waiting-for-feedback We need additional information before we can continue labels Dec 9, 2019
@rwinch rwinch added this to the 5.2.2 milestone Dec 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: acl An issue in spring-security-acl type: bug A general bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants