Cors michael

CORS and Javascript
Integration in the browser
Michael Neale
@michaelneale
developer.cloudbees.com
http://en.wikipedia.org/wiki/Cross-
origin_resource_sharing
Thursday, 12 September 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

CI serverApp service
JSON !!111
repos

but - same origin policy?
http://en.wikipedia.org/wiki/Same-origin_policy

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
All JSON world - add “padding”.
JSON P: take pure json, make it a function call - then
eval it.
Single Origin policy doesn’t apply to resource
loading

jsonp: Most glorious hack
ever

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

JSON-P
What it is really doing: creating script tags, and
making your browser “eval” the lot. Each time.
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/Cross-
origin_resource_sharing
Allows servers to specify who/what can access
endpoint directly
Use plain JSON, ALL HTTP Verbs: PUT, DELETE
etc

CORS

Oy, they’re my sisters yer lookin atNOT THESE:

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

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
direct http GET (as allowed by Access headers)
...
pre-
ﬂight
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-allow-
cors-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” - Access-
Control-Allow-Credentials: true -- needed to ensure
cookies/auth info ﬂows with requests)

Authorization
requests
authorization
identity/auth
pre-ﬂight
your app
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] +URL_REQUEST_BLOCKED_ON_DELEGATE [dt=0]
t=1374052796709 [st=262] CANCELLED
t=1374052796709 [st=262] -URL_REQUEST_START_JOB
--> net_error = -3 (ERR_ABORTED)
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!!

Servlet Filter
https://github.com/cloudbees/cors-plugin/blob/
master/src/main/java/org/jvnet/hudson/plugins/
cors/JenkinsCorsFilter.java

Thank you
Michael Neale
https://twitter.com/michaelneale
https://developer-blog.cloudbees.com

Cors michael

More Related Content

What's hot (7)

Similar to Cors michael (20)

More from Michael Neale (15)

Recently uploaded (20)

Cors michael