that was it. As an option, I don't think it's a problem. I'd review a Pull Request that brought this in.
B. > On 6 May 2020, at 19:56, Jan Lehnardt <[email protected]> wrote: > > > >> On 6. May 2020, at 20:15, Damjan Georgievski <[email protected]> wrote: >> >> On Wed, 6 May 2020 at 16:40, Robert Samuel Newson <[email protected]> wrote: >>> >>> Make an issue (https://github.com/apache/couchdb/issues) >>> >>> At first blush, I don't see why not, though I thought there was value in >>> Authorization: Bearer <token> from _not_ being a cookie. I guess those >>> benefits >>> are not coupled with the token itself though. >> >> I think the reasoning was that cookies can be long lived, and can >> persist in different places, >> and for JWTs that's generally undesirable. the Authorization: header >> is explicitly set by code, and shouldn't be persisted. > > Plus browsers auto-sending cookies in many occasions when you don’t > want that. I forget the correct web security acronym this comes out to, > but it’s somewhere in the family of XSRF and XSS. > > Best > Jan > —
