[
https://issues.apache.org/jira/browse/COUCHDB-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15298610#comment-15298610
]
Joop Ringelberg commented on COUCHDB-3020:
------------------------------------------
I would like to retract this issue.
I moved server-side NodeJS code to the browser. Server side, the 'Set-Cookie'
header can be read and, indeed, must be readable in order to be able to catch
the session token and return it to the database on new requests in a 'Cookie'
header. However, in a browser client this is, obviously, handled automatically.
Thus, browser-run code has no need for the 'Set-Cookie' header. Not to be able
to retrieve the session cookie then becomes a security bonus instead of an
issue.
My apologies for the confusion.
> Allow Set-Cookie header in CORS response
> ----------------------------------------
>
> Key: COUCHDB-3020
> URL: https://issues.apache.org/jira/browse/COUCHDB-3020
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Reporter: Joop Ringelberg
>
> Even if 'Set-Cookie' is added to the headers section of the CORS
> configuration , a response will NOT include it in the
> 'Access-Control-Expose-Headers' header. This means it is not possible to
> capture the AuthSession cookie in client code, even though CouchDB actually
> sends a Set-Cookie header. This is conform the 'fetch' specification
> (https://fetch.spec.whatwg.org/#cors-protocol, see 4.2.5 CORS protocol and
> credentials).
> It seems to me that this behaviour results from couch_httpd_cors.erl, lines
> 25 through 28, where the SUPPORTED_HEADERS variable is defined. This variable
> is used to filter the content of the headers section of the CORS
> configuration. It does not hold 'Set-Cookie'.
> Hence, my request is that this particular header is added to that variable.
> Regards, Joop
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
