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.
Related
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 using JWT token to authorize my APIs, during implementation I found header and payload in token always start with eyJ. What does this indicate?
JWTs consist of base64url encoded JSON, and a JSON structure just starts with {"..., which becomes ey...when encoded with a base64 encoder.
The JWT header starts with {"alg":..., which then becomes eyJ...
You can try on this online encoder and enter {"alg" and click on encode. The result will be eyJhbGciPSA=
I'm afraid the question, and answer above is a little too extensive/certain.
The best you can check for is (only) 'ey', as the first JSON member could be something else such as "typ" (rather than "alg"); I wouldn't recommend assuming the order of JSON members (even if they are supposed to follow a prescribed order - i.e. allowing for the possibility of real-world anomalies/a small amount of flex).
Also, as much as it is probably unlikely - as far as what is been produced by a particular implementation, there could be a (/some) whitespace following the opening (JSON object) brace character (and maybe even before it!) - I'm not sure if the standard/RFCs forbid this, but even if it's only a temporal instance of a bug (within the JWT generation process) this could in-theory occur; so you're better in only checking for 'ey' - as a quick smoke-test, before then proceeding on to a fuller/complete validation of the JWT.
(F.Y.I. I believe it may have been Microsoft 'Identity Platform' whereby "typ" preceded "alg" - if memory serves me correctly (?), but I can't swear to it / as to where I've seen this being the case - at least at one point in time.)
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 need to access the Date: header when I handle the request, but this seems to be "swallowed" by the framework; any other header (even made up FooBar ones) show up and I can get them, but this gives me None (I'm using Postman to send a simple GET request - everything else works just fine):
println("Date: " + request.headers.get("Date").getOrElse("no date!"))
returns "no date!" no matter how I try to send something sensible.
I'm wondering whether this gets processed before the request object reaches my Action.
I need the actual string value sent, as this should be part of the request's signature - so an equivalent Date object representing the same value would not be of much use (as it needs to be part of the hash, to avoid replay attacks).
Just as a test, I replaced the Date header with a Date-Auth one, and this one shows up just fine:
ArrayBuffer((Date-Auth, ArrayBuffer(Wed, 15 Nov 2014 06:25:24 GMT))
Any ideas or suggestions greatly appreciated!
Are you sure there is a Date Header in your request (tested with tools like firebug or wireshark)?
Browsers do not need to send a Date header.
RFC 2616 (HTTP 1.1) from the Date section (14.18)
Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional. A client without a clock MUST NOT send a Date header field in a request.
I stand corrected - it turns out that Chrome blocks a whole bunch of headers:
http://www.getpostman.com/docs/requests
I wrote a Python Flask test server and, in fact, the Date header is not there.
That page has also a fix, which works just fine with Postman Version 0.10.4.3 and Interceptor(1).
sorry for wasting everyone's time!
1 Incidentally, IMO Postman is the best REST client and has now also some awesome looks, beyond incredible functionality. If you're working with REST APIs, I highly recommend it.
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.