O'Reilly logo

Head First Servlets and JSP, 2nd Edition by Bert Bates, Bryan Basham, Kathy Sierra

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

The declarative side of programmatic security

There’s a good chance that when a programmer hard-codes security role names in a servlet (to use as the argument to isUserInRole()), the programmer was just making up a fake name. He either didn’t know the real role names, or he’s writing a reusable component that’ll be used by more than one company, and those companies aren’t likely to have the exact role names the programmer used. (Of course, if the programmer really wants to build reusable components, hard-coding a role name is a Terrible Idea, but we’ll suspend disbelief for now.)

It turns out that the Deployment Descriptor has a mechanism for mapping hard-coded (which means made-up) role names in a servlet to the “official” <security-role> declarations in your Container. Imagine, for example, that the programmer used “Manager” as the isUserInRole() argument, but your company uses “Admin” as the <security-role>, and you don’t even have a “Manager” security role. So even if you can’t stop a programmer from hard-coding a role name, you at least have a work-around when the hard-coded roles don’t match your real role names. Because even if you do have the servlet source code, do you really want to change, recompile, and retest your code just to change every instance of “Manager” to “Admin”?

image with no caption

Note

The <security-role-ref> element maps programmatic (hard-coded) role names to declarative <security-role> ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required