Add claims in token interface

[furdarius]

claims method was added in Token interface.
It's not available to use abstraction in auth library, because you need to get claims about user from parsed token for auth.

Signed-off-by: Artemiy Ryabinkov [email protected]

[Ocramius]

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

[furdarius]

Fixed

[Ocramius]

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

[lcobucci]

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

[furdarius]

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.

[lcobucci]

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 😉

[furdarius]

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

[furdarius]

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

[lcobucci]

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

[viteksafronov]

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

[lcobucci]

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

[lcobucci]

Based on what we discussed before I'll close this PR.