[99s-extend] Cowboy REST Logic

[Phillips, Christopher]

  Will do. I actually like the 303 due to a bug in Firefox with examining
headers, but 201 seems like the canonical approach.
  
  CORS is actually pretty easy to open up fully, and the more restrictive
you want to be the harder it gets. We're not using credentials, and we
haven't tightened the domain to just those we expect, either, but it
basically amounts to adding the following to options/2 for the pre-flight -

  * Access-Control-Allow-Origin (with the origins we want to allow; * for
anything), 
  * Access-Control-Allow-Headers (which we're setting to the same as the
client requests for convenience's sake)
  *Access-Control-Expose-Headers (for any headers beyond content-type that
the client wants access to; we have Location for the 201 mentioned above.


And the following to any request being passed back, as seems reasonable -

  * Access-Control-Allow-Origin as in options
  * Access-Control-Expose-Headers as in options


 I'm appending them in resource_exists/2 because I know that will be hit
by everything. If your logic is more complex (you want to allow PUTs from
site1, but deletes from site2, etc), you'll need to break that apart a bit
and conditionally check origin. We're relying on a firewall to protect
against direct calls from external servers, and we'll be tightening the
allowed domains and looking into validating the session with a token to
prevent CSRFs (as CORS means any existing CSRF vuln becomes a bit more
severe). 


I suspect there's some redundancy there; we have a future story for
tightening things up, but in terms of just opening it up and getting
things working, that¹s all that I had to do.


On 2/13/13 10:34 AM, "Loïc Hoguin" <essen at ninenines.eu> wrote:

>On 02/13/2013 02:52 PM, Phillips, Christopher wrote:
>>
>>    In 6.1, and still in 8.0, there is some logic that surprised me, and
>> I wanted to see if it was intentional, or if I'm missing something.
>>
>>    If I set up a POST such that it's a create, I get back a 303, rather
>> than a 201, on successful create. This came as a bit of a surprise; I
>> know from Webmachine, if it's a new resource being created, a POST will
>> return a 201 (N11 to P11 in Webmachine's v3 diagram).
>>
>>    Is this intentional? The logic seems to be post_is_create/2 ->
>> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 ->
>> respond(_, _, 303). It may be that this is a better response, rather
>> than a 201 with the location header, but it came as a surprise given web
>> machine's behavior.
>
>This difference is probably not intentional. Please open a ticket. :)
>
>>    For background, I'm attempting to migrate some web machine code to
>> Cowboy, which is serving a RESTful API to a Javascript client. The
>> client is making CORS calls. Receiving a 303 and a Location header
>> seemed to mean that the call was redirected before the client side code
>> ever saw it (not sure what the browser was doing; I was expecting
>> another request, but I wasn't quite lucid enough to check for that last
>> night when working on it); a 201 allows me to examine the location.
>
>Would be interested to know more about your CORS implementation, that's
>something I would like to have in the guide.
>
>-- 
>Loïc Hoguin
>Erlang Cowboy
>Nine Nines
>http://ninenines.eu
>