Re: [SOLVED, workaround] Why my web application automatically switchs to https?

[Luca Fagioli <lu...@innovery.it>]

Ok, it turned out to be either a bug (or a wrong configuration) of the 
environment I was working with (GIS + embedded Jetty).

So, I ended up working around it. I write it down; hope it can be useful 
for someone else.

The workaround is Jetty specific, but the same approach can be used with 
Tomcat.

I've ended up applying a Filter, to manipulate the wrong request object 
coming from the container.

Here are the few lines of code for the filter:

public class PlainHttpFilter implements Filter {

     public void init(FilterConfig filterConfig) throws ServletException {
         this.filterConfig = filterConfig;
     }

     public void doFilter(ServletRequest request, ServletResponse 
response, FilterChain chain) throws IOException, ServletException {

         // Begin workaround
         Request jettyRequest = 
Request.getRequest((HttpServletRequest)request);
         jettyRequest.setScheme("http");
         // End workaround

         chain.doFilter(jettyRequest, response);

     }

     public void destroy() {
         this.filterConfig = null;
     }

}

where the jettyRequest is an instance of org.mortbay.jetty.Request; just 
use the Tomcat implementation of HttpServletRequest 
<http://api.dpml.net/javax/servlet/2.5/javax/servlet/http/HttpServletRequest.html?is-external=true>.


Luca


Il 11/06/2010 18:03, Pid ha scritto:
> On 11/06/2010 15:53, Luca Fagioli wrote:
>    
>> Il 11/06/2010 16:01, Caldarale, Charles R ha scritto:
>>      
>>>> From: Pid [mailto:pid@pidster.com]
>>>> Subject: Re: Why my web application automatically switchs to https?
>>>>
>>>> Exact Tomcat, JVM, OS versions?
>>>>
>>>> Are you using HTTPD/IIS as well?
>>>>
>>>> Does the HTML contain hardcoded URLs?
>>>>
>>>> Are you using a framework like Struts?
>>>>
>>>>          
>>> And are you running Tomcat under Eclipse or some other IDE?  (Those
>>> often use their own configurations, ignoring what you've specified.)
>>>
>>> Which web.xml was changed?  (Modifying the one in tomcat's conf
>>> directory would be a mistake.)
>>>
>>> Post the complete WEB-INF/web.xml from your webapp.
>>>
>>>    - Chuck
>>>
>>>        
>> Thank you guys,
>> but the problem starts to be even more complicated. The application i've
>> started to working with is running in the Sterling Integrator (Gentran
>> Integration Suite) environment, and turned out that its servlet
>> container is not Tomcat, but Jetty.
>>
>> I'm in a big trouble, i think. I've posted the same question in the
>> Jetty users list, but less traffic out there.
>>
>> By the way, this is the web.xml of the application:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
>> 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
>> <web-app>
>> <display-name>Cedacri Web</display-name>
>> <filter>
>> <filter-name>SessionExpiredFilter</filter-name>
>> <filter-class>com.innovery.cedacri.servlets.SessionExpiredFilter</filter-class>
>>
>> </filter>
>> <filter-mapping>
>> <filter-name>SessionExpiredFilter</filter-name>
>> <url-pattern>/*</url-pattern>
>> </filter-mapping>
>>
>> <servlet>
>> <servlet-name>dispatcherAN</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherANAGRAFICA</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherSE</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherSERVERS</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherIN</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherINCOMING</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherOU</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherOUTGOING</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherOUI</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherOUTGOINGISTITUTI</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherCO</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherCONFIGURAZIONI</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherDE</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherDEPOSITO</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherRE</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherRECUPERO</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherFI</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherFILIALI</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherII</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherINCOMINGISTITUTI</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>dispatcherTJ</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.RequestDispatcherTEMPLATEJCL</servlet-class>
>>
>> </servlet>
>> <servlet>
>> <servlet-name>Logout</servlet-name>
>> <servlet-class>com.innovery.cedacri.servlets.Logout</servlet-class>
>> </servlet>
>>
>> <servlet-mapping>
>> <servlet-name>dispatcherAN</servlet-name>
>> <url-pattern>/dispatcherAN</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherSE</servlet-name>
>> <url-pattern>/dispatcherSE</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherIN</servlet-name>
>> <url-pattern>/dispatcherIN</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherOU</servlet-name>
>> <url-pattern>/dispatcherOU</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherOUI</servlet-name>
>> <url-pattern>/dispatcherOUI</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherCO</servlet-name>
>> <url-pattern>/dispatcherCO</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherDE</servlet-name>
>> <url-pattern>/dispatcherDE</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherRE</servlet-name>
>> <url-pattern>/dispatcherRE</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherFI</servlet-name>
>> <url-pattern>/dispatcherFI</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherII</servlet-name>
>> <url-pattern>/dispatcherII</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>dispatcherTJ</servlet-name>
>> <url-pattern>/dispatcherTJ</url-pattern>
>> </servlet-mapping>
>> <servlet-mapping>
>> <servlet-name>Logout</servlet-name>
>> <url-pattern>/Logout</url-pattern>
>> </servlet-mapping>
>>
>> <welcome-file-list>
>> <welcome-file>login.jsp</welcome-file>
>> </welcome-file-list>
>>      
> If you're using container managed security, you should never make a
> direct request for the login form.
>
> Maybe one of those servlets is doing the HTTPS redirect.
>
>
> p
>
>    
>> <taglib>
>> <taglib-uri>http://www.stercomm.com/uix/security</taglib-uri>
>> <taglib-location>tld/userautho.tld</taglib-location>
>> </taglib>
>> <taglib>
>> <taglib-uri>http://jakarta.apache.org/taglibs/xtags-1.0</taglib-uri>
>> <taglib-location>tld/taglibs-xtags.tld</taglib-location>
>> </taglib>
>>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>The entire Cedacri dashboard
>> application</web-resource-name>
>> <url-pattern>/*</url-pattern>
>> </web-resource-collection>
>> <user-data-constraint>
>> <transport-guarantee>NONE</transport-guarantee>
>> </user-data-constraint>
>> </security-constraint>
>>
>> </web-app>
>>
>>
>>
>> Luca
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>      
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org