- Shopping Bag ( 0 items )
Ships from: Zephyrhills, FL
Usually ships in 1-2 business days
Ships from: Chatham, NJ
Usually ships in 1-2 business days
Ships from: Friendswood, TX
Usually ships in 1-2 business days
Advanced JavaServer Pages delivers:
To fully exploit the power of JavaServer Pages technology in Web application development, based on J2EE technology, you need to master the sophisticated server-side techniques that David Geary presents in Advanced JavaServer Pages.
Geary tackles JavaServer Pages technology with the same exhaustive, authoritative approach that made his Graphic Java books into worldwide best sellers. He presents in-depth coverage of advanced topics including:
Advanced JavaServer Pages features detailed chapters on internationalization, authentication, JSP technology templates, design, and XML. It concludes with a comprehensive case study that ties together key topics developed in thebook and demonstrates how to integrate advanced techniques based on JSP technology. This book is a must-have resource for every developer of Java technology creating server-side applications with JSP technology and servlets.
Many books have been written about the wide ranging topic of computer security, including Java security, and this chapter is a substitute for none of them. This discussion is restricted to protecting web application resources with the authentication mechanisms described in the servlet specification.1
1. A user tries to access a protected resource, such as a JSP page.
2. If the user has been authenticated, the servlet container makes the resource available; otherwise, the user is asked for a username and password.
3. If the name and password cannot be authenticated, an error is displayed and the user is given the opportunity to enter a new username and password.
The steps outlined above are simple, but vague. It's not apparent who asks for a username and password, who does the authentication, how it's performed, or even how the user is asked for a username and password. Those steps are unspecified because the servlet specification leaves them up to applications and servlet containers. This vagueness in the servlet specification has an effect on portability; see "Portability" on page 254 for more information.
Principals can fill one or more roles; for example, a customer could also be an employee. Security constraints in
WEB-INF/web.xml associate roles with protected resources, like this:
<web-app> ... <security-constraint> <!-- web resources that are protected --> <web-resource-collection> <web-resource-name>Protected Resource</web-resource-name> <url-pattern>/page_1.jsp</url-pattern> </web-resource-collection> <auth-constraint> <!-- role-name indicates roles that are allowed to access the web resources specified above --> <role-name>customer</role-name> <auth-constraint> </security-constraint> ... <security-constraint> <!-- web resources that are protected --> <web-resource-collection> <web-resource-name>Protected Resource2</web-resource-name> <url-pattern>/page_2.jsp</url-pattern> </web-resource-collection> <auth-constraint> <!-- role-name indicates roles that are allowed to access the web resources specified above --> <role-name>employee</role-name> </auth-constraint> </security-constraint> <web-app>
Two security constraints are specified above that restrict access to
/page_2.jsp to principals that are in roles customer or employee, respectively.
Security constraints, like those listed above, associate resources with roles. It's up to servlet containers or applications to associate roles with principals; for example, with Tomcat, you edit a
tomcat-users.xml file that has entries like this:
<tomcat-users> ... <user name="rwhite" password="tomcat" roles="customer", "other"/> ... </tomcat-users>
Here, rwhite has a password of tomcat and can fill roles customer or other; thus, rwhite can access
/page_1.jsp, but not
/page_2.jsp according to the security constraints listed above.
Other servlet containers provide different mechanisms for associating principals with roles; for example, "Resin" on page 264 illustrates how it's done with Resin for basic authentication.
Table 9-1 lists HttpServletRequest methods that allow you to retrieve information about principals and roles....
...The servlet API does not provide corresponding setter methods for the getter methods listed in Table 9-1; therefore, principals and roles can only be set by servlet containers, meaning that applications cannot set them. This can be a consideration if you implement programmatic authentication—see "Programmatic Authentication" on page 271 for more information.
Table 9-2 lists other ServletRequest methods that provide security information....
...Like the methods listed in Table 9-1 on page 253, the servlet API does not provide corresponding setter methods for those methods listed in Table 9-2. This means that the authentication type and transport scheme can only be set by servlet containers.
Most servlet containers provide access to the middle of that spectrum by providing hooks so that you can replace their default authentication mechanism. "Basic Authentication" on page 256 provides an example of declarative authentication, "Customizing Authentication" on page 263 illustrates customizing authentication, and programmatic authentication is discussed in "Programmatic Authentication" on page 271.
To be honest, I wasn't too excited about servlets. Were software developers really going to create user interfaces by generating HTML with print statements from the guts of some servlet? I knew of at least one software developer that was not. Since 1984, I've had the good fortune to develop software by using a number of object-oriented languages and very cool user interface toolkits. I've developed applications in Smalltalk, Eiffel, and NeXTSTEP, and it seemed to me that developing applications with HTML— especially HTML manually generated from servlets—was akin to trading in a Ferrari for a Yugo. Then I discovered JSP.
Although back in 1999 JSP was in its infancy, it was easy to see its potential. Here was a way to mix Java with HTML, which opened the door to all kinds of interesting possibilities. And in the Future Directions section of the JSP 1.0 specification, I saw something that really caught my eye: A portable tag extension mechanism is being considered for the JSP 1.1 specification. This mechanism permits the description of tags that can be used from any JSP page. Wow. With custom tags you could encapsulate Java code, which would essentially allow you to create custom components, in the form of tags, that could be used in conjunction with HTML. From then on, I knew that my next book would be about JSP.
So I started to write an introductory JSP book, and I actually wrote the first chapter of that book before I realized two things. First, there was going to be a glut of introductory JSP books, and I did not want to compete against all of those books. Second, and most important, that first chapter was boring, and I hate to read boring books, let alone write them. So, I decided to write this book instead.
This book begins where most introductory JSP books leave off, by showing you how to implement JSP custom tags. The ability to create custom tags is arguably JSP's greatest strength because it allows software developers and page authors to work in parallel with few dependencies. Subsequent chapters cover HTML forms, JSP templates, Model 1 and Model 2 architectures, a simple Model 2 framework, handling events, internationalization, security, databases, and XML. This book concludes with a comprehensive case study that shows how to use the techniques discussed in this book to develop a nontrivial web application.
Because Tomcat is the reference implementation for the Servlet and JSP specifications, all of the code in this book should work with any servlet container that conforms to the Servlet 2.2 and JSP 1.1 (or higher) specifications. If an example from this book does not work with your servlet container, it is most likely a bug in that servlet container.
I also tested all of the code in this book against Resin 1.2, which is an excellent servlet container available from http://www.caucho.com. As a general rule, it is beneficial to test your code against more than one servlet container to ensure correctness and portability.
This book was not written for page authors. If you are a page author with no Java experience, you will be better served by one of the books listed above.
After working for 15 years as a software engineer, I tend to write books the way I write software. Each of this book's chapters started out in humble fashion. And each chapter was subsequently refactored into the final product that you hold in your hands.
You can get a glimpse into this process by looking at a JavaWorld article that I wrote about JSP templates.1 That article is the first cut of this book's Templates chapter, so you can see where the process started for that chapter and where it ended; both the chapter and the code that it discusses underwent much refactoring.
The last chapter in this book is a comprehensive case study that employs the techniques discussed throughout this book to implement a nontrivial web application. You can read (or most likely, skim) that chapter first to get a feel for those techniques, or you can read it last to see how to integrate those techniques. Or you can do both.
This book's custom tags serve two purposes. First, they illustrate how you can implement your own custom tags. Second, they serve to reinforce the concepts discussed throughout this book. But those custom tags are not the focus of this book; rather, it's the concepts that those tags embody that are important. For example, if you look at the internationalization chapter, you will see that most of that chapter is dedicated to internationalizing text, numbers, dates, and currency in a JSP-based web application. The last few pages of that chapter show how to implement two custom tags that perform internationalization. But it's the internationalization concepts, and not the custom tags, that take center stage in that chapter.
Table P-1 Coding Conventions...
Note that, for the most part, methods are referred to without their arguments; however, arguments are included when the discussion warrants them.
Table P-2 shows the typographic conventions used in this book.
Table P-2 Typographic Conventions...
Posted September 10, 2001
This is a great book, but hurried. For example, there is a 'paint' parameter to a taglib page that apparently is forgotten in the book. But, buy it! You won't be unhappy. Geary is an imaginative thinker who provides value for the price.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.