Head First Servlets and JSP, 2nd Edition

Protecting the request data

Remember that in the DD, the <security-constraint> is about what happens after the request. In other words, the client has already made the request when the Container starts looking at the <security-constraint> elements to decide how to respond. The request data has already been sent over the wire. How can you possibly remind the browser that, “Oh, by the way... if the user happens to request this resource, switch to secure sockets (SSL) before sending the request.”

What can you do?

You already know how to force the client to get a login screen—by defining a constrained resource in the DD, the Container will automatically trigger the authentication process when an unauthenticated user makes the request.

So now we have to figure out how to protect the data coming in from a request... even (and sometimes especially) when the client has not yet logged in.

We might want to protect their login data!

Turn the page to see how it all works...

Unauthorized client requests a constrained resource that has NO transport guarantee

1. Client requests /BuyStuff.jsp, which has been configured in the DD with a <security-constraint>.

   The Container checks the <security-constraint> and finds that /BuyStuff is a constrained resource... which means the user MUST be authenticated.The Container finds that there is NO transport-guarantee for this request.

2. The Container sends a 401 response ...