pascal jacob wrote:
> > I have not tried this, but see what happens with:
> > http://localhost:8080/servlet/snoop
> >
> I can tell you it works, because it is what I've always used.
>
> > (in other words, use the alias instead of the class name). However,
> > because it is so easy to map a URI prefix, or a filename extension, to a
> > servlet in the mappings.properties file, I cannot see much need for this
> > even if it works.
> >
> > The gadget that responds to the "/servlet" URI and loads anonymous
> > servlets is often called the "invoker" in servlet engine circles. Some
> > environments might consider the ability to do this a security risk, so
> > the JSDK servlet engine lets you turn it off by setting "invoker=false"
> > in the webapp.properties file for the servlet context you are running in.
>
> Now I'm perplex!
>
> Does it means that I should define an mapping-name (in the
> mappings.properties file) instead of using the alias defined in the
> "servlets.properties" file when invoking my servlets ?
>
> Here is two URLs that I use in my HTML files ("/ephone" is the context for
> my web-app):
> <FORM ACTION="/ephone/servlet/controlpanel?form=header" METHOD=POST>
> <A HREF="/ephone/servlet/logout">logout</A>
>
> Those URL invoke my servlets by the name defined in the
> "servlets.properties" file - the alias as I undertand you.
> (Here is the servlets.properties file:
> controlpanel=com.mycompagnie.ephone.ControlPanelServlet
> logout= com.mycompagnie.ephone.LogoutServlet)
>
> should I provide a mapping in the "mappings.properties" file
> like:
> /cp= controlpanel
> /logout=logout
>
> and transform the URLs to:
> <FORM ACTION="/ephone/cp?form=header" METHOD=POST>
> <A HREF="/ephone/logout">logout</A>
>
> And turn the Invoker off ?
>
> Thank you for your patience Craig.
>
> ZartC++
>
Which approach to take is a choice, not a requirement. You can use either
approach, or combine them.
The "invoker" approach has been historically supported, and makes life easier
if you are converting older apps to 2.1. It also gives you the flexibility to
introduce new servlets that you haven't put in the configuration files. One
cautionary note -- the name, ane even the existence, of the "invoker" servlet
(typically /servlet) is not currently mandated in the spec, so at the moment
you are not guaranteed of consistency across engines. However, it seems to be
pretty widely implemented.
The mapping approach lets you construct more readable URLs (if you care), but
more importantly gives you slightly better security -- *only* the servlets you
have configured in this context can be executed. Also, based on the
clarifications in Appendix B of the JSP spec, you can count on servlet engines
implementing both URI mapping and extension mapping this way.
I am designing my new apps using the mapping approach (actually, I'm using a
design pattern that funnels all of the action requests through a single
servlet for the entire context so that I can centralize access control and so
on), but I leave the invoker set to "true" in my development environment so I
can randomly call a session or snoop type servlet during debugging. In
production, though, the invoker will be turned off.
Craig
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
