Generating many client tokens

[npearson72]

I apologize for the cross-post, but I'm not sure if the problem I'm experiencing is related to this gem or it's angular library counterpart (or my improper implementation), but I've posted my issue here also:

lynndylanhurley/ng-token-auth#140

What I'm seeing is that when I close the browser while logged in, and I then open the browser and log back into my app, it generates a new client token.

This causes many client tokens to be generated.

Is anyone else experiencing something like this? Any ideas on how to prevent this?

[c0mrade]

Did you try this in your initializer :

DeviseTokenAuth.setup do |config|
  config.change_headers_on_each_request = false
end

[qx]

SQL (0.5ms) UPDATE "users" SET "tokens" = $1, "updated_at" = $2 WHERE "users"."id" = $3 [["tokens", "{"Q4g1PZrCdBb18Ndxxli55A":{"token":"$2a$10$7BLPPqKnPCNiBZ.O8uWIkOELtUak88RO9lFhIKdex7AjI2RqrsH7K","expiry":1433030748},"EwsS1phl1A9_plCI02eB7w":{"token":"$2a$10$5xgFolVXRhtzYKKE2lIccO2ytgc65gVQN74JS2hYBUw72.bZgW7vS","expiry":1433030766},"93fuGltfv8LO3-2_g3RF2Q":{"token":"$2a$10$qD4NdH0yaLA4AXORuCZ59eyHzyL/bqKKvDjjKlvN3iMbw.rGZKbhO","expiry":1433030814},"8_SQvQe5zq-ICJa1e-biYw":{"token":"$2a$10$DqlURiArR8n.L6Xrv3bs2.fIj/WYqdhU3UsUCKaca6VK8HhijfnSa","expiry":1433030826},"oCThb8B-epVt5A2aOWKStA":{"token":"$2a$10$FaqquEXhCy5dxaGUFdxnxOHdIp5mqvJgKbaYpXUw/j5ptVXmAd7XG","expiry":1433030837},"OlQ-X6i5wXbTGHHgj5ceuw":{"token":"$2a$10$FjMZg4GykcJUVxqAv4FayuaLsul5cgljmEkAgDja6UKlpvDWP0jMG","expiry":1433030858},"DUqK_RA5dGLVq-cRY1Dnhg":{"token":"$2a$10$MA9SWeut0G1pBK6jwAfRTevwES/uh.tsh5gdQFof0b2sHuvcAKfu6","expiry":1433030870},"eY5gn1JuHfle4bI8wOddyQ":{"token":"$2a$10$qshqJ2s2PdSdD2JstZtq.uBckvOLhOnqlwRdWXobXENMN.yS6bkjK","expiry":1433031039,"last_token":"$2a$10$INZb8EVrslHc/af4W6UoSuR83yKpcdmEqkEWb5CN04v96RGgupRXW","updated_at":"2015-05-17T08:10:39.643+08:00"}}"], ["updated_at", "2015-05-17 00:10:39.646659"], ["id", 1]]

Stil have so many tokens while sign in.

[nicolas-besnard]

Well, I can see many implementation to solve this:

1. We can LIMIT the number of token generated by adding a created_at , near
   the expiry key. When we reach the limit, we delete the last one used.
2. we need to understand WHY the creator of this gem has implemented a
   c"lient_id". When many others just use a single token. What issue solve the
   use of the "client_id" ?
   On Sun 17 May 2015 at 02:11 qx [email protected] wrote:

SQL (0.5ms) UPDATE "users" SET "tokens" = $1, "updated_at" = $2 WHERE
"users"."id" = $3 [["tokens",
"{"Q4g1PZrCdBb18Ndxxli55A":{"token":"$2a$10$7BLPPqKnPCNiBZ.O8uWIkOELtUak88RO9lFhIKdex7AjI2RqrsH7K","expiry":1433030748},"EwsS1phl1A9_plCI02eB7w":{"token":"$2a$10$5xgFolVXRhtzYKKE2lIccO2ytgc65gVQN74JS2hYBUw72.bZgW7vS","expiry":1433030766},"93fuGltfv8LO3-2_g3RF2Q":{"token":"$2a$10$qD4NdH0yaLA4AXORuCZ59eyHzyL/bqKKvDjjKlvN3iMbw.rGZKbhO","expiry":1433030814},"8_SQvQe5zq-ICJa1e-biYw":{"token":"$2a$10$DqlURiArR8n.L6Xrv3bs2.fIj/WYqdhU3UsUCKaca6VK8HhijfnSa","expiry":1433030826},"oCThb8B-epVt5A2aOWKStA":{"token":"$2a$10$FaqquEXhCy5dxaGUFdxnxOHdIp5mqvJgKbaYpXUw/j5ptVXmAd7XG","expiry":1433030837},"OlQ-X6i5wXbTGHHgj5ceuw":{"token":"$2a$10$FjMZg4GykcJUVxqAv4FayuaLsul5cgljmEkAgDja6UKlpvDWP0jMG","expiry":1433030858},"DUqK_RA5dGLVq-cRY1Dnhg":{"token":"$2a$10$MA9SWeut0G1pBK6jwAfRTevwES/uh.tsh5gdQFof0b2sHuvcAKfu6","expiry":1433030870},"eY5gn1J
uHfle4bI8wOddyQ":{"token":"$2a$10$qshqJ2s2PdSdD2JstZtq.uBckvOLhOnqlwRdWXobXENMN.yS6bkjK","expiry":1433031039,"last_token":"$2a$10$INZb8EVrslHc/af4W6UoSuR83yKpcdmEqkEWb5CN04v96RGgupRXW","updated_at":"2015-05-17T08:10:39.643+08:00"}}"],
["updated_at", "2015-05-17 00:10:39.646659"], ["id", 1]]

Stil have so many tokens while sign in.

—
Reply to this email directly or view it on GitHub
#210 (comment)
.

[lynndylanhurley]

The client_id is used so that users can authenticate with multiple browsers using different tokens. For example, you can maintain a session on your phone while still signed in on your laptop. This is not possible without the client_id attribute.

[nicolas-besnard]

I'm aware of this behavior, but I think we need a way to handle this to avoid generating too many tokens who are not used.

Can we modify Devise trackable capability to update a key in the token ? With something like "last_used" and delete useless token ? Or maybe it's already implemented thanks to "expiry" ?

[lynndylanhurley]

The tokens will be removed after they have expired, or updated if they are still in use. It looks like @qx has around 8 tokens - I don't think that's a cause for concern. And they will be removed once they expire.

[nicolas-besnard]

It can be an issue when you don't want your token to expiry and you set
your expiration date to 9999.days.

I'm not in this situation, but 8 tokens seems to be big for a single user
on a single webapp.

On Mon, May 18, 2015 at 5:24 PM Lynn Dylan Hurley [email protected]
wrote:

The tokens will be removed after they have expired, or updated if they are
still in use. It looks like @qx https://github.com/qx has around 8
tokens - I don't think that's a cause for concern. And they will be removed
once they expire.

—
Reply to this email directly or view it on GitHub
#210 (comment)
.

[lynndylanhurley]

Right, but if the expiration is set to 9999.days, then the tokens should persist for 9999 days. Removing them before that amount of time has passed would go against the configuration.

There should only be one token per connected device. If this is not the case, then there is something else going on with the client.

@npearson72 and @qx - I think this issue is related to lynndylanhurley/ng-token-auth#119. I'll push a fix tonight.

[nicolas-besnard]

There's no way to identify a device uniquely. I can login 20 times on the
same device, i'll have the same amount of tokens.
On Mon 18 May 2015 at 20:55 Lynn Dylan Hurley [email protected]
wrote:

Right, but if the expiration is set to 9999.days, then the tokens should
persist for 9999 days. Removing them before that amount of time has passed
would go against the configuration.

There should only be one token per connected device. If this is not the
case, then there is something else going on with the client.

@npearson72 https://github.com/npearson72 and @qx
https://github.com/qx - I think this issue is related to
lynndylanhurley/ng-token-auth#119
lynndylanhurley/ng-token-auth#119. I'll push
a fix tonight.

—
Reply to this email directly or view it on GitHub
#210 (comment)
.

[lynndylanhurley]

There's no way to identify a device uniquely. I can login 20 times on the same device, i'll have the same amount of tokens.

The tokens should be destroyed after logout. Are you saying that is not the case?

[nicolas-besnard]

Yes, is it the case. But on an iOS device you can ask your user to log in
again for several reason, and you'll generate many tokens.

IMO, this is not a problem, but it seems to be a problem for some people. I
just try to look around to make people happy ;)
On Mon 18 May 2015 at 23:35 Lynn Dylan Hurley [email protected]
wrote:

There's no way to identify a device uniquely. I can login 20 times on the
same device, i'll have the same amount of tokens.

The tokens should be destroyed after logout. Are you saying that is not
the case?

—
Reply to this email directly or view it on GitHub
#210 (comment)
.

[qx]

@lynndylanhurley Do you means this setting"#config.token_lifespan = 2.weeks" in devise_token_auth.rb, the the tokens will be removed after 2.weeks, or logout manual? If so,this problem will not be serious.
I test it in localhost without logout manually.

[lynndylanhurley]

@qx - that is correct. Most users will only connect with 1 or 2 devices, and so they will only have a few tokens max.

Yes, is it the case. But on an iOS device you can ask your user to log in
again for several reason, and you'll generate many tokens.

@nicolas-besnard - could this be solved by re-using the same client_id when authenticating users that are already signed in?

[nicolas-besnard]

This can be a solution, but the client_id must be saved on the device and you can't send a client_id when you log in, right ?

[lynndylanhurley]

If they're already signed in, I think the client_id header may already be appended to the authentication request. We would just need to check for it and re-use it if it's there, or delete the existing token from the tokens hash.

[nicolas-besnard]

Could be useful, but if you open your API to external developer, they won't
think about sending the client_id. Doesn't seems to be a good fix IMO.

On Tue, May 19, 2015 at 5:52 PM Lynn Dylan Hurley [email protected]
wrote:

If they're already signed in, I think the client_id header may already be
appended to the authentication request. We would just need to check for it
and re-use it if it's there, or delete the existing token from the tokens
hash.

—
Reply to this email directly or view it on GitHub
#210 (comment)
.

[lynndylanhurley]

Could be useful, but if you open your API to external developer, they won't
think about sending the client_id.

Can you elaborate on this please?

[davidtlee]

I found that I have 192 tokens.... not sure how this is happening. How does ng-token-auth detect a unique client?

A possibility is that I am building an ionic / cordova app. I'm wondering if it could be that everytime I create a new build, it's registering as a new client even though it's the same phone? (I guess it would view each build as a different browser?)

I have my token expiry time to be large (essentially infinite) since I don't want a mobile user to have to re-login (just as in the case of a native app).

[davidtlee]

I wonder...is there a way to customize expiry times depending on the type of client? e.g. if it's a mobile client, then I would have an infinite expiry time, but if it's a web client, then expire it after a finite time?

[davidtlee]

I think I know what's happening now. With a hybrid app (e.g. using Ionic / Cordova), you have a native app with a WebView inside. Every time you launch the app, it is registered as a new client since there is essentially a new browser instance that is loaded within the app.

Any ideas for workarounds? For example, would it be possible for me to save the clientID in some native storage and then use that clientID on initial app launch?

[phfts]

I was having the same problem in my rails based api which is using this gem. The api client was using the angular counterpart, and some of its requests (for some reason I don't know yet) were arriving with 'client' header not set. Everytime it happened a new auth token were created, just like @qx commented. After some requests, I was getting a database error saying that my tokens column had reached the size limit.

I think that if the the request 'client' header is empty (this could be a client's mistake) a new client token should be created/updated with client_id = 'default', thus avoiding the creation of unecessary tokens.

I've already done this change in my fork. If you guys think that this makes sense for you, I would be glad to make a pull request.

[booleanbetrayal]

@paulosoares86 - i'd definitely be interested if you or anyone else were able to isolate the client-side issue in ng-token-auth, but I agree that we shouldn't be able to DOS the service due to unnecessary token creation. I'd be interested in seeing that PR if you'd like to put it together.

[phfts]

@booleanbetrayal, can this issue be marked as closed because PR #434 ?

[booleanbetrayal]

I think so, yes. Thanks @paulosoares86