Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

HttpServletRequest - RequestDispatcher - Forward - is not using Constraint

 
Jeff Bradford
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We have a Servlet that is being called via a standard POST (http).

The Servlet is doing a RequestDispatch FORWARD to a JSP. We would like that JSP to be called via HTTPS (SSL).

We have the Constraint in web.xml below in place, but it still uses http://localhost::8080 when routing to the JSP

<security-constraint>
<web-resource-collection>
<web-resource-name>Restricted URLs</web-resource-name>
<url-pattern>/sso.jsp</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>


However, if you hit the JSP directly from the Browser it does switch the URL over to SSL.

Any ideas?


Thanks,
Jeff
 
Abimaran Kugathasan
Ranch Hand
Posts: 2066
Clojure IntelliJ IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think, the web.xml security constraint is for direct access from client.
 
Jeff Bradford
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That appears to be true. I found this.

Security constraints work only on the original request URI and not on calls made through a RequestDispatcher (which include <jsp:include> and <jsp:forward>). Inside the application, it is assumed that the application itself has complete access to all resources and would not forward a user request unless it had decided that the requesting user also had access.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64982
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You cannot change the protocol midstream. The HTTP request has already been made, it can't be changed after-the-fact.
 
Jeff Bradford
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We ended up turning on SSL for the entire site instead.

 
Hebert Coelho
Ranch Hand
Posts: 754
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Haha, simple solution! ^^

gratz, Jeff Bradford
 
Abimaran Kugathasan
Ranch Hand
Posts: 2066
Clojure IntelliJ IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:You cannot change the protocol midstream. The HTTP request has already been made, it can't be changed after-the-fact.


Correct! Can't it redirect the client to request over SSL, if the request contains access to restricted resources implicitly?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic