Github user KlausTrainer commented on the pull request:
https://github.com/apache/couchdb/pull/366#issuecomment-155241623
I'm all +1 for making authentication and authorization more flexible
(and thereby more powerful), given that we don't compromise on security.
This is a nice and simple feature, and I don't see a reason to not
support it.
The feature is complementary to proxy authentication in the following
ways:
1) It can be used without a proxy.
2) A corresponding user document is required for successful
authentication.
3) There is a possibility to invalidate all of a particular user's
authentication cookies. (This can be achieved e.g. by setting the
`password` field when updating the user document. This works even if
the password doesn't get changed at all.)
I also have a use case for the feature.
Together with @robertkowalski, I've been working on a small plugin that
provides passwordless authentication by sending the authenticating user
a sign-in link via email [1]. The sign-in link contains an
authentication token, which gets exchanged for a CouchDB authentication
cookie the first time a user follows the sign-in link. Thereby, we want
to make sure that that every authentication token can only be used once,
and that for a given user there can only be one valid authentication
token at a time.
Previously, we would always set a new password for each sign-in, and
thereby involuntarily invalidate all authentication cookies for that
user when creating a new authentication token. This is big show-stopper
given the fact that people nowadays tend to switch between different
devices all the time. Not being able to authenticate with more than one
browser at a time is not acceptable. Aside from that, we however still
want to make it possible to invalidate all of a particular user's
authentication cookies.
Although we found a solution that matches our requirements, it took us
quite some time. Implementing the same functionality would have been way
easier if this feature had been available. The resulting code would be
less complex and therefore easier to understand. I guess I don't need to
explain why this is critical when dealing with sensitive stuff like
authentication.
[1] https://github.com/KlausTrainer/couch_email_auth
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
