klaustrainer / couch_email_auth Goto Github PK

Currently, the GET request fails with an error if the redirectLocation configuration is not specified. If no redirectLocation is specified, the server should respond with status code 200 and return the response body from the request to CouchDB's /_session endpoint.

Currently, any existing CouchDB authentication cookie is invalidated as soon as a new authentication token is generated (also see issue #38). Aside from the problem that is described in issue #38, this prevents users from being authenticated in two different browsers at the same time (i.e., they have to re-authenticate every time they switch browsers). As frequently using the same web site with different browsers is a common use-case these days (think switching between different devices), this is a serious design flaw.

At some point we should add docs

As a user, I want to have an easy way to customize the emails.

Suggestion: https://github.com/dominictarr/rc

If Bob knows Alice's email address, he could invalidate Alice's authentication cookie by sending an HTTP POST-request that has Alice's email address as email parameter value.

The problem is that even when Bob is only pretending to sign in as Alice, by just sending a POST-request containing Alice's email address as email parameter value, any authentication cookie that may be in use by Alice is invalidated as well.

TODOs (in this order):

• test 1: reproduce the issue
• test 2: proof that the issue is fixed (it must be failing at this point)
• bugfix: test 1 must fail, and test 2 must pass
• cleanup: remove test 1 (which is now obsolete)

As there's no sane way to know the client request's URI scheme (http or https), we need a respective configuration.

Hapi helps alot writing maintanable code and takes care of alot of things we are currently missing like protection against aborted requests or client request timeouts

http://hapijs.com/api

It is quite unconventional in JavaScript-land to have underscored file and module names. We should therefore change the project and module name to couch-email-auth (and file names accordingly), in order to not look too strange.

Sometimes it is desirable to always have a username, and not just an email address. There should be a configuration option that enables the validation of the presence of a username.

One example is the signin-link: https://github.com/KlausTrainer/couch_email_auth/blob/master/lib/server.js#L100

As an application developer, I'd like to provide the redirect location as request parameter, in order to be able to use couch_email_auth with multiple applications.

For security reasons, this should come along with a whitelist of domains that are allowed in redirect locations.

This implies getting rid of the redirectLocation configuration option.

Let's provide support for email by default, but if I want to send SMS I should be able to plug that functionality in. This might conflict with some parts of #23

Instead of sending a response with status code 200, the server should send status code 302 and set the Location header to value that is retrieved from the configuration.

TODO:

• introduce correspondent configuration (e.g. redirectLocation)
• change the HTTP response accordingly

Its meaning should also be documented at least in the default configuration. For instance:

tokenExpirationTime = 1 ; the time in seconds an authentication token (which is part of the sign-in link) is valid

If browsers don't accept third-party cookies and requests to the couch_email_auth endpoint are cross-origin, clients should still be possible to set the AuthSession cookie themselves.

We should optionally add the respective AuthSession query parameter to the redirectUrl in the response after following the sign-in link, so that clients can set the AuthSession cookie themselves.

If an essential requirement is missing, the service should stop immediately (i.e., at start time) rather than causing problems later. That is, we should provide sensible defaults where possible and have as few requirements as possible. However, there are some prerequisites that we can't provide, and that users have to make sure are available (e.g. the configuration of the address in the "From" header in the email).

TODO: Define which requirements are essential.

write a blogpost for the couchdb news / blog

As a user, I want to have an easy way to configure the SMTP options.

Suggestion: https://github.com/dominictarr/rc

Changing the usernames (i.e., the name field in the CouchDB user document) to be of the format some.host/[email protected] will allow us to scope authentication to individual domains.