Validation, Authentication, and Authorization

[zoe-1]

Objectives

• Use joi to validate submitted POST data.
• Gain basic understanding of the hapijs request lifecyle.
• Understand hapi-auth-cookie authentication and authorization
  • strategies
  • sessions and cookies
  • scopes
• Implement simple RBAC (role based access controls) using hapi's scopes to implement an authorization scheme.
• Make basic login and logout functionality.
• Configure application to handle bad route requests.
• Begin designing an api to support multiple clients.

  Study Helps

If you read the assignment requirements and do not know where to start then go to: the study helps. Or, view this sample hapi-auth-cookie project . It is written using ES6 JavasScript and uses hapi v13 so it is an up-to-date example.

Cookie-based session management.

Configure hapi-auth-cookie for cookie-based session management. Every route will be black listed requiring authentication and authorization globally. White list public routes. Make two user roles for basic RBAC authorization:

• "admin" the super user
• and "user" basic user

There will be three types of authorization restrictions:

• "public" routes open to all
• "user" routes restricted to authenticated users with the role of "user" or "admin".
• "admin" routes restricted to authenticated users with the role "admin".

  Login Process

We created the GET /login route in assignment6. This route is to be open to the public. When the user clicks the submit button on the HTML form, client side JavaScript should handle the submission and make an AJAX POST request. If the POST request is successful, the login form should disappear and user is presented with links to access restricted content /account or /logout. At this stage the login process is complete, session cookies are set, and authorized users can begin to access restricted content.

If the login AJAX request fails, a red HTML format error message is displayed above the login form. If the user clicks submit again the error message should disapear. Bonus: Add clientside logic to avoid duplicate form submissions.

api first steps

Building towards a client-server architecture for an application that serves multiple clients. Begin building the api:

• Make an 'api' label along with the web-tls connection.
• Make a ./lib/api directory.
• Make a ./lib/api/login.js
  • Make POST ./login route in this directory.
  • configure this plugin to use hapi-auth-cookie and begin the session upon successful login.
  • handle AJAX POST request at ./login route.

    Restricted Access Content

    The /account route

After a successful login, user sees "My Account" link and "Logout" link. The "My Account" link goes to the /account route which is restricted to authenticated users with roles of "user" or "admin". The /account route will display a page with the username of the logged in user and the following links: "Logout", "Home", and "Admin Panel" (if user has admin privileges). Correspondingly, the previous mentioned links point to /logout, /home, and /admin.

The /admin route

The /admin route should display an admin welcome message with the admin's username displayed. Plus, there should be three links: "My Account", "Logout" , "Home". Only users with the role of "admin" should be able to access /admin route.

The /home route

If a logged in user goes to /home, "My Account" and "Logout" links are displayed along with the hapi university image. When a user clicks on the "My Account" link they are taken to the /account route described above. If user is not logged in the login link is displayed.

Logging Out

On /home, /account, and /admin routes there should be a logout button which links to /logout and destroys the session. Plus, the /login POST route should have a "Logged out" message displayed after the logout AJAX request successfully completes.

Other Technical Details and Refactoring:

When configuring the application to use hapi-auth-cookie

• Remove hapi-auth-basic from the application. Remove the private plugin too.
• Make plugin: ./lib/auth-cookie.js which:
  • Configures hapi-auth-cookie authentication strategy to project.
  • redirects to '/login' route if the user is not logged in.
  • Requires the use of tls.
  • ttl: 60 * 100 or greater.
  • Configure the strategy to use tls.
  • Apply this auth strategy to every route in the application. White list the routes that do not require authentication or authorization.
• When creating the session cookie with hapi-auth-cookie do not put sensitive user account data (i.e. passwords) in the session cookie. Before creating a session, use Hoek to clone the account data JSON object then delete passwords from the newly cloned object. Once secure data is removed create the user's session with: request.auth.session.set(account).
• Use scopes to control which authenticated users are authorized to use the specific routes. First steps toward RBAC (role based access controls).
• Refactor ./lib/users.json to have user records like below. Most importantly user records must now have the scope array for RBAC.

 "foo": {
        "id": 1,
        "username": "Foo Foo",
        "password": "foo",
        "email": "foo@hapiu.com",
        "scope": ["user", "admin"]
    },

• Configure restricted routes to redirect to the /home, if the user is not authenticated or authorized to view the page.
• (Optional) When handling /login POST requests use poeticninja 's style of using a JavaScript Promise to authenticate users. Important, use bluebird to make promises, otherwise, node.js v0.10.0 will fail. It cannot handle plain JavaScript promises.
  • Use boom to return authentication errors. Follow poeticninja's way of using boom.
• Add bad route handling to project. Configure a server.ext('onPreResponse') to redirect to /home when routes do not exist. {"statusCode":404,"error":"Not Found"}
• Add unauthorized access attempt handling to the project. If a logged in used attempts to view a page not authorized to access, user is redirected to /home. Hint: this is the related error info. "statusCode":403,"message" and "Insufficient scope..."
• joi validation All POST request payloads must be validated by joi.
• Optional: feel free to use JQuery on the client if you want to.
• Last but not least, 100% test coverage required.

  Due Date July 7, 2015

The work required to master the content of this assignment will reap benefits over the long run. hapi's authorization and authentication logic is powerful and beautiful. :-) Let's push each other to work hard and make this assignment a great learning experience!

[zoe-1]

Assignment7 Important Modifications

• Changed Promise logic to use bluebird to get node.js v0.10.0 tests to pass (per @mindbits recommendation). When building this project did not test v0.10.x of node.js. After making the PR, travis failed because v0.10.x cannot use JavaScript Promises. originally, made a quick fix and removed Promise logic from the project. In the end, added bluebird to the project and node.js v0.10.0 was then Ok.
• Updating hapi and lab packages causes stricter validation rules.
  Travis uses the latest validation rules so we should use them too. After updating lab you will have to add a .eslintrc file to your project. To avoid linting errors related to: no-shadow-relaxed issues. See my PR for example solution.

[zoe-1]

How to extend default linting options

hapijs lab uses eslint to lint JavaScript files. Default configurations for linting are found here: ./node_modules/lab/lib/linters/eslint/.eslintrc You can extend or modify linting configurations by putting a .eslintrc file in the root of your project. See: eslint's documentation and look at my .eslintrc file for examples of extending default linting options. Plus, see @AdriVanHoudt 's comments at this post: hapijs/lab#372

[AdriVanHoudt]

I am open to any eslint questions!

[zoe-1]

Due date extended to July 7, 2015. Original due date was June 28, 2015.

@AdriVanHoudt Thank you for being willing to help with the linting :-)

[AdriVanHoudt]

np I don't have time for the assignments so I try to help where possible

[ghost]

@AdriVanHoudt Can you explain the no-shadow-relaxed

[AdriVanHoudt]

@rwobben the standard no-shadow was too strict, shadowing things like err and done have a really small chance of messing things up and changing it makes the code less readable so @geek made a relaxed version