Servlet Chain and Request Parameters.

[Brian R. Wainwright]

I have what I hope is a fairly straightforward question. I want to create a servlet_a which accepts a POST request with some parameters (through a form submission) on server_a. The servlet would then some login information (username and password for example) from the file system and then redirect to servlet_b running on server_b. This servlet would perform some authentication using the credentials provided from servlet_a. Following this authentication (which has essentially set some session information on server_b) control is returned to servlet_a and another request is sent to another resource on server_b which is then displayed in the client browser. Another alternative would be to include login information in the request for the resource and return the resource after authentication, so only one request is made to server_b. The idea behind this is to hide the required login process from the user and (more importantly) not expose that login information (username and password) in either the URL of the client's browser OR in the POST information (kind of like a rudimentary single sign-on). So my question is, given this scenario, will that login information (which was NOT part of the first request to servlet_a) be exposed anywhere to the client when the resource on server_b is returned back to the browser.

Hope this makes sense. Thanks for any thoughts or information.

---Brian

[Ben Souther]

Servlet Chaining isn't around any more.
Have a look at the RequestDispatcher object.
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/RequestDispatcher.html

It will allow you to perform server side forwards from one Servlet/JSP to another without sending anything back to the client along the way.

[Brian R. Wainwright]

Thanks Ben... I guess I'm showing my age. ;-)

[Brian R. Wainwright]

As a follow-up question, the include() method of the RequestDispatcher will allow me to include a resource from another server, is that correct?

[Charles Lyons]

You cannot communicate at the servlet-level between two different J2EE servers - just simply won't work. Additionally, you can only use RequestDispatchers (and most other container services) within the same container - so applications running in the same J2EE instance but different containers can't communicate directly either.

You therefore cannot use a RequestDispatcher to communicate with another server - you can use it between applications in the same container, by obtaining the ServletContext for the foreign application, then obtaining a RequestDispatcher from that. However, security restrictions in your container (especially if it's from a shared hosting company) may prevent you obtaining foreign contexts.

Your can only obtain resource stream from resources on other servers that are pre-processed by the other server, and return just a normal HTTP response. So, for example, you can include another server's page into your current response by using standard java.net classes - in particular java.net.URL and openStream().

I know this can be a frustrating issue, but it's a matter of logistics, since the container handles everything in its closed "sand box".

[Brian R. Wainwright]

Thanks for the clarification Charles. That of course makes sense. Creating a URL object may accomplish what I need to do. I can then get an InputStream from that and read those bytes in and write them back out to my response.

[Ben Souther]

Oops. I over looked the inter server part of your question.
Charles is correct. The RequestDispatcher is not intended for communication between servers.