-
Notifications
You must be signed in to change notification settings - Fork 343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CORS Headers Options verb #1020
Comments
@Primajin Would it be possible to share the OpenAPI document you're trying to mock or at least a minimal reproducible example? |
Uhh I would need to set something up for this - my hunch was that it was just forgotten to add OPTIONS as part of allowed cors methods. We would need it to be set to
So that I can connect to the mock server via browser and test out all the endpoints. |
That's why I was asking for your document — I am assuming it has an explicit OPTION verb you're handling, right? |
Oh I see now it actually does not 🤔🙈 But even if I add one, the mock server does not add that to the allowed methods - it does show up in Routes though |
That is really weird then, the CORS option are enabled by default in Studio. I'll triple check. |
Maybe it's really just that one method missing? The other standard methods like GET seem to work fine. |
I am a little bit confused — how can you effectively perform an OPTIONS request to your API when you have CORS enabled? Wouldn't the CORS handler catch all the requests anyway, preventing your custom handler to be executed? |
So normally we request via a library called Axios from the browser to our API. The API has cors headers set in a way that allows our company url + localhost to connect. When developing new endpoints I wanted to use the stoplight mockserver so that we can already start working on UI implementation while our API developers still work on the real endpoint. We are using the options call to check what fields the current user can request and then start the normal get requests as anyone does. But the options call fails against the mock server and the browser shows a CORS error - that's why I thought there might be something missing. If I use postman or insomnia then this problem doesn't occur because those don't respect the cors headers that are set server side - while a common browser respects those. |
That is indeed what they should do, since it's just that it's a browser-only check and these are two desktop applications. This is not their lack, it's just the way it is. What is still not clear to me is that how can Prism differentiate between YOUR OPTIONS handler and the one that Prism "auto generates" to handle your CORS? It would really help me a lot to get a sample OpenAPI Spec to try this out, because the whole thing is still not clear to me. |
Alright then let me tinker something for you in the next week 👍 |
OK here we go: openapi: 3.0.0
info:
title: cors-me
version: '1.0'
contact:
name: Jannis Hell
email: [email protected]
servers:
- url: 'http://localhost:3000'
paths:
/test:
get:
summary: Your GET endpoint
tags: []
responses:
'200':
description: OK
content:
application/json:
schema:
type: object
properties:
test:
type: string
default: GET worked
operationId: get-get
parameters: []
post:
summary: ''
operationId: post-test
responses:
'200':
description: OK
content:
application/json:
schema:
type: object
properties:
test:
type: string
default: POST worked
options:
summary: ''
operationId: options-test
responses:
'200':
description: OK
content:
application/json:
schema:
type: object
properties:
test:
type: string
default: OPTIONS worked
components:
schemas: {} Then Open a browser on this page: https://codesandbox.io/s/stoplight-test-cors-9kt99 It will do a GET, POST and OPTIONS call against Doing an OPTIONS over Insomnia also does not return the body as configured. Hope this helps |
Hey, Ok I've gone through your use case and I now understand what's going on Yes, effectively we are not allowing the https://github.com/stoplightio/prism/blob/master/docs/guides/cors.md Essentially, if you enable CORS Prism will take control of the whole The solution to this might be a little bit complicated, since it would require to check the OPTIONS verb and then still forward the request internally for its processing — but I am not entirely sure this is how all the other web servers behave. If you want to use such verb I would suggest you to use a proxy before hitting Prism (what are you using for your frontend application? If you're on create-react-app it should be easy: https://create-react-app.dev/docs/proxying-api-requests-in-development/) I'll close this while I think a little bit more about it, but this might be something we can't solve. Feel free to keep the discussion here though, I still want to figure out a solution so we can at least update our documentation. |
Hmm OK, that's sad, how about adding a message / ℹ️ button there somewhere to make clear to the user, that whatever one set's up in studio besides a 204 with an empty body on the options call can not be mocked by the built in server? My confusion in the beginning came from reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS that states that a successfull response can have a body and the response code is not limited to 204 - and I can set it up in stoplight that way, so I had guessed that the mockserver handles it consistently just as any other request. Yes we are using create react app - so we can proxy that to a different server, but that would mean we can't work together with the API developers via stoplight on OPTIONS calls but would have to wait until they deployed their changes on the options call to an internal test server that can handle it correctly. |
The documentation should explain that already (see cors.md file).
Ok interesting, it seems that maybe we can melt the two responses together (and the browser would understand that it's both to accept the request and return its response. I will check it out and see if we can make it happen.
My idea was that you could in meantime proxy the request from Create-React-App to Prism directly so you would request stuff from the same domain — and so you could disable the cors ( |
So for the browser also a different port from localhost to localhost is CORS so I need to fiddle around a bit to see how I can trick it to think it's still the same domain. |
Hmm I fail to understand the difficulty. If CRA is serving your app on localhost:3000 you can set it up to do localhost:3000/api to localhost:4010 and on that 4010 port there would be Prism responding for you. Am I making sense? |
Ahh yes of course, sorry my bad. Will try that out |
@Primajin Can you try out this branch and see if that fixes your use case? I've been reading the spec and apparently there's a reliable way to detect a preflight request. I've tried with your codesandbox and it seems ok, however I'd like to get back from you first. |
User story.
As a frontend developer, I want to connect to the local mock server, so that I can see mocked responses in my browser.
Is your feature request related to a problem?
I can not connect to the mock server via a secure browser, as the CORS Headers are not set up correctly to allow any origin and any verb (OPTIONS, GET, POST, PATCH, etc.)
Describe the solution you'd like
The stoplight client mock server is sending out widely set CORS headers to allow any origin and any verb - or it allows me to configure it myself.
Additional context
![Screenshot 2020-03-03 at 09 55 02](https://user-images.githubusercontent.com/1742115/75758992-1da19500-5d35-11ea-8f3a-8cc8a963b3a9.png)
The text was updated successfully, but these errors were encountered: