If I set the access_token_validity to 315569260, I'm expecting the token

when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?

It's a little bit different.

access_token_validity is how long the token is valid for from the time of
creation. thus we can derive

exp (expiration time) = token creation time + access token validity

you don't get to set the expiration time, since that doesn't make sense as
the clock keeps ticking forward.

in your case, having access token validity be 10 years, achieves exactly
what you want

Filip


On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Thanks again Filip.

However, here's what I mean,

If I set the access_token_validity to 315569260, I'm expecting the token
when decoded to read exp: 315569260. If this is not, then is it possible to
set the token expiry time?

line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)

Now the question is why do you have to do expirationTime*1000l since the
token when decoded originally set's this value to 1438209609 (without *
1000l)

Except I'm completely getting this all wrong?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev