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.
Related
I'm in context of managing an openId jws, and I'm not sure about how to verify the aud claim.
In details, suppose that I've an application id myapp.site.com and I receive an aud which value is myapp.site.com|*|ANY. I've not found specifications about this format, but reading the aud specification into https://openid.net/specs/openid-connect-core-1_0.html#IDToken I've supposed to explode the string myapp.site.com|*|ANY using the "pipe" as separator, and then verify if this array contains the aspected client id (ie myapp.site.com).
My question is: whatabout the * and ANY? there's some specifications about this format? where can I retrieve informations?
Thanks in advance,
Sim.
That looks like a custom thing that is not a standard that I have seen anywhere else, so I guess its up to you to parse it as it is. At the same time the purpose of the audience is for the receiver of a token to be sure the token is aimed for it and not someone else. So its a security risk to accept any token even if the signature is valid.
We want to work with timezones in the Watson Assistant responses.
Basically we want to implement the "good morning" sample as described here:
https://console.bluemix.net/docs/services/conversation/dialog-methods.html#date-time
When we post to this URL
https://gateway.watsonplatform.net/assistant/api/v1/workspaces/<workspaceid>/message?version=2018-02-16
using this payload (first call in the conversation)
{"context":{"$timezone":"Europe/Amsterdam"}}
We keep getting greetings based on the UTC.
When we add the now() output to the response we also do see the time according to the UTC.
The strange thing is, when we try this out in the try-out panel of the Watson Assistance workbench (browser) the output behaves as expected ?
The value should be, without the dollar sign:
{"context":{"timezone":"Europe/Amsterdam"}}
The $ is used to denote (context) variables for the short syntax, but in the payload you are working with the regular context struture and key/value pairs.
I am attempting to preview a track via the 7digital api. I have utilised the reference app to test the endpoint here:-
http://7digital.github.io/oauth-reference-page/
I have specified what I consider to be the correct format query, as in:-
http://previews.7digital.com/clip/8514023?oauth_consumer_key=MY_KEY&country=gb&oauth_nonce=221946762&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1456932878&oauth_version=1.0&oauth_signature=c5GBrJvxPIf2Kci24pq1qD31U%2Bs%3D
and yet, regardless of what parameters I enter I always get an invalid signature as a response. I have also incorporated this into my javascript code using the same oauth signature library as the reference page and yet still get the same invalid signature returned.
Could someone please shed some light on what I may be doing incorrectly?
Thanks.
I was able to sign it using:
url = http://previews.7digital.com/clip/8514023
valid consumer key & consumer secret
field 'country' = 'GB'
Your query strings parameters look a bit out of order. For OAuth the base string, used to sign, is meant to be in alphabetical order, so country would be first in this case. Once generated it doesn't matter the order in the final request, but the above tool applies them back in the same order (so country is first).
Can you make sure there aren't any spaces around your key/secret? It doesn't appear to strip white space.
If you have more specific problems it may be best to get in touch with 7digital directly - https://groups.google.com/forum/#!forum/7digital-api
I am using the ruby paypal rest api and everything I do seems to be right but PayPal keeps saying my date format is incorrect.
Here is my call:
Payment.all(:start_time => '2013-03-06T11:00:00Z', :end_time => '2013-03-06T11:00:00Z')
After many attempts I literally took the date example in the documentation: https://developer.paypal.com/webapps/developer/docs/api/
Because no matter what I do I keep getting the same response:
'{"name":"VALIDATION_ERROR","details":[{"field":"start_time","issue":"Must
be a date_time string of form yyyy-mm-ddThh:mm:ss(.sss)?Z"},{"field":"end_time","issue":"Must
be a date_time string of form yyyy-mm-ddThh:mm:ss(.sss)?Z"}],"message":"Invalid
request - see details","information_link":"https://developer.paypal.com/webapps/developer/docs/api/#VALIDATION_ERROR","debug_id":"dcd8a9ce6a5e7"}'
Am I blind or does it not make sense?
Looks like it's a bug in our API where it's expecting raw value rather than url encoded value. The SDK was always url encoding the value of the start_time and end_time (or as a matter of fact all url parameters as per the HTTP spec). We have filed a bug and get this fixed as soon as possible. Meanwhile if this is something you need to work, we can possibly make the SDK not url encode the params or you can just modify the code for now locally.
I think your issue might be that you're setting both the start time and the end time to the same exact value. If you want a single day's worth of transactions the end time would be 2013-03-06T23:59:59Z.
I searched on Google and StackOverflow to find a answer to my question but I can't find one.
I'd like to store the access_token to my database for offline access and I'd like to be sure to specify the correct length of my column.
I can't even find if it's just a number or a mix between number and strings.
I work at Facebook and I can give a definitive answer about this.
Please don't put a maximum size on the storage for an access token. We expect that they will both grow and shrink over time as we add and remove data and change how they are encoded.
We did give guidance in one place about it being 255 characters. I've updated the blog post that had that information and updated our new access token docs to include a note about sizes:
https://developers.facebook.com/docs/facebook-login/access-tokens/
Sorry for the confusion.
With Facebook's recent move to encrypted access tokens, the length of the access token can be up to 255 characters. If you're storing the access token in your database, the column should be able to accommodate at least varchar(255). Here's an excerpt from Facebook's Developer blog from October 4, 2011:
"With the Encrypted Access Token migration enabled, the format of the access token has changed. The new access token format is completely opaque and you should not take any dependency on the format in your code. A varchar(255) field will be sufficient to store the new tokens."
Full blog post here: https://developers.facebook.com/blog/post/572
This answer is no longer correct, and I can't find a corrected value in FB's docs. We have been receiving access tokens that are longer than 255 characters. We're moving from VARCHAR to a SMALLTEXT instead to try to future-proof things.
From section 1.4 of The OAuth 2.0 Authorization Protocol (draft-ietf-oauth-v2-22)
Access tokens can have different formats, structures, and methods
of utilization (e.g. cryptographic properties) based on the
resource server security requirements. Access token attributes and
the methods used to access protected resources are beyond the scope
of this specification and are defined by companion specifications.
I looked for the "companion specifications" but didn't find anything relevant and in section 11.2.2 it states
o Parameter name: access_token
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]
Which seems to indicate that the access_token parameter is defined within this spec. Which I guess the parameter is but the actual access token isn't fully fleshed out.
Update:
The latest version of this writing of the specification (draft-ietf-oauth-v2-31) includes an appendix that defines better what to expect from the access_token parameter
A.12. "access_token" Syntax
The "access_token" element is defined in Section 4.2.2 and
Section 5.1:
access-token = 1*VSCHAR
So essentially what this means is that the access_token should be at least 1 character long but there is no limit on how long defined in this specification.
Note they define VSCHAR = %x20-7E
Facebook access token can be longer than 255 characters. I had a lot of errors like ActiveRecord::StatementInvalid: PG::StringDataRightTruncation: ERROR: value too long for type character varying(255) where the value was facebook access token. Do not use string type column because its length is limited. You can use text type column to store tokens.
Recently, our app has been seeing them longer than 100 characters. I'm still looking for documentation so I can figure out a 'safe' field size for them.
I'll update the answer from the time spend.
From the OAuth2 documentation,
The access token string size is left undefined by this specification. The client should avoid making assumptions about value sizes. The authorization server should document the size of any value it issues.
(Section 4.2.2 of this document)
Note: Facebook is using OAuth2, as mentionned on this page.
So now, no informations seems to be available on the developers portail of Facebook about the length of the OAuth token. Yahoo seems to use a 400 bit long token, so it's best to assume that a TEXT column in MySQL is safer than a varchar.