express-user - npm Package Compare versions

Comparing version 0.0.1-alpha.15 to 1.0.0

lib/ExpressUser.js

@@ -5,21 +5,3 @@ //Copyright (c) 2015 Eric Vallee <[e-mail]>
 var Express = require('express');
-var AccessControl = require('express-access-control');
 
-function ConnectionCheckGenerator(Check) 
-{
-    return(function(Req, Res, Next) {
-        if(!Check(Req))
-        {
-            var Err = new Error();
-            Err.Source = "ExpressUser";
-            Err.Type = "InsecureConnection";
-            Next(Err);
-        }
-        else
-        {
-            Next();
-        }
-    });
-}
-
 function GetRoutingVars(Req, Res, Next, Callback)
@@ -83,3 +65,13 @@ {
                 {
-                    Next(Err);
+                    if(Err.UserStore && Err.UserStore.Name == 'ConstraintError')
+                    {
+                        var Err = new Error();
+                        Err.Source = "UserStore";
+                        Err.Type = "StoreConstraint";
+                        Next(Err);
+                    }
+                    else
+                    {
+                        Next(Err);
+                    }
                 }
@@ -196,3 +188,3 @@ else if(Result==0)
     return(function(Req, Res, Next) {
-        if(!Req.session.User)
+        if(!(Req.session&&Req.session.User))
         {
@@ -262,43 +254,10 @@ var Err = new Error();
 {
-    var ConnectionSecurity = Options && Options.ConnectionSecurity ? Options.ConnectionSecurity : function(Req) {
-        return((Req.ip=='127.0.0.1')||Req.secure);
-    };
     var Validator = Options && Options.Validator ? Options.Validator : null;
     var Responder = Options && Options.Responder ? Options.Responder : null;
-    var Roles = Options && Options.Roles ? Options.Roles : {'Edit': ['Admin'], 'Delete': ['Admin'], 'Get': ['Admin']};
     
     var Router = Express.Router();
     
-    if(ConnectionSecurity)
-    {
-        Router.use('/Users', ConnectionCheckGenerator(ConnectionSecurity));
-        Router.use('/User', ConnectionCheckGenerator(ConnectionSecurity));
-        Router.use('/Session/Self/User', ConnectionCheckGenerator(ConnectionSecurity));
-    }
-    
-    Router.patch('/User/Self', AccessControl.AuthenticateRoute());
-    Router.delete('/User/Self', AccessControl.AuthenticateRoute());
-    Router.get('/User/Self', AccessControl.AuthenticateRoute());
-    Router.post('User/Self', AccessControl.AuthenticateRoute());
-    
-    if(Roles&&Roles.Edit)
-    {
-        Router.patch('/User/:Field/:ID', AccessControl.AuthenticateRoute(Roles['Edit']));
-        Router.put('/User/:Field/:ID/Memberships/:Membership', AccessControl.AuthenticateRoute(Roles['Edit']));
-    }
-    
-    if(Roles&&Roles.Delete)
-    {
-        Router.delete('/User/:Field/:ID', AccessControl.AuthenticateRoute(Roles['Delete']));
-        Router.delete('/User/:Field/:ID/Memberships/:Membership', AccessControl.AuthenticateRoute(Roles['Delete']));
-    }
-    
-    if(Roles&&Roles.Get)
-    {
-        Router.get('/User/:Field/:ID', AccessControl.AuthenticateRoute(Roles['Get']));
-    }
-    
     if(Validator)
     {
-        Validator(Router, Options.Roles);
+        Validator(Router);
     }
@@ -308,5 +267,8 @@
     Router.patch('/User/Self', MainRoutes.UserPATCH(UserStore));
+    Router.patch('/User/:Field/:ID', MainRoutes.UserPATCH(UserStore));
     Router.post('/User/Self/Recovery/:SetField', MainRoutes.UserPATCH(UserStore));
     Router.delete('/User/Self', MainRoutes.UserDELETE(UserStore));
+    Router.delete('/User/:Field/:ID', MainRoutes.UserDELETE(UserStore));
     Router.get('/User/Self', MainRoutes.UserGET(UserStore));
+    Router.get('/User/:Field/:ID', MainRoutes.UserGET(UserStore));
     Router.get('/Users/:Field/:ID/Count', MainRoutes.UsersCountGET(UserStore));
@@ -316,21 +278,6 @@ Router.post('/User/:Field/:ID/Recovery/:SetField', MainRoutes.UserPATCH(UserStore));
     Router.put('/User/Self/Memberships/:Membership', MainRoutes.UserMembershipsPUT(UserStore));
+    Router.put('/User/:Field/:ID/Memberships/:Membership', MainRoutes.UserMembershipsPUT(UserStore));
     Router.delete('/User/Self/Memberships/:Membership', MainRoutes.UserMembershipsDELETE(UserStore));
+    Router.delete('/User/:Field/:ID/Memberships/:Membership', MainRoutes.UserMembershipsDELETE(UserStore));
     
-    if(Roles&&Roles.Edit)
-    {
-        Router.patch('/User/:Field/:ID', MainRoutes.UserPATCH(UserStore));
-        Router.put('/User/:Field/:ID/Memberships/:Membership', MainRoutes.UserMembershipsPUT(UserStore));
-    }
-    
-    if(Roles&&Roles.Delete)
-    {
-        Router.delete('/User/:Field/:ID', MainRoutes.UserDELETE(UserStore));
-        Router.delete('/User/:Field/:ID/Memberships/:Membership', MainRoutes.UserMembershipsDELETE(UserStore));
-    }
-    
-    if(Roles&&Roles.Get)
-    {
-        Router.get('/User/:Field/:ID', MainRoutes.UserGET(UserStore));
-    }
-    
     Router.put('/Session/Self/User', MainRoutes.SessionUserPUT(UserStore));
@@ -341,3 +288,3 @@ Router.delete('/Session/Self/User', MainRoutes.SessionUserDELETE(UserStore));
     {
-        Responder(Router, Options.Roles);
+        Responder(Router);
     }
@@ -344,0 +291,0 @@

package.json

 {
   "name": "express-user",
-  "version": "0.0.1-alpha.15",
+  "version": "1.0.0",
   "description": "Ressource Oriented Express Middleware to Manage Users.",
@@ -27,6 +27,12 @@ "keywords": [
   "dependencies": {
-    "express": "~4.10.6",
-    "express-access-control": "~1.0.0"
+    "express": "~4.10.6"
   },
-  "devDependencies": {},
+  "devDependencies": {
+    "body-parser": "^1.12.2",
+    "express-session": "^1.10.4",
+    "express-session-mongodb": "^1.3.3",
+    "mongodb": "^1.4.35",
+    "nodeunit": "~0.9.0",
+    "user-store": "^1.3.0"
+  },
   "license": "MIT",
@@ -37,4 +43,4 @@ "directories": {
   "scripts": {
-    "test": "echo \"Error: no test specified\" && exit 1"
+    "test": "./node_modules/nodeunit/bin/nodeunit test"
   }
 }

README.md

@@ -6,21 +6,16 @@ Express-User
 
-Status
-======
+Overall Architecture
+====================
 
-The library is in prototype stage at this point. It is untested (beyond basic manual tests) and I'll postpone the writing of automated tests until the API is relatively final.
+The express-user relies on the following architecture:
 
-The API is very likely to change due to:
+Validator: performs access-control and input-validation. See express-user-local for a flexible implementation of traditional local authentication.
+Store: Interacts with the user store. This is this project.
+Responder: handles responding to the client and custom tasks (ie, sending emails, etc) before responding. See express-user-local-basic for a barebone implementation using local authentication.
 
-- My eventual desire to decouple the response logic (return codes and content + logging) from the rest of the library in order to allow for specialized response plugins (ex: HTML forms, single-page clients with Ajax, collection+JSON hypermedia, etc)
+These 3 components communication with each other using predefined express routes and by accessing and manipulating the response.locals.ExpressUser object.
 
-- While I do not foresee that many architectural changes for this, I do not rule them out entirely as I integrate the following features in my web applications:  email verification.
+Routes
+======
 
-Known Bug(s)
-============
-
-...
-
-URL Map
-=======
-
 1) Universal URLs:
@@ -46,76 +41,161 @@ - POST /Users -> Account creation
 
-Architecture
-============
+Note: Admin URLs is a suggestion here of URLs that I think should be restricted to superusers. To increase flexibility and provide a clearer separation of concerns among components, the enforcement of that restriction is delegated to the validator.
 
-Express-User relies on 2 components (eventually at least 3):
+Usage
+=====
 
-- express-user itself that does the following: 
+Constructor
+-----------
 
--secure connection checking (HTTPS or local)
+...
 
--Access control: privilege check to ensure the admin URLs are accessed by an admin and that the user is logged in when accessing the Self URLs
+TO DO
 
--Handle accout manipulation
+Session Route
+-------------
 
--Provide a routing callback for authentication (to check the user is either logged in or belongs to a given group)
+...
 
-- A validator (currently, the express-user-local npm repo implements validation for an email/username/password scheme)
+TO DO
 
-This component implements validation to check that requests contain all the expected information and in the right format.
+Example
+-------
+For a full implementation with local authentication and MongoDB for storage, see the example in the express-user-local project. 
 
-From there, it constructs the req.locals.ExpressUser.User (usually expected by express-user) and the req.locals.ExpressUser.Update (sometimes expected by Express-User) as needed.
+```javascript
+var Express = require('express');
+var Http = require('http');
+var ExpressUser = require('express-user');
+var BodyParser = require('body-parser'); //express-user doesn't require it, but your validator probably will
+var Session = require('express-session');
 
-It shouldn't handle traditional database validations (ie, does the username already exist) which should handled by a properly configured user-store.
+...
+//Initialize Validator, Responder and UserStore
+...
 
-Express-User passes an Express router to the validator which allows it establish validation routes.
+var App = Express();
 
-The entire achitecture relies heavily on Express routes to establish ordering of logic and communication between components.
+//You'll need to initialize your session store if you want sessions to be stored permanently
+App.use(Session({
+    'secret': 'qwerty!',
+    'resave': true,
+    'saveUninitialized': true,
+    'store': SessionStore
+}));
 
-Security Note About Validator
-=============================
+//In this example, the client would send the request bodies to the library's routes in JSON format
+App.use(BodyParser.json());
 
-At the database level, user-store provides some optional error-checking for user insertion (uniqueness, not null, hashing of password if present).
+//Initialize all the routes in proper order
+var UserRouter = ExpressUser(UserStore, {'Validator': Validator, 'Responder': Responder});
 
-Otherwise, the user-store I implemented is using MongoDB which is schema free and I took full advantage of this fact to make my implementation of user-store unbiased.
+//Route to ensure that a user's session will always be in sync with his info. It should be assigned to every path where a user's session is required. '/' is a good general default.
+//Here, '_id' is assumed unique field that is present for each user. This is the default ID field in MongoDB collections, but you'll probably want to change it if you use another database or your own custom ID field.
+App.use(ExpressUser.SessionRoute(UserStore, '_id'));
 
-Similarly, express-user, which provides Express routing and some access control on top of user-store and a user's session, is very flexible and has little bias.
+//Assign all the routes described above to the '/' base route. Alternatively, you could decide to assign to another base route like '/ExpressUser'. 
+App.use(UserRouter);
 
-This means that the vast majority of the bias concerning what your user fields should look like and what input various actions expect falls on the validator.
+//And... the rest should be business as usual :)
 
-As such, it should ensure that all the fields you expect for various actions (ex: password) are there and that their values follow whichever constraints you wish to place upon them.
+```
 
-You should be as conservative as your application domains allows concerning what you'll accept.
+API With Other Components
+=========================
 
-Also, you validator should ensure that for the route /Users/:Field/:ID/Count/, only publicly available information should be selectable for regular users (see express-user-local code for an implementation of this).
+Expected method
+---------------
 
-Finally, the validator should be very selective about what values of Membership it allows for the /User/Self/Memberships/:Membership routes.
+...
 
-Session Synchronization
-=======================
+TO DO
 
-For a smooth seemless functionality to users, sessions and user accounts they point to need to be in sync, such that when accounts are updated or deleted, this is reflected in sessions pointing to it.
+Intercomponent Communication: Input
+-----------------------------------
 
-The only implemented solution ais the ExpressUser.SessionRoute route, which should be placed after session initialization, but before any logic that uses sessions.
+express-user doesn't take any input from a request's body, from URL parameters or from the session. That's a validator's job. Rather, express-user take its input from the res.locals.ExpressUser object, which should be properly set by the validator.
 
-It returns a route, taking as arguments the user store and a string representing a constant field that will never change for a particular user (_id works if the database is MongoDB).
+The reason of this architecture is twofold: Make express-user more generic with a clear separate of concerns from the validator and make express-user more secure by blocking routes that haven't been processed by the validator, thus making it the default that anything you haven't defined in your validator is blocked.
 
-I didn't integrate this in the main express-user route so that you can place user/session synchronization on any path that uses sessions without being required to do same for the main express-user route.
+Below are the input expectations from various routes:
 
-For example, you might decide to set the base path of express-user's main route to /ExpressUser, but you should probably put session synchronization on /.
+- POST /Users
 
-Future Optimisation
--------------------
+res.locals.User: should contain the fields of the new user
 
-In the longer term, I'm considering implementing a read-only capability for express-session-mongodb which will allow us to implement the insurance that user info is never re-saved with the remainder of the session.
+- PATCH /User/Self and PATCH /User/:Field/:ID
 
-From there, sessions will be updated directly when users are updated/deleted (without fear of those changes being overwritted by session re-saves).
+res.locals.User: should contain the fields identifying the user to modify
+res.locals.Update: Should contain the new values of fields that are to be modified
 
-The advantages of this implementation would be to save a trip to the user store to read the user info for each request, at the cost of making profile updates and deletions more expensive operations (which would be ok since they are a lot rarer).
+- DELETE /User/Self and DELETE /User/:Field/:ID
 
-The disadvantages would be a greater dependency to my session-store (since other implementations are extremely unlikely to implement something like this with the same API) and sessions getting out-of-sync anyways in the case of a failure after the user is updated, but before sessions can be updated (since MongoDB is transaction free for complex operations of this nature)
+res.locals.User: Should contain the fields identifying the user to delete
 
-For the above reasons, when I get around to implementing this, it will be an optional feature.
+- GET /User/Self and GET /User/:Field/:ID
 
-Given that this would be an optimisation rather than a requirement for functionality, I'll probably finish functionality before I get around to implementing this.
+res.locals.User: Should contain the fields identifying the user to get
 
+- PUT /Session/Self/User
+
+res.locals.User: Should contain the fields identifying the user to store in the session
+
+- DELETE /Session/Self/User
+
+No input required. Will just delete the req.session.User, if present.
+
+- GET /Users/:Field/:ID/Count
+
+res.locals.User: Should contain the fields that define the users you wish to count
+
+- PUT /User/Self/Memberships/:Membership and PUT /User/:Field/:ID/Memberships/:Membership
+
+res.locals.User: should contain the fields identifying the user to modify
+res.locals.Membership: the membership you wish to add
+
+- DELETE /User/Self/Memberships/:Membership and DELETE /User/:Field/:ID/Memberships/:Membership
+
+res.locals.User: should contain the fields identifying the user to modify
+res.locals.Membership: the membership you wish to remove
+
+- POST /User/Self/Recovery/:SetField and POST /User/:Field/:ID/Recovery/:SetField
+
+res.locals.User: should contain the fields identifying the user to modify
+res.locals.Update: Should contain the new values of fields that are to be modified
+
+Intercomponent Communication: Output
+------------------------------------
+
+express-user doesn't respond to requests directly. Rather, it interacts with the responder by setting properties on the res.locals.ExpressUser object and by triggering error routes (ie, calling next(err)).
+
+Below are outputs for various routes:
+
+- All routes
+
+If res.locals.Express is not defined by the validator, an error route will be triggered with Err.Source having the value of 'ExpressUser' and Err.Type having the value of 'NotValidated'.
+
+If user-store returns an error that isn't a constraint error, an error route will be triggered and the error will be passed to it.
+
+- POST /Users
+
+If a constraint error is encountered (ie, unique or null constraint violated), an error route will be triggered with Err.Source having the value of 'UserStore' and Err.Type having the value of 'StoreConstraint'.
+
+If no error was encountered while manipulating the store, but the user was not inserted,  an error route will be triggered with Err.Source having the value of 'ExpressUser' and Err.Type having the value of 'NoInsertion'.
+
+Otherwise, no properties are set.
+
+- PATCH /User/Self and PATCH /User/:Field/:ID
+
+If a constraint error is encountered (ie, unique or null constraint violated), an error route will be triggered with Err.Source having the value of 'UserStore' and Err.Type having the value of 'StoreConstraint'.
+
+If no error was encountered while manipulating the store, but the user was not inserted,  an error route will be triggered with Err.Source having the value of 'ExpressUser' and Err.Type having the value of 'NoInsertion'.
+
+Otherwise, no properties are set.
+
+...
+
+- Further Note: that whatever is passed to express-user by the validator is also passed to the responder and if an error is encountered by the validator, it can bypass express-user entirely and go straight to the responder by triggering an error route.
+
+TO FINISH
+
 Dependencies
@@ -126,91 +206,145 @@ ============
 
-- A recent version of Express.js
+- A recent version of Express.js (version 4.x, the library uses Express.Router()) [1]
 
-- npm if you want the easy way to install this module.
+- Either the user-store project (and accompanying dependencies) or a user store that has the same API as the user-store project 
 
-[1] Later versions should also work. If you find it not to be the case, let me know.
+- A route to handle sessions that will initialize the req.session attribute. The express-session project will do this for you.
 
-Dependencies for out-of-box solution
-====================================
+- For an "out of the box" solution, you'll also need a validator and a responder. express-user-local and express-user-local-basic can provide those for you for local authentication.
 
-- User store:
+- The library uses the PUT, DELETE and PATCH HTTP methods, which are traditionally not supported in submitted HTML forms. If you use those, you'll need to use a library like method-override.
 
-This library expects a user store that outwardly behaves just like the user-store project for the Add/Get/Remove/Update methods.
+Security Note About Validator
+=============================
 
-You can use user-store (which uses MongoDB), or implement your own user store solution (from scratch or by writing a wrapper around an existing solution to conform to the expected API).
+At the database level, user-store provides some optional error-checking for user insertion (uniqueness, not null, hashing of password if present).
 
-- Session management:
+Otherwise, the user-store I implemented is using MongoDB which is schema free and I took full advantage of this fact to make my implementation of user-store unbiased.
 
-Additionally, this library also expects a session management library that behaves like express-session as far as the req.session variable is concerned.
+Similarly, express-user, which provides Express routing on top of user-store and a user's session, is very flexible and has little bias.
 
-Again, you can use express-session to get a working solution out of the box or implement your own solution (either from scratch or by writing a wrapper around another existing solution such that req.session behaves as expected).
+This means that the vast majority of the bias concerning what your user fields should look like, what input various actions expect and access control on routes fall on the validator.
 
-- Validator:
+As such, it should ensure that all the fields you expect for various actions (ex: password, email token, etc) are there and that their values follow whichever constraints you wish to place upon them.
 
-In order to remain flexible, this library leaves the implementation of request validation to you in terms of making sure that the right fields are submitted (plus any sanitation check)
+You should be as conservative as your application domains allows concerning what you'll accept.
 
-Currently, the traditional email/username/password validation scheme is implemented in this project: express-user-local
+Also, in most applications, you'll want to:
 
-- Request Body:
+- Restrict what fields a user can define with the POST /Users route
+- Restrict what fields a user can set with the PATCH /User/Self route
+- Restrict what fields a user can see with the GET /User/Self route
+- Restrict what memberships a user can add with the PUT /User/Self/Memberships/:Membership route
+- Restrict what memberships a user can remove with the DELETE /User/Self/Memberships/:Membership route
+- Make the Admin routes accessible only to superusers
+- restrict what fields a user can reset with the POST /User/:Field/:ID/Recovery/:SetField and POST /Self/:ID/Recovery/:SetField routes
+- restrict what fields a user can count with the GET /Users/:Field/:ID/Count
 
-This library expects req.body to be populated with the variables in the body of your request. The body-parser project can do this for you.
+For local authentication, the express-user-local project take all these things into consideration.
 
-- Methods:
+Also, any route that the validator doesn't handle will return a 'NoValidation' error by default (which can be caught by the responder), so you can simply forgo implementing the routes that you don't plan on using in the validator (but you still need to catch the error and return something like 404).
 
-If you are using HTML forms (which only support the GET and POST methods), you'll need a library like method-override to simulate other kinds of request methods (ie, PUT, PATCH, DELETE)
+Session Synchronization
+=======================
 
-- For a shortcut:
+For a smooth seemless functionality to users, sessions and user accounts they point to need to be in sync, such that when accounts are updated or deleted, this is reflected in sessions pointing to it.
 
-The dev-dependencies in the express-user-local project contain a complete stack for an out-of-the-box solution, minus the method handling of html forms.
+The implemented solution right now is the ExpressUser.SessionRoute route, which should be placed after session initialization, but before any logic that uses sessions.
 
+It returns a route, taking as arguments the user store and a string representing a constant field that will never change for a particular user (_id works if the database is MongoDB).
+
+I didn't integrate this in the main express-user route so that you can place user/session synchronization on any path that uses sessions without being required to do same for the main express-user route.
+
+For example, you might decide to set the base path of express-user's main route to /ExpressUser, but you should probably put session synchronization on /.
+
+Future Optimisation
+-------------------
+
+In the longer term, I'm considering implementing a read-only capability for express-session-mongodb which will allow us to implement the insurance that user info is never re-saved with the remainder of the session.
+
+From there, sessions will be updated directly when users are updated/deleted (without fear of those changes being overwritted by session re-saves).
+
+The advantages of this implementation would be to save a trip to the user store to read the user info for each request, at the cost of making profile updates and deletions more expensive operations (which would be ok since they are a lot rarer).
+
+The disadvantages would be a greater dependency to my session-store (since other implementations are extremely unlikely to implement something like this with the same API) and sessions getting out-of-sync anyways in the case of a failure after the user is updated, but before sessions can be updated (since MongoDB is transaction free for complex operations of this nature)
+
+For the above reasons, when I get around to implementing this, it will be an optional feature.
+
+Given that this would be an optimisation rather than a requirement for functionality, I'll probably finish functionality before I get around to implementing this.
+
 Example
 =======
 
-See express-user-local project for a working example using local authentication.
+See the example in the express-user-local project for a working example using local authentication.
 
-Future
-======
-
-More in-depth details to come once the API is finalized.
-
 Versions History
 ================
 
-0.0.0 
+1.0.0
 -----
 
-Initial prototype
+- Fixed a bug where session existence check wouldn't be performed for some of the Self routes
+- Moved access control on admin URLs to validator and removed Express-Access-Control as a dependency
+- Moved connection security verification to validator
+- Moved Roles constructor option to Validator
+- Added support for constraint errors on PATCH routes
+- Added dev dependencies to run unit tests
+- Started unit tests
+- Started final version of documentation
+- Updated dev dependency of user-store to version 1.3.0
 
-0.0.1-alpha.1
--------------
+0.0.1-alpha.15
+--------------
 
-Doc formating fix.
+- Changed POST /User/Self/:SetField and POST /User/:Field/:ID/:SetField routes to more semantically meaningful POST /User/Self/Recovery/:SetField and POST /User/:Field/:ID/Recovery/:SetField
 
-Changed session management URL from /Session/User to /Session/Self/User
+0.0.1-alpha.14
+--------------
 
-0.0.1-alpha.2
--------------
+- Added support for POST /User/Self/:SetField and POST /User/:Field/:ID/:SetField routes
+- Added support for Responder.
+- Replaced response logic by feedback to pass to Responder.
+- Removed GetSerializer and CountSerialized constructor options. Moved them to Responder.
 
-Update dev dependencies for express-user-local to version 0.0.1-alpha1
+0.0.1-alpha.13
+--------------
 
-0.0.1-alpha.3
--------------
+- Moved the responsability to manage which fields are hidden for 'GET' requests to the validator.
 
-- Updated dev dependencies for user-store to version 1.1.1
+0.0.1-alpha.12
+--------------
 
-- Modified bad input handling to take into account the more detailed constraint errors of user-store and return 400 rather than a 500 system error for submissions that violate constraints.
+- Added support for membership manipulation routes
 
-0.0.1-alpha.4
+0.0.1-alpha.11
+--------------
+
+- Moved example to express-user-local project
+- Removed dev dependencies tied to the example
+
+0.0.1-alpha.10
+--------------
+
+- Updated dev dependency of express-user-local to 0.0.1-alpha.7.
+- Modified example (client and server) to include csrf mitigation.
+
+0.0.1-alpha.9
 -------------
 
-Added session sychronization support
+- Updated dev dependency of express-user-local to 0.0.1-alpha.5.
+- Updated the client-side of the example to changes made to express-user-local.
 
-0.0.1-alpha.5
+0.0.1-alpha.8
 -------------
 
-- Moved access control logic into a separate module.
-- Changed the validator API a bit so that the validator can access Roles.
-- Updated user-store dependency to version 1.2.0.
-- Updated dev dependency of express-user-local to 0.0.1-alpha.2
+- Updated dev dependency of express-user-local to 0.0.1-alpha.4.
+- Added express-brute and express-brute-mongo to the dev dependencies
+- Augmented the example with brute-force mitigation
 
+0.0.1-alpha.7
+-------------
+
+- Fixed doc error
+- Added '/Users/:Field/:ID/Count/' consideration for validator security section of the doc.
+
 0.0.1-alpha.6
@@ -226,54 +360,37 @@ -------------
 
-0.0.1-alpha.7
+0.0.1-alpha.5
 -------------
 
-- Fixed doc error
-- Added '/Users/:Field/:ID/Count/' consideration for validator security section of the doc.
+- Moved access control logic into a separate module.
+- Changed the validator API a bit so that the validator can access Roles.
+- Updated user-store dependency to version 1.2.0.
+- Updated dev dependency of express-user-local to 0.0.1-alpha.2
 
-0.0.1-alpha.8
+0.0.1-alpha.4
 -------------
 
-- Updated dev dependency of express-user-local to 0.0.1-alpha.4.
-- Added express-brute and express-brute-mongo to the dev dependencies
-- Augmented the example with brute-force mitigation
+Added session sychronization support
 
-0.0.1-alpha.9
+0.0.1-alpha.3
 -------------
 
-- Updated dev dependency of express-user-local to 0.0.1-alpha.5.
-- Updated the client-side of the example to changes made to express-user-local.
+- Updated dev dependencies for user-store to version 1.1.1
 
-0.0.1-alpha.10
---------------
+- Modified bad input handling to take into account the more detailed constraint errors of user-store and return 400 rather than a 500 system error for submissions that violate constraints.
 
-- Updated dev dependency of express-user-local to 0.0.1-alpha.7.
-- Modified example (client and server) to include csrf mitigation.
+0.0.1-alpha.2
+-------------
 
-0.0.1-alpha.11
---------------
+Update dev dependencies for express-user-local to version 0.0.1-alpha1
 
-- Moved example to express-user-local project
-- Removed dev dependencies tied to the example
+0.0.1-alpha.1
+-------------
 
-0.0.1-alpha.12
---------------
+Doc formating fix.
 
-- Added support for membership manipulation routes
+Changed session management URL from /Session/User to /Session/Self/User
 
-0.0.1-alpha.13
---------------
+0.0.0 
+-----
 
-- Moved the responsability to manage which fields are hidden for 'GET' requests to the validator.
-
-0.0.1-alpha.14
---------------
-
-- Added support for POST /User/Self/:SetField and POST /User/:Field/:ID/:SetField routes
-- Added support for Responder.
-- Replaced response logic by feedback to pass to Responder.
-- Removed GetSerializer and CountSerialized constructor options. Moved them to Responder.
-
-0.0.1-alpha.15
---------------
-
-- Changed POST /User/Self/:SetField and POST /User/:Field/:ID/:SetField routes to more semantically meaningful POST /User/Self/Recovery/:SetField and POST /User/:Field/:ID/Recovery/:SetField
+Initial prototype

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Non-existent author

Supply chain risk

The package was published by an npm account that no longer exists.

Found 1 instance in 1 package

Network access

Supply chain risk

This module accesses the network.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

No tests

Quality

Package does not have any tests. This is a strong signal of a poorly maintained or low quality package.

Found 1 instance in 1 package

No v1

Quality

Package is not semver >=1. This means it is not stable and does not support ^ ranges.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

116770

increased by56.55%

Dependency count

1

decreased by-50%

Number of package files

16

increased by14.29%

Lines of code

665

increased by89.46%

Number of low quality alerts

1

decreased by-66.67%

Number of lines in readme file

393

increased by42.39%

Worsened metrics

Dev dependency count

6

increased byInfinity%

Number of high supply chain risk alerts

1

increased byInfinity%

Number of medium supply chain risk alerts

1

increased byInfinity%

Dependency changes

• - Removedexpress-access-control@~1.0.0

• - Removedexpress-access-control@1.0.0(transitive)