Mike Engelhart wrote:
> Hello -
>
> I am building a web application that needs to transfer the user to a secure
> server to enter credit card information. The problem I've run into with
> servlets/JSP is that you can't pass session information to another server
> and back again because it violates security rules. So, I thought I would
> write a servlet that uses RMI to grab a session from the initiating server.
> It had a single method:
> getRemoteSession(String sessionID) that would return an HttpSession based
> on the ID that was passed to it.
>
One way to approach this would be as follows:
* Session is established in the non-secure servlet context
* Non-secure servlet sets a custom cookie with the session ID
of the session in question (it will know it's own session ID without
having to use any deprecated methods).
* This cookie is configured (domain & path) so that it will be sent to
the secure servlet when you submit to it.
* Secure servlet receives this cookie, and submits a specialized
request to a non-secure servlet (in the same context) to retrieve
whatever session values are required. This request must include
the session identifier of the non-secure session.
* NOTE: In order for this to work, the secure servlet needs to know
the cookie name to submit the session ID with. Right now (2.0/2.1
API) this is non-standard, but it becomes standard in 2.2.
* Non-secure servlet creates a stream of Java serialized objects
containing these values, and returns it to the secure servlet.
* A similar approach can deal with the secure servlet wanting to
update something -- it creates what amounts to an "upload"
request, passing a stream of serialized Java objects that the
non-secure servlet uses to update the session contents.
>
> That would have been fine until I realized that the
> HttpSessionContext.getSession(String id) has been completely deprecated and
> will not be replaced (again because of security rules) so now I have no way
> of getting a session from the remote server. My question is, how does
> anyone build a useful ecommerce system if all servlet engines make it
> impossible to move between servers. Certainly the designers of JSDK must
> have thought about moving between servers like this while retaining state.
> Is there any way to do this using the JSDK 2.1/JSP 1.0 API's without writing
> a ton of code? I know the app servers out there must do this or else they
> wouldn't be able to support load balancing. I think Apache JServ allows
> you to get information from any other maching running JServ but
> unfortunately it doesn't let you use the JSDK2.1 api which I need to be able
> to use beans for business logic and JSP for display. (i.e, no
> RequestDispatcher in the JSDK 2.0).
>
Apache JServ 1.0 was designed and written before the 2.1 API came out. As a
result, it violates the 2.1 requirements related to contexts not crossing virtual
host boundaries, because it allows a zone to be shared across virtual hosts (i.e.
across the secure and non-secure servers). Reliance on this "feature" will
require you to rewrite your logic anyway when you go to any 2.1-compliant servlet
engine, so my suggestion would be "don't go there".
>
> Also, in regards to the security issues, wouldn't it be better to leave
> something like HttpSessionContext.getSession(String id) in the API and
> require the use of the SecurityManager classes to use it instead of just
> deprecating it?
>
Note that a security manager doesn't help you unless it's modified to include
"check" methods for this purpose -- since servlets are a standard extension rather
than core, this does not seem likely. You can use the policy permissions
mechanisms of JDK 1.2, but then you're saying "sorry ... no servlets allowed under
JDK 1.1. any more".
As for the reason this is a big deal, consider the fact that many people store
sensitive resources, such as an authenticated JDBC connection, in user sessions.
Consider also that these sorts of connections are often quite capable, because
they must be able to perform any transaction this user is authorized for.
Now, consider the fact that, unless the system administrator is careful, anonymous
servlets (i.e. those invoked with a /servlet/xxxxx URL instead of being
preconfigured in the servlet engine's property files) can be executed.
Do you *really* want such a servlet to be able to walk through all the currently
active sessions, with full access to all the user objects that are stored there?
It's just like giving anonymous DOS programs the right to say "delete *.*" across
your entire hard disk.
IMHO, servlets should never ever be allowed to access information for any session
other than the one specified in the current request. Doing anything else creates
too many potential holes.
>
> Thanks for any help with this and I apologize for such a long post.
>
> Mike
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
