Skip to content

Commit afe28f5

Browse files
committed
docs(readme): cleaning up readme
1 parent f85298f commit afe28f5

File tree

1 file changed

+21
-17
lines changed

1 file changed

+21
-17
lines changed

Diff for: readme.md

+21-17
Original file line numberDiff line numberDiff line change
@@ -20,29 +20,29 @@ Have a look at the source code: https://github.com/DaftMonk/fullstack-demo
2020
## Usage
2121

2222
Install `generator-angular-fullstack`:
23-
```
23+
```bash
2424
npm install -g generator-angular-fullstack
2525
```
2626

2727
Make a new directory, and `cd` into it:
28-
```
28+
```bash
2929
mkdir my-new-project && cd $_
3030
```
3131

3232
Run `yo angular-fullstack`, optionally passing an app name:
33-
```
33+
```bash
3434
yo angular-fullstack [app-name]
3535
```
3636

3737
## Express
3838

3939
Launch your express server in development mode.
40-
```
40+
```bash
4141
grunt serve
4242
```
4343

4444
Launch your express server in production mode, uses the minified/optimized production folder.
45-
```
45+
```bash
4646
grunt serve:dist
4747
```
4848

@@ -54,13 +54,17 @@ grunt serve:dist
5454

5555
To generate a dist folder that can easily be deployed use:
5656

57-
grunt
57+
```bash
58+
grunt
59+
```
5860

5961
This will run unit tests, jshint, concatenate and minify scripts/css, compress images, add css vendor prefixes, and finally copy all files to a tidy dist folder.
6062

6163
Alternatively to skip tests and jshint, use:
6264

63-
grunt build
65+
```bash
66+
grunt build
67+
```
6468

6569
### Heroku Deployment
6670

@@ -84,27 +88,27 @@ That's it! Your app should be live and shareable. Type `heroku open` to view it.
8488

8589
## Setting up Route authorization
8690

87-
If your app uses the Passport boilerplate for accounts, you'll of course want to restrict access to certain client routes/api routes.
91+
If your app uses the Passport boilerplate for accounts, you will want to restrict access to certain client routes/api routes.
8892

89-
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.
93+
For restricting server API routes, we can use the `auth` middleware, which will send a 401 unauthorized error if a request is made from someone thats not logged in.
9094

91-
For protecting client routes, we automatically handle 401s sent from the server by redirecting you to the login page.
95+
For restricting routes on the client side, we automatically handle 401s sent from the server by redirecting you to the login page.
9296

9397
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.
9498

95-
You can easily do this from your `app.js` by adding the following to any client routes that need protecting.
99+
You can do this from your `app.js` by adding the following to any client routes that you want to restrict to logged in users.
96100

97-
authenticate: true
101+
```
102+
authenticate: true
103+
```
98104

99105
This redirects the user to the login page before attempting to load the new route, avoiding the flicker.
100106

101-
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.
102-
103-
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.
107+
Please keep in mind this client routing is only for improving the user interface. Make sure you **secure your server API** routes and don't give any sensitive information unless the user is authenticated or authorized.
104108

105-
#### How do I only let users authorized access an api route?
109+
#### How do I only let authorized users access an api route?
106110

107-
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.
111+
Similarly to how the `auth` middleware checks if a user authenticated before going to the next route, you can make an ensureAuthorized middleware that checks the users role, or some other field, before sending them to the protected route, otherwise have it sends a `403` error.
108112

109113
## Generators
110114

0 commit comments

Comments
 (0)