Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add claims in token interface #186

Closed
wants to merge 2 commits into from
Closed

Add claims in token interface #186

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fc3a1c2
Add claims to token interface
furdarius Jun 5, 2017
7ce8e05
Remove .idea from gitignore
furdarius Jun 6, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,3 +3,4 @@ phpunit.xml
composer.lock
humbuglog.txt
coverage
.idea
Copy link
Collaborator

Choose a reason for hiding this comment

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

This change shouldn't be here: please use a global .gitignore

Copy link
Author

Choose a reason for hiding this comment

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

Fixed

5 changes: 5 additions & 0 deletions src/Token.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,11 @@ interface Token
*/
public function headers(): DataSet;

/**
* Returns the token claims
*/
public function claims(): DataSet;
Copy link
Collaborator

Choose a reason for hiding this comment

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

@lcobucci I think this was initially excluded due to encrypted tokens?

Copy link
Owner

Choose a reason for hiding this comment

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

Indeed, it shouldn't be on the interface for that reason.

Copy link
Author

@furdarius furdarius Jun 6, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

You mean if JWE using, then it must be decrypted first? Or why claims must not be available? And how to get user information from token, if we have not claims?

Btw, if looks at claims method in Token\Plain class, it refer to inheritdoc which should be in TokenInterface: https://github.com/lcobucci/jwt/blob/master/src/Token/Plain.php#L63
But now you can't find this method in interface.

Copy link
Owner

Choose a reason for hiding this comment

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

You mean if JWE using, then it must be decrypted first? Or why claims must not be available? And how to get user information from token, if we have not claims?

@furdarius exactly, if you need to extract information from a nested token (and the information is "public") you can use the headers, otherwise you just decrypt it.

I didn't add that method to the interface because we have plans to support nested tokens in the near future, which means that claims are not available for that kind of token.

Btw, if looks at claims method in Token\Plain class, it refer to inheritdoc which should be in TokenInterface: https://github.com/lcobucci/jwt/blob/master/src/Token/Plain.php#L63
But now you can't find this method in interface.

Thanks for pointing that out 😉

Copy link
Author

Choose a reason for hiding this comment

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

@lcobucci Even if you are going to implement JWE functionality, i don't understand how are you think to get claims from JWT today and in future?

Copy link
Author

Choose a reason for hiding this comment

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

@Ocramius @lcobucci What you think about my previous question and about this PR?

Copy link
Owner

@lcobucci lcobucci Jun 8, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

@furdarius we need to bear in mind that we don't always have control over what is being sent to the parser, which means that you might receive from a client an encrypted token or a plain token. So, the parser might return either an encrypted token or a plain token.

It's up to us to check the type of token we're receiving and decide how they should be treated.

With that said, my opinion is that we shouldn't add that method to the interface (which was consciously bypassed so that we have forward compatibility). However, if you have any suggestion on how to achieve both things please let me know.

Copy link

Choose a reason for hiding this comment

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

@lcobucci well, we could add two interfaces PlainToken and EncryptedToken both extending Token and then add a public method claims() to PlainToken only. This solution is much cleaner in my opinion.

Copy link
Owner

Choose a reason for hiding this comment

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

@viteksafronov sorry for not getting back to you earlier. That's not ideal, I explained the reason also on #203


/**
* Returns if the token is allowed to be used by the audience
*/
Expand Down