Turning On Spring Security with Java Config24:11 with Chris Ramacciotti
In this video, we'll switch on security by adding a
@Configuration class that specifies the details of which Spring Security features we'd like to use.
Spring Security Filter Chain
For more information on the filter chain, check out the Spring docs: http://docs.spring.io/spring-security/site/docs/current/guides/html5/form.html
Sessions for Login Failures
I've demonstrated the use of session attributes to handle login failure messages, as opposed to using the standard in examples you might see around the web. Examples typically show the use of a query string parameter in the URL, such as
I don't like this approach because care must be taken so that one cannot visit that URL directly to reproduce the flash message. Instead, I prefer to keep the URL clean, and rely on a session attribute to save the flash message. Session attributes are server-stored values, and can even include rich objects. When session attributes are used, you'll notice that a session cookie (usually called JSESSIONID) is set in the browser and passed with every request, so that the server can pair the browsing session with the server-stored session data.
If you choose this approach, be sure to clear the session attribute when it makes sense to do so. In our case, it makes sense as soon as we add the flash message to the model map for display in the rendered template.
Session IDs and Cookies
When working with session data in web applications using Java or any other server-side language, it is best to understand how your data might be compromised. Many applications match server-stored session data with browsing sessions using some sort of session cookie. This value is stored in the browser, and when your application receives a request that entails using that session ID for authentication or other session data, the application assumes the request originated from the same place.
But, what if your session ID cookie becomes compromised, whether through a browser vulnerability, or a non-HTTPS (read: plaintext) request intercepted by an attacker? Remember, HTTP requests are sent as plaintext, and if they're intercepted, they are directly readable by the attacker. Adding SSL encrypts all requests and responses in a way that protects all data (including cookies) in a way that doesn't make it more difficult for an attacker to intercept your requests or responses, but rather renders them unreadable since they're encrypted.
In any case, check the Teacher's Notes of later videos for common web app vulnerabilities.
Git Command to Sync Your Code to the Start of this Video
git checkout -f v5
Using Github With This Course
You can complete this course entirely using code created by you on your local machine. However, if you choose to use the code I've made available to you, you have two options:
- Use the project files linked at the bottom of this page, or
- Use the Github repository I've made available (recommended)
If you choose the recommended option of using the Github repository, it can be found at
To utilize Github with this course, you can download the Github desktop client for your system or use the command line interface provided with Git.
Clone this repository to your machine using the Github desktop client, or using the following command:
git clone firstname.lastname@example.org:treehouse/todotoday.git
To update your local repository to match a video's starting point, you can use the
git checkout command in combination with the stage and video number. For example, to update your local repository to match the starting point of Video 4, you'd use the following:
git checkout -f v4
Notice the use of the -f option. This forces Git to override all local changes, so be aware: this will cause any changes you made to be lost.
You need to sign up for Treehouse in order to download course files.Sign up