fluid-express-user
v2.0.3
Published
A series of Fluid components to provide simple user management.
Downloads
15
Keywords
Readme
fluid-express-user
This package provides a series of server and client-side Fluid components to provide simple user management, including:
- Login, logout, and "current user" mechanisms.
- A "signup" mechanism to allow users to create accounts themselves. Accounts must be associated with a valid email to be complete the setup.
- A "forgot password" mechanism that sends the user a custom link via email that can be used to reset their password.
Server Side Components
The server side components are intended to be used with a fluid.express
instance, and provide the REST API endpoints
documented in src/docs/api.md
. Before you can use the server side components, you must set up your database with the
views included in src/views
(see that directory for details).
When writing your own server-side components that depend on the current user's information, the current user will
always be available as part of the request.session
object. The user key may change depending on your configuration,
by default the user is found at request.session._fluid_user
.
Client Side Components
The client-side components provided here are intended to be used with the server-side API running on the same hostname and port that hosts the client-side content. No CORS, proxy, or other mechanism is provided to handle remote lookups.
To use the client side components, set up your fluid.express
instance with a static handler that will serve up the
contents of src/js/client
, and a fluid.express.hb
instance that can serve up the required template content. It is
recommended that you copy the sample template content found in src/templates
to your template directory and customize
based on your specific needs.
For an example of both the server-side configuration and of serving up client-side content, check out the configuration
of tests/js/launch-test-harness.js
and tests/js/test-harness.js
,
Tests
To run the tests in this package, use the command npm test
.
The tests in this package make use of fluid-couchdb-test-harness.
By default that package uses Docker to run the tests. To use Vagrant instead, set the environment variable
FLUID_TEST_COUCH_USE_EXTERNAL
to true
. To use a standalone instance of CouchDB (which must run on port 25984
),
set the environment variable FLUID_TEST_COUCH_USE_EXTERNAL
to true
. For the full list of supported environments,
software requirements, and configuration options, see the documentation for fluid-couchdb-test-harness.
The browser tests in this package make use of fluid-webdriver,
which requires you to install the appropriate version of chromedriver
(Chrome), geckodriver
(Firefox), et cetera.
Chrome in particular has issues when its version does not exactly match the version of chromedriver
installed. For
more information about the requirements for running the browser tests, see the fluid-webdriver documentation.
Migrating from Version 1 to Version 2
Version 1 of this package was designed to tightly mimic the user record structure and password encoding of early versions of CouchDB. Version 2 no longer supports this use case. To migrate from version 1 to version 2, you will need to make a few key changes to your record structure:
- You will need to remove the
org.couchdb.user:
prefix from all IDs. - You will need to add the previous default value for
digest
("sha1
") to each record. - You can safely remove the
name
field from all records. - All other fields should remain the same.
To give a concrete example, here is a record from version 1:
{
"_id": "org.couchdb.user:sample",
"type": "user",
"name": "sample",
"username": "sample",
"derived_key": "dd11a6d074786fc914cbcdbc7ec5a06ad002812a",
"salt": "secret",
"iterations": 10,
"email": "sample@localhost",
"roles": ["role1", "role3"],
"verified": true
}
Here is the same record updated for compatibility with version 2 of this package:
{
"_id": "sample",
"type": "user",
"username": "sample",
"derived_key": "dd11a6d074786fc914cbcdbc7ec5a06ad002812a",
"salt": "secret",
"digest": "sha1",
"iterations": 10,
"email": "sample@localhost",
"roles": ["role1", "role3"],
"verified": true
}
One way to migrate all records would be to make use of the CouchDB bulk API endpoints:
- Take a backup of your existing user database.
- Download all existing records including design document(s).
- Convert the download format into the format used by the CouchDB
_bulk_docs
endpoint. - Update all records as outlined above (
digest
,_id
,name
fields). - Remove your existing records.
- Submit the updated records using the
bulk_docs
endpoint.