Newsgroup: it.comp.java
Titolo: Authentication problem, bypassing the servlet.

Hi
I'm using weblogic 4.51 and using a controller servlet to forward requests
to my jsp's.  The problem I have is that if someone is figures out what the
name of my jsp page is and type it in the URL it takes them directly to the
jsp page.  Although the page is missing some format it is basically the
entire webpage which is not what I want.  Anyone know how to bump someone
who requests a url to my Login page.
Example URL for the client I'm working on
www.mbusa.com/owners/care/roadside.jsp
 (the hacky way)
versus
http://www.mbusa.com/owners/container.jsp?/care/roadside.jsp
 (the
authenticated route)
Here are a few solutions that have been brought up both with advantages and
dis.
So here is what i've determined. There are 2 options (there could be more,
so if you know of any please speak up :O) that we can use to prevent the
client from accessing owners pages without using the front controller
servlet:
1. Add authentication to the weblogic pipeline. this is the path that all
jsp request must go thru. the browser hawk (this is the servlet that checks
to ensure the client is using supported browsers and correct versions)
implementation uses this method.
Advantages:
- insert authentication in this one spot to prevent unauthorized jsp access.
- easy to implement
Disadvantages:
- adds time to EVERY request including requests for just mainsite pages.
this time is probably negligible as the additional time for each request
after the browser hawk check was inserted into the pipeline took an
additional (on average) 0.015 seconds.
- we would be inserting application specific code into the generic pipeline
used by all weblogic applications.
2. Add authentication to each jsp on the site
Advantanges:
- easy to implement
Disadvantages:
- add more stuff to the jsps
- i believe authentication will be done twice on each request using the
front controller servlet. once in the front controller, and then again when
the request is dispatched to the view.
ANY SUGGESTIONS

I don't think I fully understand #1, and #2 sounds like a maintenance
pain. I did think of another possible solution, but I don't know if it
will work with your configurations (It's been over two years since I
worked with WL 4.5).
Most app servers have a web server in front of them. These two
communicate through a plug-in. The app server's servlet engine usually
creates a mapping for the plugin, indicating what URL patterns it
accepts. One of these would be the URL pattern for your controller
servlet. Another would be *.jsp, which would map to WL's JSP servlet.
When the web server encounters a URL for which it is not mapped, it
checks the plug-in to see if it contains the mapping. If so, the
request is forward to the app server.
If you can somehow suppress explicit '*.jsp' requests from going to
your app server (by removing this mapping from the plug-in) and
instead have the web server serve a friendly 404 page, you're in
bidness.
Not sure if I am forgetting a critical piece, but I think this may
work.
Hope this helps.
Ryan

 authenticated route)
I almost always have a similar 'problem'. What I do is:
- have one main servlet (controller) which does request dispatching for all
the authenticated requests, something like the second url stated above. for
unauthorized requests forward to login page.
- move all the jsps in /WEB-INF/jsp. WEB-INF should be unaccesible from the
outside world (specification says so, I think).
- for the unprotected jsps, just leave them in the web root (or its subdir,
of course).
Check RequestDispatcher class (servlet spec. 2.1 and newer, if I remember
correctly).
You can also map controller servelt to something like /auth/*.
Also, check Struts, 
http://jakarta.apache.org/struts
 which should help you
here.

 wrote in message
news:ahrjeu$hfb$1...@sunce.iskon.hr...


 
Definitelly no.
Check struts, it really helps. Although I'm not too satisfied with some 
details of struts, it saved me a lot for troubles. 
-- 
Davor Cengija, 
dcengija...@inet.hr

Another way you could possibly solve this is to override the default
behavior of your servlet container's JSP servlet. By default, the
container probably always forwards JSP requests to it's default JSP
servlet. You could instead subclass this servlet, add a "security
check" in the service method, and then pass control to the superclass
for the actual processing (if the security check passes). You then map
*.jsp requests to YOUR secure JSP servlet.
This security check should be as fast as possible. The simplest would
probably be for your controller servlet to place a token object in the
request before forwarding your JSP servlet. Your JSP servlet then
checks for the existance of this token
[request.getAttribute("com.yourpackage.tokenName") != null]. If this
passes, handle the request. If not, forward to another "error page".
Did I miss something crucial here? I think this is a pretty clean
approach. For some reason, placing JSP files under the WEB-INF
directory just seems yucky. Don't know why.
Hope this helps.
Ryan

 wrote in message
news:55e900c9.0207...@posting.google.com...


 
Although not perfect, it appears to be quite stable and useful. It won me 
on form validation functionality. Also, using Actions which call all the 
business logic, JSP's really become the viewer part of an application. 
It is a little bit cumbersome to start using it and you'll never be 100% 
happy with it but it really helps to some extent.
Hmmm.... becoming a Struts evangelist although I don't like it too much? :-)
-- 
Davor Cengija, 
dcengija...@inet.hr