When I decode my JWT token I see in payload
{
"exp": 1494105589
}
What does it value means? Docs says that default JWT expiresIn value is "1d" but it's not seems like 1 day after token created and even not 1 day in ms (1000*60*60*24). And the worst: this value not changed much when I set "expiresIn": "90d" in my config. Could somebody give some explanation of this?
it's a unix timestamp, counting the seconds since 1st of January 1970 00:00 UTC.
There are several websites that help you to convert the value, eg. this one : http://www.unixtimestamp.com/index.php
For your timestamp it says 05/06/2017 # 9:19pm (UTC), so your token is valid for 5 month.
https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4
explains that a numeric date is used for the exp claim (and also for the nbf (not before) and iat (issued at) claims)
https://www.rfc-editor.org/rfc/rfc7519#section-2
defines the numeric date:
A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds.
beside that you said
And the worst: this value not changed much when I set "expiresIn":
"90d" in my config.
when you got the token, did it come in a structure like this :
{"access_token": "eyJhbGciOiJ...", "token_type": "bearer", "expires_in": 86399 }
and if yes, did expires_in show the correct value ?
Related
I am working on private endpoints of Crypto.com, and I am receiving the following problem
{
"id":60,
"method":"private/get-currency-networks",
"code":10007,
"message":"INVALID_NONCE"
}
when sending the message
"{\"id\":60,
\"method\":\"private/get-currency-networks\",
\"nonce\":1667591280642,
\"params\":{},
\"sig\":\"xxxxxxx\",
\"api_key\":\"xxxxxx\"
}"
with signature Hex encoded and all. I tried to get nonce using UTCtime since the Epoch:
long nonce = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();
But I still receive the error message that according to the documentation means "Nonce value differs by more than 30 seconds from server"
for me it helped substracting 10 sec from the current-time when setting the nonce, like:
.setNonce(LocalDateTime.now().minusSeconds(10).atZone(ZoneId.systemDefault()).toInstant().toEpochMilli())
see:
https://exchange-docs.crypto.com/exchange/v1/rest-ws/index.html#invalid_nonce-on-all-requests
Why the following iso format date is parsed incorrectly?
GET /find?account.create_date=2016-06-01T00:00:00.000+05:45
In the controller, if I print the queryString, I get the following result:
println(request.queryString)
//result - Map(account.create_date -> Buffer(2016-06-01T00:00:00.000 05:45))
As, you can see, the timezone sign is missing 05:45 instead of +05:45. However, negative timezone work well. 2016-06-01T00:00:00.000-05:45 is successfully parsed as it is.
This is because the ISO date format is not compliant with the URL encoding (RCF-3896 which has a special use for space and : characters). Playframework will be automatically URL decoding the querystrings you pass in the URL for you.
The correct date time string should have been
GET /find?account.create_date=2016-06-01T00%3A00%3A00.000%2B05%3A45
You can read more about the URL encoding here: https://en.wikipedia.org/wiki/Percent-encoding
I'm using v2 of the core API with HTTP directly, the method https://www.dropbox.com/developers/documentation/http/documentation#sharing-modify_shared_link_settings. I have no problems changing the visiblity, password and expiration date of a link, but I can't see how to remove the expiration entirely.
I've tried
not sending 'expires' at all in my request while changing other properties - no effect
setting 'expires' to the the JSON literal null - no effect
setting 'expires' to a time in the past - gives a 'invalid_settings' error
setting 'expires' to an empty string - gives a "time data " " does not match format '%Y-%m-%dT%H:%M:%SZ'" error.
I'm kind of at a loss here, is there something obvious I'm missing?
Per https://www.dropboxforum.com/hc/en-us/community/posts/205296726-modify-shared-link-removing-expiration-date , currently it is not possible to remove the expiration with the API. The workaround would be to set the expiration to a date very far in the future.
Update: This is now possible using the remove_expiration parameter on the /sharing/modify_shared_link_settings endpoint.
What does the expires_in exactly mean and how is it used?
I am getting 21599 as the expires_in value. It doesn't look like a unix timestamp nor a date in a format I can think of so I do not know how exactly this info would be useful to check whether my token has expired.
I tried looking at the following docs and I cannot find the answer to my question:
https://developers.soundcloud.com/docs/api/guide
https://developers.soundcloud.com/docs/api/reference
Presumably it is in seconds (from now):
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22#section-4.2.2
It would be better if they explicitly documented the units.
So I am creating cookies using Perl's CGI module, and I do it as so:
my $cookie = CGI::Cookie->new(-name => "$name",
-value => "$val",
-expires => "$expiration_date",
-path => $cookie_path,
-secure => 0
);
print "Set-Cookie: $cookie\n";
And the cookie is set in the browser, the only issue is that the time does not match up with the expiration date I put. For example, if I put +1d for expiration date, it really does something like +1d - several hours. I checked my system time to see if that was the issue, but my system time is right. Then I printed out the cookie and I got this:
Actual Time of cookie creation: 6/4/2012 12:10:02 PM
COOKIE: session_id=534fec49c864d8cf0325779b0921b6be1338829802484; path=/; expires=Tue, 05-Jun-2012 17:10:02 GMT
The strage thing above is that I record the actual time of cookie creation with perl's 'localtime(time())' function, but it records a different time than what my date command puts out (so not the actual current time)! And then the expiration time on the cookie is actually correct, but it's in the wrong time zone.
So my server is in the eastern timezone when I run the date command:
Mon Jun 4 12:05:12 EST 2012
However, the cookie is being set with GMT as the timezone, and I think this is the issue. Is there another time I should be setting on the server besides just date? I'm running on CentOS 5 if that helps at all. Thanks!
Those times are actually equivalent (12:00 EST is 17:00 GMT). Note that cookies are required, by the specification, to specify the expiry time in GMT. Your browser, in turn, is required to automatically convert the time zone back.
In so many words: everything is happening as it should.
but it records a different time than what my date command puts out
That's not true.
Tue, 05-Jun-2012 17:10:02 GMT
and
Tue, 05-Jun-2012 12:10:02 EST
are different representations of the exact same time. There's no problem. There would be a problem if you had gotten
Tue, 05-Jun-2012 17:10:02 EST
or
Tue, 05-Jun-2012 12:10:02 GMT
But you didn't.
GMT is used because "EST" is ambiguous — there's a time zone in Australia with the same name — and because only one time zone needs to be known instead of all of them if everyone uses GMT.