Need to implement OPTIONS method and CORS

[karlcz]

The hatrac service does not implement the OPTIONS method for HTTP.

@kylechard @robes we need to define the scope of this...

OPTIONS request processing

Every resource should support this:

0. Request headers for CORS pre-flight OPTIONS request
   • Origin: the origin or origins of the page causing the request on the browser (null or space-separated list of origins e.g. https://server1 http://server2:port)
   • Access-Control-Request-Method: the all-caps HTTP method name the browser plans to use with actual request, e.g. GET
   • Access-Control-Request-Headers: comma-separated list of header names the browser plans to send with actual request
1. Response headers for basic HTTP OPTIONS request
   • Allow: comma-separated list of all-caps HTTP method names supported by the resource (for the current client), e.g Allow: GET,OPTIONS
2. Response headers for CORS:
   • Access-Control-Allow-Origin: * or null or single origin?
   • Access-Control-Allow-Credentials: true to say we want our cookies sent w/ the cross-origin request
   • Access-Control-Expose-Headers: comma-spearated list of response header names exposed (exposed means the cross-origin client can view the response header content)
     • Default allows: Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma
   • Access-Control-Allow-Methods: comma-separated list of all-caps method names
   • Access-Control-Allow-Headers: comma-spearated list of request header names allowed (allowed means the cross-origin client can specify the request header content)
     • Don't need to list implicit ones: Accept, Accept-Language, Content-Language, Content-Type
   • Access-Control-Max-Age: delta seconds as one more more decimal ASCII digits

Extensions to regular request processing

The CORS response headers should actually be included in most responses to cover cases where the browser opportunistically sends the request rather than doing a pre-flight via OPTIONS.

• Access-Control-Allow-Credentials
• Access-Control-Allow-Headers if request had Access-Control-Request-headers
• Access-Control-Allow-Origin says whether this specific response can be shared, also include Origin in the Vary response header if content is restricted!
• Access-Control-Expose-Headers

Cross-site concerns

1. We need a service configuration option to actually supply CORS whitelist policies.
2. We need to actually check Origin headers against our policy on all requests, not just in the new OPTIONS request handler.
3. We need to decide how many levels of CORS-managed trust we might have in origins:
   • None: behave as in pre-CORS world
   • Public: map our * ACLs into public access in CORS terms?
   • Read-only: only support GET, HEAD, OPTIONS?
   • Full: support all operations as we would from our own origin

[karlcz]

I'm not seeing any feedback that this is a high priority issue, so we'll park it for now. We need some motivating use cases for how we want CORS to interact with credentials and fine-grained ACLs, including how many levels of trust a server admin might want to express for other origins.

[carlkesselman]

I think this was driven by the desire to use JBROWSE in Facebase….

[karlcz]

According to @robes that was just to allow a non-standard deployment for development purposes. The actual deployment would put the jbrowse stuff on the same server and not involve any cross-domain requests.

[carlkesselman]

Ahh, ok. Carl

…

---------------------------------------------------------- Dr. Carl Kesselman Dean’s Professor, Epstein Department of Industrial and Systems Engineering Fellow, Information Sciences Institute Viterbi School of Engineering Professor, Preventive Medicine Keck School of Medicine University of Southern California 4676 Admiralty Way, Suite 1001, Marina del Rey, CA 90292-6695 Phone: +1 (310) 448-9338 Email: [email protected]<mailto:[email protected]> Web: http://www.isi.edu/~carl On Mar 16, 2017, at 4:58 PM, Karl Czajkowski <[email protected]<mailto:[email protected]>> wrote: According to @robes that was just to allow a non-standard deployment for development purposes. The actual deployment would put the jbrowse stuff on the same server and not involve any cross-domain requests. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#38 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADbjXvL0scY3DYudra6hR_1RpYDWprUlks5rmcyIgaJpZM4MYkgb>. {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/informatics-isi-edu/hatrac","title":"informatics-isi-edu/hatrac","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/informatics-isi-edu/hatrac"}},"updates":{"snippets":[{"icon":"PERSON","message":"@karlcz in #38: According to @robes that was just to allow a non-standard deployment for\ndevelopment purposes. The actual deployment would put the jbrowse\nstuff on the same server and not involve any cross-domain requests.\n"}],"action":{"name":"View Issue","url":"#38 (comment)"}}}

[robes]

That’s right