(TODO-04) Open the SecurityConfig class. Notice that the actual security constraints are defined inside the method configure(HttpSecurity http). In particular notice that the EDITOR role is required to access the accountList page.

When we tried to access the restricted accountList page the application tried to redirect us to a login page. Time to configure one.

Back inside SecurityConfig, configure the login page to be /login by modifying the loginPage() method under the formLogin() method.

At the same time, setup the access denied page so it uses '/denied'.

Save all work and, once the application restarts, navigate to the home page at http://localhost:8080/. This time when you click the 'View Account List' it should redirect you to the login form.

Try logging in with a random username and password such as username "foo" and password "foo". You should be returned to the login page with an error message in red. Notice the URL at the top of the page http://localhost:8080/login?error . By default a failed login redirects back to the login URL with the error parameter defined. (You can customize this by specifying formLogin().failureUrl("/some-url")).

Open login.html under the src/main/resources/templates/ folder. The <div> delimited by {{#springMacroRequestContext.request.parameterMap.error}} will be output if the error parameter is non null.

Notice that the default input field names are username and password and that the form action is to POST the form to itself.

(TODO-05) To determine a valid username/password combination, you can explore the authentication configuration (further down within SecurityConfig you will find the configureGlobal() method). An in-memory authentication provider is being used. Notice that a single hard-coded user, password, and role have been setup to support testing.

Try logging in using the user called vince. You should see the "Access Denied" page.

So far you have only been logging in as a user with the VIEWER role, and you have been denied access to the account list. Perhaps the restriction is too severe. To edit an account should require the EDITOR role, but accessing the accountList and accountDetails views should be available to a user with the VIEWER role.

Find the authorizeRequests method and modify the rules for /accounts/account* to enable access for viewers as well.

Save all work and let the application restart. Using the user vince, you should now be able to access the account list and the account details. On the Account details page, click on 'Edit Account'. This link should send you to the 'Access Denied' page as vince does not have the EDITOR privileges.

(TODO 07) Currently you secure URLs starting with /accounts/edit and accounts/account To get a more robust configuration, you should also enforce that people must at least be logged in to show anything else starting with /accounts/.

Log out by clicking on the 'log out' link. Then try to access "the Hidden Page" (http://localhost:8080/accounts/hidden). As you can see, this URL is currently not protected, but it should be.

Inside SecurityConfig class, add another mvcMatchers element at the bottom of the list with the pattern /accounts/** which enforces that the user should be fully authenticated. Be sure to do this using the method that will permit all users to access. Where should you place this to make sure that the more specific entries will be evaluated first.

Once the application restarts, check that attempts to access "the Hidden Page" (http://localhost:8080/accounts/hidden) result in the login page being displayed.

(TODO 08) Notice that the account list page provides a logout link. Open accountList.html within /src/main/resources/templates to see how it is implemented; by default Spring Security looks for a POST /logout request, which is implemented using Spring MVC form tag.

At this point, logging out doesn’t help much since you only have one user defined. However, by adding a new user with the EDITOR role, you should be able to login as that user and successfully edit the account.

Revisit the globalSecurity method and add a user called edith with the EDITOR role. To do this, you will need to add an “and()” method on the end of the line that defines vince, then add edith on the following line. The new definition will be similar to that for vince except Edith’s role must be EDITOR.

Save all work and, after the application restarts, log in with the user edith. Navigate to the edit page by selecting an account from the account list and using the "Edit account" link on the details page. This time you should be able to access the editAccount page.

Our goal is to allow those with EDITOR role to edit account details while disallowing other roles, so we need to ensure that other users cannot access this page. Logout of the application and login again as vince. Repeat the navigation, but this time we expect vince to be redirected to the "Access Denied" page.