-
Notifications
You must be signed in to change notification settings - Fork 109
Use tokenField from config if defined #376
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
Conversation
use tokenField from config if defined else IdentifierInterface::CREDENTIAL_JWT_SUBJECT
in conditions must be used dataField
src/Identifier/TokenIdentifier.php
Outdated
| $dataField = $this->getConfig('dataField'); | ||
| if (!isset($data[$dataField])) { | ||
| $tokenField = $this->getConfig('tokenField'); | ||
| if (!isset($data[$tokenField])) { | ||
| return null; | ||
| } | ||
|
|
||
| $conditions = [ | ||
| $this->getConfig('tokenField') => $data[$dataField], | ||
| $this->getConfig('dataField') => $data[$tokenField], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this change necessary? Unless I'm missing something, It just flips the config options, which breaks backwards compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right. I came out from this issue #353 (comment) I think data and token name is confusing. I expected that data is db field and token for token. But its other way arround. And also when you use custom token key name, here https://github.com/cakephp/authentication/pull/376/files/90a2daea03f470ef1294d9ac423bd42870a17ece#diff-b7a10d2c99be4b6528582b9471a0fb86R92 was fixed to 'sub' key name and because of that custom naming did not work and I did some debug. But now I see that naming is vice vera as I thought. But this https://github.com/cakephp/authentication/blob/master/src/Authenticator/JwtAuthenticator.php#L92 is still the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JwtAuthenticator should use JwtSubjectIdentifier, you don't need to mess around with the TokenIdentifier.
Scratch that, JwtSubjectIdentifier extends TokenIdentifier and just changes the default config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GrandFelix Switching the use of these config options would be a backwards compatibility break.
Since the issue is about making use of IdentifierInterface::CREDENTIAL_JWT_SUBJECT only JwtAuthenticator needs changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes... will fix that. thanks.
| $result = json_decode(json_encode($result), true); | ||
|
|
||
| $key = IdentifierInterface::CREDENTIAL_JWT_SUBJECT; | ||
| $key = $this->getConfig('tokenField', IdentifierInterface::CREDENTIAL_JWT_SUBJECT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ties into the question why the config options are being flipped in the identifier... Should this use dataField instead?
|
Walking through the The authenticator has The way the Returning the JWT claims as identity isn't the best default IMO. |
|
ok.. I have reverted almost everything except JwtAuthenticator $key definition. |
| $result = json_decode(json_encode($result), true); | ||
|
|
||
| $key = IdentifierInterface::CREDENTIAL_JWT_SUBJECT; | ||
| $key = $this->getConfig('dataField', IdentifierInterface::CREDENTIAL_JWT_SUBJECT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should add the new key in the default config array using the constant for it's default value. Also dataKey might be a better name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
renamed key var
|
|
||
| $key = IdentifierInterface::CREDENTIAL_JWT_SUBJECT; | ||
| if (empty($result[$key])) { | ||
| $dataKey = $this->getConfig('dataField'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was suggesting dataKey for the option name, not just the variable name 🙂.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pfff, ok. but this would break backward compatibility? IF anyone have already defined this with the default value of sub, when he will change the value this will not work anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't really understand what backwards compatibility concern you have. We are adding a new config, so whether it's named dataField or dataKey really doesn't matter.
That's said let's see if anyone else has other suggestions regarding the new key name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right. it looks its too much for today. I have looking at Authentication.JwtSubject config and have messed up. Yes, thats new config. The only concern that is is that all other components have dataField naming. If thats ok I can change to dataKey.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only concern that is is that all other components have dataField naming. If thats ok I can change to dataKey.
While naming consistency is important it should be contextual too. Personally I haven't seem the term "field" used in context of JWT. In JWT parlance the sub key is a "claim". So perhaps something more verbose like identityClaimKey might be ever better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. Maybe subjectClaimKey
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
claimKey or subjectKey are shorter names that are inline with other JWT jargon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to add a test for this configuration option to help prevent regressions in the future.
|
Looking good. Are you able to update the tests or do you need a hand with that? |
|
Targeting the PR to next minor would help document this new option better. |
fixed wrong used config fields in some places when using custom fields
use tokenField from config if defined else IdentifierInterface::CREDENTIAL_JWT_SUBJECT.
this fixes this #353 (comment)