This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
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".
Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / AmazonAmazon UK )
Brian R. Wainwright
Joined: Aug 12, 2003
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.