Yup, thanks @kennethlimcp! Weāve already committed the code to the Cloud internally, and Authorization will be accepted in CORS requests beginning the next time we deploy, sometime next week most likely.
I donāt know much about such stuff and never got that deep to the discussion you guys had over in the other thread but im always impressed!
Hopefully someday iām good at what im learning too
Hey there Ć¼bergeek
@zachary, on a separate matterā¦can you code a quick example of how to call the spark.function digitalwrite and pass D0, high in jquery? The args=D0, HIGHā¦are confusing. Haha!
@Dave ā¦ re the PUT comment you made. Naturally, I would tend to agree. However, this is a copy paste from the current Cloud API Documentation page ā¦
# EXAMPLE REQUEST IN TERMINAL
# Flash a Core with a file called "my-firmware-app.cpp"
curl -X PUT -F file=@my-firmware-app.cpp \
"https://api.spark.io/v1/devices/0123456789abcdef01234567?access_token=1234123412341234123412341234123412341234"
Perhaps that should ideally be changed then, to some thing like ā¦
# EXAMPLE REQUEST IN TERMINAL
# Flash a Core with a file called "my-firmware-app.cpp"
curl -H "Authorization: Bearer 1234123412341234123412341234123412341234" \
-X PUT -F file=@my-firmware-app.cpp \
"https://api.spark.io/v1/devices/0123456789abcdef01234567"
Or, given the documentation as it stands right now, is it possible that the server actually only accepts the token in the URI at present (for flashing)? Seems unlikely, given what you have just stated. Worth double checking, maybe?
Actually the key confusing difference here is the content type of the request. While uploading a file, the content-type is multipart/form-data. That's why we use the -F flag instead of -d. If you try to put the token in the body with an additional -F flag, you'll see the server's clear response:
{
"code": 400,
"error": "invalid_request",
"error_description": "When putting the token in the body, content type must be application/x-www-form-urlencoded."
}
Which means you can either put it in the query string (weird exception to the good general rules @Dave mentioned), or, even better, in an authorization header as @gruvin suggested. It will work either way. From the authentication section of the docs:
There are three ways to send your access token in a request.
In an HTTP Authorization header (always works)
In the URL query string (only works with GET requests)
In the request body (only works for POST & PUT when body is URL-encoded)
When we're uploading files to flash to a Core, the body is not URL-encoded.
In general, even though most internet users never see HTTP headers (so headers feel confusing to novice web coders), I'd recommend everyone get in the habit of just always sending tokens that way, since it always works. FTW:
Waiting for my spark device to test this outā¦ spark.io, you would not happen to have a set of test devices online for API consumers to play with (until my device arrives :)?
Oh! Right. Silly me. I didn't read the code carefully enough to even see the -F and realise the obvious. You cannot have a token stuffed inside the content of the file you're sending! (I was stuck in some previous context and skim reading. Never a wise move.)
Yeah, That might be a really good idea. It wouldn't even need to be a real spark. Just a virtual demo spark, in the cloud. People who haven't made a purchase decision yet could maybe play with such a thing, perhaps to see how it works in with their current knowledge and abilities or something.
Others, who write tutorials or books on the sparkcore could maybe use such a virtual test spark for their examples and what not.
Obviously not a high priority. But maybe useful for the future?
Unfortunately, I am still seeing issues with CORS. I tried to PUT code on a spark and it failed due to CORS headers.
XMLHttpRequest cannot load https://api.spark.io/v1/devices/55ff6c065yyyyyyyyy32391887. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://mydomain.com' is therefore not allowed access.
Hmm, thatās weird, that header should be included on all requests / and OPTIONS requests. Any chance you could send us a sample request / response? Are you developing directly on your domain, or are you running the file locally? Browsers do some weird stuff when youāre running them from a file, and not from a webserver, so it might be a local file browser security thing.
Silly me. Not specifying the content-type fixed the CORS issue (code below). However, the PUT call never returns and eventually fails with an empty response.
PUT (failed) net::ERR_EMPTY_RESPONSE
sample code:
<html>
<head>
<title></title>
<script>
function flash() {
var url = "https://api.spark.io/v1/devices/<DEVICE ID>"
var request = new XMLHttpRequest();
request.open("PUT", url);
request.setRequestHeader("Authorization", "Bearer <ACCESS TOKEN>")
var form = new FormData();
var input = document.getElementById('file');
form.append("file", input.files[0])
request.send(form)
}
</script>
</head>
<body>
<input id="file" name="file" type="file">
<input type="submit" value="Upload" onclick="flash()" />
</body>
</html>