-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Proposal: Parameters in cookie #161
Comments
We actually thought about adding support for cookie parameters, but honestly, I'm not sure how that translates to the request. Would would the HTTP request look like in your example above? |
Here's an example HTTP request:
Notice that there are several third-party cookies in there, as well as my API cookie (
|
Okay, thank you for the clarification. I should probably hunt down and see if there's any RFC or other standard that defines it. If you know of anything specific, feel free to share. |
If we are adding cookies to parameters we should add it to response object too. That would help tooling test responses more accurately |
definitely +1 |
+1, we just ran into that issue and was quite surprised by the lack of cookies support |
Parent: #565. |
Example in the wild of cookie-based auth in Wordpress API http://v2.wp-api.org/guide/authentication/#cookie-authentication |
Cookies do not fit into the REST model of resources and their manipulation with HTTP operations, as they introduce some kind of session state hold by the client and sent back to the server – instead all needed state should be in the resource representations retrieved and the links in them to other resources (i.e. the hypermedia). I guess cookies used as authentication are a border case which might be needed sometimes – but there is #15 for that. |
@ePaul - I agree that it's bad practice to use cookies for state or resource representations. But using them for authentication is common practice and should be supported by Swagger, IMHO. There are two scenarios in which Cookie parameters are needed, both having to do with cookie-based authentication:
|
@ePaul I agree with @BigstickCarpet with his use cases, and would like to add another: if I were to document a third party API using OpenAPI / Swagger, I don't get to choose whether they apply a "pure" REST model or use cookies for authentication, state, etcetera. Although the use of cookies should not be encouraged, it would be nice to be able to document as much as possible about an API - which would include (to some degree) the underlying HTTP mechanisms available. |
@BigstickCarpet @gmta I'm very interested in documenting third party APIs, my entire project build around this concept. But at the same time, if we start adding all features available in the wild, core spec became huge and hard to fully implement. And the worse possible case is then developers will start doing partial or "light-weight" implementations. Which exactly story behind CORBA failure. So I think two questions which I asked earlier is the minimal threshold for adding non-standard REST practices in the core spec. |
For public APIs, cookie-based auth doesn't seem to be as common as other options, such as OAuth. But it's used very frequently for enterprise APIs, b2b APIs, and single-sign-on solutions. There are even some popular public APIs that use cookie-based auth, such as the ones that @jasonh-n-austin posted the other day |
Closed as cookie support was added. |
Currently, the only way we can define a cookie parameter is like this:
But that just requires a cookie - any cookie - to be present. There's no way to distinguish between third-party cookies (e.g. google analytics, advertising, etc.) and our API's cookies. It would be nice to be able to do this:
The text was updated successfully, but these errors were encountered: