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.

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

allow non expiring authentication tokens by setting ttl to -1. #1797

Closed
wants to merge 4 commits into from

Conversation

jesucarr
Copy link

@jesucarr jesucarr commented Nov 5, 2015

I guess this was the initial intent since the -1 value is allowed already

I guess this was the initial intent since the -1 value is allowed already
@slnode
Copy link

slnode commented Nov 5, 2015

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@nini-os
Copy link

nini-os commented Nov 6, 2015

really useful patch.

@bajtos
Copy link
Member

bajtos commented Nov 16, 2015

Hi @jesucarr, thank you for the pull request. I am fine with allowing non-expiring auth tokens, even though I think it may be a security vulnerability.

However, I am not rather uncomfortable to enable this "feature" in all existing applications. Could you please introduce a new setting to enable this feature?

var isValid = elapsedSeconds < secondsToLive ||
  (this.constructor.settings.allowEternalTTL && secondsToLive === -1);

Note that you can already achieve the same effect by setting TTL to Number.MAX_SAFE_INTEGER or similar large number.

@raymondfeng @ritch what's your opinion on this? Am I too paranoid?

@bajtos bajtos self-assigned this Nov 16, 2015
@bajtos
Copy link
Member

bajtos commented Nov 16, 2015

@slnode ok to test

@superkhau
Copy link
Contributor

+1 for config to turn this feature on/off

@jesucarr
Copy link
Author

ok just pushed the new setting as proposed. I think it's a good idea. However I changed the name to allowEternalTtl so it is consistent with the camelcase naming.

@bajtos
Copy link
Member

bajtos commented Nov 24, 2015

@jesucarr thank you for the update. Could you please add a unit-test to check the correctness of your implementation and prevent regressions in the future?

@pulkitsinghal
Copy link

+1 good community contribution, will try it out when its merged

@doublemarked
Copy link

It feels incongruent to have this allowEternalTtl setting under AccessToken but to have other TTL-related settings under User (ttl, maxTTL, etc.). Maybe implement this by overloading User.maxTTL? maxTTL: -1

@SandeshSarfare
Copy link

is there any good plugin for loopback api security?

@jamesw6811
Copy link

If anyone is looking at workarounds and wants an expiration date longer than 1 year -- see #353

@KorySumsion
Copy link

Any news on this feature getting into production?

@slnode
Copy link

slnode commented Feb 23, 2016

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@htertery
Copy link

+1

@slnode
Copy link

slnode commented Apr 12, 2016

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

@KorySumsion
Copy link

+1

2 similar comments
@ahmed-abdulmoniem
Copy link

+1

@juanpujol
Copy link

+1

@superkhau
Copy link
Contributor

LGTM, @bajtos @raymondfeng @ritch Thoughts? We should get this merged if there are no objections.

@ahmed-abdulmoniem
Copy link

@jesucarr How we can use the new option after merging this change?

@jesucarr
Copy link
Author

@ahmed-abdulmoniem you just need to set the ttl to -1 in the options

@superkhau
Copy link
Contributor

Can someone add unit tests to verify these changes?

@ahmed-abdulmoniem
Copy link

@jesucarr I mean in which options, options of the model or what?

@jesucarr
Copy link
Author

@ahmed-abdulmoniem yes AccessToken options, or login options https://docs.strongloop.com/display/public/LB/Logging+in+users

@bajtos
Copy link
Member

bajtos commented May 13, 2016

It feels incongruent to have this allowEternalTtl setting under AccessToken but to have other TTL-related settings under User (ttl, maxTTL, etc.). Maybe implement this by overloading User.maxTTL? maxTTL: -1

This is a good point. Perhaps we should implement this change at the place where the AccessToken is created and we have access to User.settings, so that we can set allowEthernalTTL via User settings?

Regardless of that, we need a unit-test before we can land this change. Is there any volunteer to pick up that task?

@Shyri
Copy link

Shyri commented May 23, 2016

Hi guys, do you know if this is going to be merged any time soon?

@ahmed-abdulmoniem
Copy link

++++1

@ritch
Copy link
Member

ritch commented Jul 6, 2016

A couple things before this can be merged:

  • a test verifying a token is valid when create w/ infinite TTL: -1
  • split out the expression into multiple lines, with a variable describing each parts of the sub expression.

I want this code to be overly-clear so that if any of us come accross it again, its obvious what it is doing. Something like:

var created = this.created.getTime();
var elapsedSeconds = (now - created) / 1000;
var secondsToLive = this.ttl;
var allowEternalTTL = this.constructor.settings.allowEternalTTL;
var isEternalToken = secondsToLive === -1;
var isValidEternalToken = isEternalToken && allowEternalTTL;
var isValid = isValidEternalToken || (elapsedSeconds < secondsToLive);

@slnode
Copy link

slnode commented Jul 6, 2016

Can one of the admins verify this patch?

@ritch
Copy link
Member

ritch commented Jul 6, 2016

However, I am not rather uncomfortable to enable this "feature" in all existing applications. Could you please introduce a new setting to enable this feature?

@bajtos agree 100%

@bajtos
Copy link
Member

bajtos commented Oct 10, 2016

Closing in favour of #2841.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet