github
/
spring-security
spegling av https://github.com/spring-projects/spring-security


			
				
					
						
						
							1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586
							=== Exploring the secured application

Start the server as we did in <<running-the-{starter-appname}-application>> Now when you visit http://localhost:8080/sample/ you will be prompted with a login page that is automatically generated by Spring Security.

==== Authenticating to the secured application

Try entering an invalid username and password:

* *Username* _invalid_
* *Password* _invalid_

You should see an error message stating that authentication failed. Now try entering a valid username and password:

* *Username* _user_
* *Password* _password_

You should now see the page that we wanted to secure.

NOTE: The reason we can successfully authenticate with *Username* _user_ and *Password* _password_ is because that is what we configured in our <<security-config-java,`SecurityConfig`>>.

==== Displaying the user name

Now that we have authenticated, let's update the application to display the username. Update the body of index.jsp to be the following:

.src/main/webapp/index.jsp
[source,html]
----
<body>
  <div class="container">
    <h1>This is secured!</h1>
    <p>
      Hello <b><c:out value="${pageContext.request.remoteUser}"/></b>
    </p>
  </div>
</body>
----

WARNING: The `<c:out />` tag ensures the username is escaped to avoid http://en.wikipedia.org/wiki/Cross-site_scripting[XSS vulnerabilities] Regardless of how an application renders user inputed values, it should ensure that the values are properly escaped.

Refresh the page at http://localhost:8080/sample/ and you will see the user name displayed. This works because Spring Security integrates with the <<servlet-api-integration,Servlet API methods>>

==== Logging out

Now that we can view the user name, let's update the application to allow logging out. Update the body of index.jsp to contain a log out link as shown below:

.src/main/webapp/index.jsp
[source,html]
----
<body>
  <div class="container">
    <h1>This is secured!</h1>
    <c:url var="logoutUrl" value="/logout"/>
    <p>
      Hello <b><c:out value="${pageContext.request.remoteUser}"/></b> 
    </p>
    <p>
      <a href="${logoutUrl}">Click here</a> to log out.
    </p>
  </div>
</body>
----

Refresh the page at http://localhost:8080/sample/ and you will see the log out link. Click the link and see that the application logs you out successfully.

==== Basic authentication

We stated that Spring Security supported both form and HTTP Basic authentication, but how does Spring Security know when to use one and not the other? When using HTTP Basic, the user should receive a HTTP 401 response, but when we visit our application in our web browser we are redirected to a login page. The reason for this is because Spring Security uses content negotiation to determine which type of authentication to use. For example, if we specified our *Accept* header to be _application/json_ the result would be an HTTP 401.

You can use any tool you prefer (i.e. curl), but the instructions in this section we will use https://www.google.com/intl/en/chrome/browser/[Google Chrome] and the https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en[Postman - REST Client] to make an _application/json_ request to our application.

* Open Google Chrome and launch the Postman - REST Client extension
* Enter _http://localhost:8080/sample/_ into the request URL field
* Select the *Headers* button
* Enter _Accept_ into the *Header* input 
* Enter _application/json_ into the *Value* field
* Presss the *Send* button

Observe that we get an HTTP Status of 401 instead of our redirect. Now lets try entering our user name and password.

* Select the *Basic Auth* tab
* Enter _user_ for the *Username* 
* Enter _password_ for the *Password*
* Click the *Refresh headers* button
* Click the *Send* button

This time you should see the HTML of our secured page.