One possible implementation of this method would involve storing the
user ID (e.g., either username itself or the session ID) and the names of the categories
of users this user belongs to in the HttpSession object. For example, you
might use a filter??”see Chapter 5 (Servlet and JSP Filters)??”to intercept every
request to any of your application??™s resources and check for the presence of the user
information in the HttpSession. You can then use the information in the
HttpSession to decide if this user is allowed to have access to the requested
4.3 Handling All Security Programmatically 189
resource. If the user information is absent, you can forward the user??™s request to the
login page. The action of the login page form would then evaluate username and
password for validity. If valid, the user??™s information would be loaded into the
HttpSession object. The main advantage of this approach is that you still get to
present a custom login page with the look and feel of the rest of the application and
at the same time achieve complete portability. However, creating such a security
module would mean a lot of work. In this section, we??™ll concentrate on the native
HTTP authentication.
HTTP supports two varieties of authentication: BASIC and DIGEST. Few browsers
support DIGEST, so we focus on BASIC here.
Here is a summary of the steps involved for BASIC authentication:
1. Check whether there is an Authorization request header.
Pages:
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237