Cross site calls with javascript - the right way with CORS

CORS and Javascript
Integration in the browser
Michael Neale
@michaelneale

Friday, 25 October 13

Integration in the browser
Lots of services, microservices
Everything has an API
JSON == lingua franca
Why have servers that are just text pumps:
Integrate into new apps in the browser


For example


JSON !!111

App service

repos

CI server

but - same origin policy?

http://en.wikipedia.org/wiki/Same-origin_policy

but - same origin policy?
Web security model - not bad track record.
Not going to change... so, how to work around:


integration middleware?


Overkill


JSON-P
Add “padding”.
JSON P: take pure json, make it a function call - then
eval it in the browser.
Same Origin Policy doesn’t apply to resource loading
(script tags)


jsonp: Most glorious hack
ever


JSON-P
JSON: { “foo” : 42 }
JSONP: callback({ “foo” : 42 });
Widely supported (both by servers and of course
jquery & co make it transparent)


direct to origin:
$.ajax({
dataType : "json"
...
});


JSON-P cross domain
$.ajax({
dataType : "jsonp",
jsonp:'jsonp'
....
});


JSON-P
What it is really doing: creating script tags, and
making your browser “eval” the lot. Each time, each
request.
Don’t think too hard about it...


JSON-P
Really misses the “spirit” of same-origin.
Security holes: any script you bring in has access to
your data/dom/private parts.
How secure is server serving up json-p?


JSON-P
Also, JSON is not Javascript
JSON can be safely read - no eval
JSON-P only eval
JSONP is GET only


CORS
http://en.wikipedia.org/wiki/Crossorigin_resource_sharing
Allows servers to specify who/what can access
endpoint directly
Use plain JSON, ALL HTTP Verbs: PUT, DELETE
etc


NOT THESE:


Oy, they’re my sisters yer lookin at

CORS
Trivial to consume: plain web calls, direct.
Complexity: on the server/conﬁg side.
Browser support: complete(ish):
http://enable-cors.org/
All verbs, all data types


CORS - client side ex.
$.ajax({
dataType : "json",
xhrFields: {
withCredentials: true
}
...
});


How it works
Most work is between browser and server, via http
headers.
“Pre ﬂight checks”:
Browser passes Origin header to server:
Origin: http://www.example-social-network.com

Server responds (header) saying what is allowed:
Access-Control-Allow-Origin: http://www.example-social-network.com


How it works
browser

server
http OPTIONS (Origin: http://boo.com)
Access-Control-Allow.... etc

preﬂight

direct http GET /POST (as allowed by Access headers)

...


your
app

How it works
Performed by browser, opaque to client app.
Browser enforces. You don’t see them.
Uses “OPTION” http verb.


Security Theatre?
Can be just an annoyance.
Access-Control-Allow-Origin: *

Downside: allows any script with right creds to pull
data from you (do you want this? Think, as always)


Common pattern
Access-Control-Allow-Origin: $origin-from-request

The returned value is really echoing back what Origin
was - checked oﬀ against a whitelist:
Server needs to know whitelist, how to check, return
value dynamically.
Not a static web server conﬁg. SAD FACE.


Middleware
All app server environments have a way to do the
Right Thing with CORS headers:
Rack-cors: ruby
Servlet-ﬁlter: java
Node: express middleware
etc...
(it isn’t hard, just not as easy as it should be)
http://stackoverflow.com/questions/7067966/how-to-allowcors-in-express-nodejs


Other CORS headers
Access-Control-Allow-Headers (headers to be
included in requests)
Access-Control-Allow-Methods: GET, PUT, POST,
DELETE etc
Access-Control-Allow-Credentials: boolean
(lists always comma separated)


Authorization
You can use per request tokens, eg OAuth
OpenID and OAuth based sessions will work
(browser has done redirect “dance” - AccessControl-Allow-Credentials: true -- needed to ensure
cookies/auth info ﬂows with requests)


Authorization
requests
authorization your app
identity/auth
pre-ﬂight


browser

Debugging
Pesky pre-ﬂight checks are often opaque - may
show up as “cancelled” requests without a reason.
Use chrome://net-internals/#events


Debugging
Following screen cap shows it working...
note the match between Origin and Access-control if you don’t see those headers in response something is wrong.


Debugging
t=1374052796709 [st=262]
t=1374052796709 [st=262]
t=1374052796709 [st=262]

+URL_REQUEST_BLOCKED_ON_DELEGATE
CANCELLED
-URL_REQUEST_START_JOB
--> net_error = -3 (ERR_ABORTED)

[dt=0]

This is it failing: look for “cancelled”.
Could be due to incorrect headers returned, or
perhaps Authorization failures (cookies, session etc)


My Minimal Setup
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: $ORIGIN

$ORIGIN = if (inWhitelist(requestOriginHeader) return
requestOriginHeader
INCLUDE PORTS IN Access-Control-Allow-Origin!!


Example (express)
app.all('*', function(req, res, next) {
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Headers", "X-Requested-With");
next();
});

node and express js:
http://enable-cors.org/server_expressjs.html


Example (rack/ruby)
gem install rack-cors
...
in config/application.rb:
...
config.middleware.use Rack::Cors do
allow do
origins '*'
resource '*', :headers => :any, :methods => [:get, :post, :options]
end
end

https://github.com/cyu/rack-cors


Cross site calls with javascript - the right way with CORS

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Cross site calls with javascript - the right way with CORS

Similaire à Cross site calls with javascript - the right way with CORS (20)

Plus de Michael Neale

Plus de Michael Neale (15)

Dernier

Dernier (20)

Cross site calls with javascript - the right way with CORS