Hi Jamey,
Jamey Wood wrote:
> Hi Jan,
>
> Jan.Luehe_at_sun.com wrote:
>
>> Jamey Wood wrote:
>
> ...<snip>...
>
>>> So it appears that the only way to force it into a
>>> 'setSecure(false)' case would be if we could force our
>>> HttpServletRequest to return false for the isSecure call. I believe
>>> that's possible in Tomcat (setting 'secure="false"' in server.xml,
>>> as documented at
>>> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html).
>>
>>
>> Sounds like a hack. :)
>
>
> For this specific scenario, I'd agree. But there might be other cases
> where such a setting would be more proper. For example, if your
> appserver were accessible only via an HTTPS reverse proxy, you might
> want any apps there to see all requests as "secure" even though the
> network connection coming directly out of the appserver might just be
> simple HTTP.
Yes, for the latter scenario, I would agree.
We support this scenario in GlassFish as well, but in a more flexible
way than in Tomcat (I think). In GlassFish, we leverage our ProxyHandler
interface, whose implementation class is configurable at the <http-service>
and <http-listener> levels in domain.xml.
Based on certain (custom) request headers that the load-balancing proxy
adds to the request before forwarding it to the GlassFish backend
instance, the proxy handler (configured on the GlassFish instance) can
determine whether the original request was over HTTP or HTTPS.
If the HTTPS reverse proxy enforces client auth, it would also pass the
(authenticated) client's SSL cert chain as one of the custom request
headers to the GlassFish instance. The instance's proxy handler will
then parse the cert chain from the request header and make it available
as a context attribute under its standard name.
In GlassFish, several of the ServletRequest methods, such as isSecure(),
delegate to the proxy handler (if present) to get the correct information
about the original request that was intercepted by the proxy.
>
> ...<snip>...
>
>> So in summary, there are 2 issues we need to fix in GlassFish:
>>
>> 1. Consider the "isSecure" cookie property in sun-web.xml.
>>
>> 2. Consider the cookie-properties from sun-web.xml not only for
>> JSESSIONID,
>> but also JSESSIONIDSSO cookies.
>>
>> Does this answer your question?
>> If so, please feel free to file an RFE on this.
>
>
> Yes, thank you. I've filed these RFEs:
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=3822
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=3823
>
Great!
Thanks!
Jan
> --Jamey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>