|
1 | 1 | # AngularJS + Express Full Stack Generator |
2 | 2 |
|
3 | | -A MEAN stack generator for Yeoman, Angular Fullstack scaffolds applications with MongoDB, Express, AngularJS, Node, and a lot of customization. |
| 3 | +Yeoman generator for creating MEAN stack applications, using MongoDB, Express, AngularJS, and Node. |
4 | 4 |
|
5 | 5 | Featuring: |
6 | 6 |
|
7 | 7 | * Express server integrated with grunt tasks |
8 | 8 | * Livereload of client and server files |
9 | 9 | * Support for Jade and CoffeeScript |
10 | 10 | * Easy deployment workflow. |
11 | | - * MongoDB integration |
12 | | - * Passport integration for adding user accounts |
| 11 | + * Optional MongoDB integration |
| 12 | + * Optional Passport integration for adding user accounts |
13 | 13 |
|
14 | 14 | ## Example project |
15 | 15 |
|
@@ -84,6 +84,30 @@ We provide an extremely simplifed deployment process for heroku. |
84 | 84 |
|
85 | 85 | That's it! Your app should be live and shareable. Type `heroku open` to view it. |
86 | 86 |
|
| 87 | +## Setting up Route authorization |
| 88 | + |
| 89 | +If your app uses the Passport boilerplate for accounts, you'll of course want to restrict access to certain client routes/api routes. |
| 90 | + |
| 91 | +For protecting server API routes, we can use the `auth` middleware, which will send a 401 unauthorized error if a user makes a request without being logged in. |
| 92 | + |
| 93 | +For protecting client routes, we automatically handle 401s sent from the server by redirecting you to the login page. |
| 94 | + |
| 95 | +However, as this will load part of the page before redirecting, it will cause a flicker. So this should only be used as a fallback mechanism. A better way to handle restricted pages is to mark the routes on the client side that you want to require authentication for. |
| 96 | + |
| 97 | +You can easily do this from your `app.js` by adding the following to any client routes that need protecting. |
| 98 | + |
| 99 | + authenticate: true |
| 100 | + |
| 101 | +This redirects the user to the login page before attempting to load the new route, avoiding the flicker. |
| 102 | + |
| 103 | +Please keep in mind this client routing is only for improving the **user interface**. Anyone with chrome developer tools can easily get around it and view pages they're not supposed to see. |
| 104 | + |
| 105 | +This is not a problem as long as you **secure your server API** routes, ensuring that you don't give any sensitive information unless the user is authenticated or authorized. |
| 106 | + |
| 107 | +#### How do I only let users authorized access an api route? |
| 108 | + |
| 109 | +Similarly to how the `auth` middleware checks if a user authenticated before going to the next route, you could easily make an ensureAuthorized middleware that checks the users role, or some other field, before sending them to the protected route, otherwise it sends a `403` error. |
| 110 | + |
87 | 111 | ## Generators |
88 | 112 |
|
89 | 113 | Available Angular generators: |
|
0 commit comments