Relationship with old plugin?

Hi @dominic_ks , thanks for your questions.

Am I right in assuming you have forked this and progressed the development?
This plugin was based on that great plugin :). Although the codebase is quite different now, the flow is similar.
– Some issues have been fixed in this plugin. And many of the PR on that plugin has been implemented in this plugin.
– More filters added

> If so, do you know if you can switch straight from one to another?
Maybe not. But migrating shouldn’t be hard. There are some small differences in the responses like:
– Default success response’s data when you request to generate a token
– Please check again the responses in the readme, to make sure if they are compatible with your existing app.

Lastly, do you have any plans for introducing functionality to allow users to manage existing tokens and choosing to manually expire them? i.e. Log me out everywhere or Log me out from my iPhone type abilities?
Please correct me. I think this feature needs the tokens to be saved in database. So beside the jwt-auth checking, we also need to check the token in DB. This way, we can “log out from everywhere” or “log out from specific device”. Is this correct?

If that is the case, i think it needs to be a separate plugin :D.
I’m happy and open to contribution via GitHub ??

Best regards,
Bagus

Hi @dominic_ks ,
thanks for your questions. (i have replied but the previous one has been held for moderation)

Am I right in assuming you have forked this and progressed the development?
This plugin was based on that great plugin :). Although the codebase is quite different now, the flow is similar.
– Some issues have been fixed in this plugin. And many of the PR on that plugin has been implemented in this plugin.
– More filters added

> If so, do you know if you can switch straight from one to another?
Maybe not. But migrating shouldn’t be hard. There are some small differences in the responses like:
– Default success response’s data when you request to generate a token
– Please check again the responses in the readme, to make sure if they are compatible with your existing app.

Lastly, do you have any plans for introducing functionality to allow users to manage existing tokens and choosing to manually expire them? i.e. Log me out everywhere or Log me out from my iPhone type abilities?
Please correct me. I think this feature needs the tokens to be saved in database. So beside the jwt-auth checking, we also need to check the token in DB. This way, we can “log out from everywhere” or “log out from specific device”. Is this correct?

If that is the case, i think it needs to be a separate plugin :D.
I’m happy and open to contribution via GitHub ??

Best regards,
Bagus

Hey,

Thanks for getting back to me. I think I’ll be looking to switch over to this plugin as the old one doesn’t seem to be being maintained any more.

On the last point re: storing tokens & logging out, yes something would need to be stored, though, I had wondered if, rather than storing the token itself, perhaps the object used to generate the token could also store some other ID, perhaps a user meta ID to reference in the database, and the meta value could contain some info about the device it’s related to; user agent, first login, last login for example.

Seems more secure than storing the entire token that could potentially be stolen.

This would need to be checked when validating an existing token and could be removed (or have it’s status updated if you wanted to keep a record) individually when logging out of an specific device or remove / updated en masse if logging out everywhere.

Any reason why you think this should be a different plugin? Feels to me like it fits quite nicely with the functionality already here?

Cheers,
Dominic,

Thanks for the explanation @dominic_ks ??

The reason might be: How about existing users that already installed this plugin? Currently their auth method is simply by checking against Authorization Header.

Cheers,
Bagus

Yes that’s a point that would need consideration, but you could easily just simply choose to continue to allow those tokens until they expire, i.e. if they don’t have the new ID, don’t check them, or you could allow an option to automatically invalidate all existing sessions to force users onto the new ones.

If you’re not keen it’s your choice and I’ll just need to see how I can develop this as an add-on later.

Cheers,

Does this feature could be achieved using the filter jwt_auth_payload?
So you can check the parameter with the filter jwt_auth_valid_token_response:

add_filter( 'jwt_auth_valid_token_response', function($response, $user, $token, $payload){
	
	if($payload->data->user->device != 'what you want to check'){					
		return new WP_REST_Response(
			array(
				'success'    => false,
				'statusCode' => 403,
				'code'       => 'jwt_auth_token_deprecated',
				'message'    => __( "The token is deprecated", 'jwt-auth' ),
				'data'       => array(),
			)
		);					
	}
	
	return $response;
});

This make sense?

• This reply was modified 4 years, 3 months ago by pesseba.

What is the “device” property you are checking for there? And presumably it’d need to be set when the token is generated in order to be checked later?

@contactjavas – I still am happy to come back to this and contribute a solution for this to the plugin if you are open to it? Especially if it’s on GitHub and I can do it as part of Hacktoberfest!

Hi @dominic_ks , i’m open to this feature. It would be awesome if you have time to contribute in GitHub.
But before this feature, there is refresh token feature needs to work on.

Hi @dominic_ks , I forgot to mention about the parameter ‘device ‘. It was added in jwt_auth_payload filter. So, I think the device information must be sent in wp-auth/token request. Could be a thrird optional parameter called device, together login and password. This value can be stored in user meta.
I think the user password (md5 hash) must be used in token generation too, so if user changes the passord, the token becomes obsolete too.
Hi @contactjavas I can contribute in GitHub too.

Hi @dominic_ks and @contactjavas, I created the ‘connected device’ feature in this pull request: https://github.com/usefulteam/jwt-auth/pull/10

This feature is optional. The system behave like before if the parameter is not present. It just save a meta value for user about the device key and add it in jwt token.
The devices shows up in user profile like this: https://tiny.cc/zakqsz

I added another feature too:
If user changes the password, all tokens becomes obsolete. The user password is not used in token generation.

Please @contactjavas, check if the pull request is ok.

Hi! I think this issue can be closed right? ?? Since you both of you are in GitHub too

Yes I think so!