Suggestion: api.spark.io server to include headerAccess-Control-Allow-Headers "Authorization"

General
1

To the master of ceremonies in charge of Spark’s api server security protocols,

Not sure if this would really help in any sorely needed way, since all GET requests to the API server are https encapsulated. However, those URIs do get logged in plain text on the server, so an argument of extreme paranoidal proportions might be made in favor of avoiding tokens in the URI. Thus, I besiege thee …

For ajax Sparkcore variable access via a web app, I was trying to get the ?access_token= thing out of the GET/URL and into an, Authorization: Bearer ... header. But it turns out the api.spark.io server CORS responses do not permit the Authorization header. Following is the related response from the server, to my browser’s OPTIONS request …

Access-Control-Allow-Headers	X-Requested-With, Content-Type, Accept

If the api server god (homage :stuck_out_tongue: !) would be willing to append Authorization to that response, then it would enable keeping the access_token out of the GET URL, such that the following jQuery ajax variable GET request would work …

      var url = baseURL + coreID + "/variableget"; // + "?access_token=" + accessToken;
      $.ajax({
        url: url,
        beforeSend: function(xhr) {
          xhr.setRequestHeader("Authorization", "Bearer " + accessToken);
        },
        dataType: "json",
        success: function(obj) {
          console.log(obj);
        },
        fail: function(obj) {
          console.log(obj);
        }
      });

Just a thought.

Interestingly, the same sort of thing already works, using curl …

curl -H "Authorization: Bearer e4ff9...4f316c" https://api.spark.io/v1/devices/testdevice/variableget

… apparently because curl doesn’t care to honor CORS rules (probably doesn’t even send an OPTIONS pre-flight request) and the api server just gives in and serves the request anyhow. Rather bizarre that last part, I thought. {shrug}

1 Like
2

I’ll second this request.
Never feels right to have sensitive data in a querystring parameter even if it is SSL.

Between this and a browser oauth flow. Potentially even expiring tokens would round out the api security.

3

That already happens for you (whether you like it or not) after 90 days. I couldn't find it in the official documentation, but @Dave answered it in this forum thread.

4

I meant much shorter lived limited request tokens. So I can get a temporary request token and not worry about it being present in JavaScript code.
They expire after say fifteen minutes and only have read capabilities. When it expires you just request another one with the access token.

Getting a temporary request token would only ever be done server side, but then you can pass request token down to the client relatively worry free.

5

Hey Guys,

Lots of good questions! I’ll try to answer what I can – Both @zachary and @Dave (me) are most familiar with the insides of the API, so feel free to ping us by the @name and we’ll get an email from the thread directly. :slight_smile:

###What do our api logs look like?

Both because of large amounts of traffic, and security, we log very little of the API traffic, mostly only if errors occur. When we do log requests, we have code that filters out access tokens. These logs soon will not be stored on the cloud at all, and are currently deleted after about a week. :smile:

###Authorization header in Curl vs. Javascript

I didn’t realize there was a CORS issue when using the header on another site, I’ll add a task for that to our API backlog and try to fix that soon. :smile:

Limited access tokens

Personally I really like the idea of more finely grained control over both token expiration as well as permissions levels. How great would it be if you could give out a “only read this particular variable from this core” access token with a long life? :slight_smile: Or only call this function and not this function, etc. It’s something we’ve been chatting about, but the configurable expiration life would be a quicker change we could make while planning out better controls. I’ll add a task for that as well!

Thanks,
David

1 Like
6

I concur with @Dave. Also I coded the (one-liner) change to append the Authorization header to the allowed CORS list faster than he could add it to the backlog. :fast_forward: :exclamation: :wink: It will be effective next time we deploy the Cloud, probably after @Dave’s back from China.

Re the fact that the Authorization header works with curl—CORS is only enforced by browsers. It’s not an intrinsic part of the API, other than stating in headers what we want the browsers to allow. I guess one could view curl as a browser that arguably ought to enforce CORS, but I would personally hate that, and I think lots of other folks would too. :smile:

1 Like
7

@dave, @zachary … thanks a bunch for the info and taking these ideas onboard. No wait … you were already ahead of us on the token thing, by the sounds. Yay \o/

Oh and yes, let’s not even raise the issue with the curl crew. I’m more than happy to let that sleeping dog lay blissfully undisturbed, dreaming of Spark powered kennels and even easier food.

1 Like
8

Totally!

As a side note, I’m guessing something like curl shouldn’t enforce cors, since it doesn’t quite have a browser context :slight_smile:

9

Exactly! Do you think we can get that written into law? It would sure be a pain if curl were to start enforcing CORS. What would I use for website hacking then? :stuck_out_tongue:

FWIW, my original comment about curl was merely a curiosity or thinking out loud about how the server responds with headers telling the browser that an Authorization header is not allowed, but then goes on to accept and process one if given, anyway. It makes sense though. CORS is a browser enforced thing and a bandaid solution, at that. We certainly cannot have servers refusing Authorization headers, just because there was no CORS pre-flight check, as there most often would never be, of course. Hence my original, '{shrug}', which was really just me being too lazy to remove my pointless dribble from the post. LOL

1 Like