Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
The scenario we are trying to achieve is this:
<Connector port="8443" scheme="https" secure="true" SSLEnabled="false"/>
How will in that case behave:
Let me see if I can explain
<Connector port="8443" scheme="https" secure="false" SSLEnabled="false"/>
a) The socket is doing HTTP over TCP, no SSL
b) request.getScheme returns https, so if the webapplication uses this
to create URLs, they will be prefixed with https
c) if there is a transport user constraints, ie the page is only allowed
to be server CONFIDIENTIAL, tomcat will throw a 403 error
<Connector port="8443" scheme="https" secure="true" SSLEnabled="false"/>
a) The socket is doing HTTP over TCP, no SSL
b) request.getScheme returns https, so if the webapplication uses this
to create URLs, they will be prefixed with https
c) Tomcat handles the transport-guarantee scenario correctly and allows
the request into the application
<Connector port="8443" scheme="https" secure="false" SSLEnabled="true"/>
a) The socket is doing HTTPS over TCP, ie HTTP over SSL over TCP
b) request.getScheme returns https, so if the webapplication uses this
to create URLs, they will be prefixed with https
c) if there is a transport user constraints, ie the page is only allowed
to be server CONFIDIENTIAL, tomcat will throw a 403 error
<Connector port="8443" scheme="https" secure="true" SSLEnabled="true"/>
a) The socket is doing HTTPS over TCP, ie HTTP over SSL over TCP
b) request.getScheme returns https, so if the webapplication uses this
to create URLs, they will be prefixed with https
c) Tomcat handles the transport-guarantee scenario correctly and allows
the request into the application
What you are trying to do is correlate the two values, and you get
locked into the correlation.
For example
1. the assumption that secure=true -> scheme=https is false, there are
other secure protocol than HTTPS
2. the assumption that scheme=https -> secure=true could be valid, but
again is not guaranteed and therefor false, just because the values
don't correlate, the scheme value is only used to create urls, not to
determine if the transport protocol was secure
3. the assumption that secure=false -> scheme=http is also wrong, scheme
could be FTP for all we know, scheme is only used to create urls,
nothing else
4. the assumption that scheme=http -> secure=false is wrong, because the
value scheme doesn't tell you anything about the actual transport, it
only gives you the value to create urls with, so again, this value cant
determin if a request is secure or not.
So when looking at this config, try to open yourself to the possibility
that "secure" has nothing to do with "scheme" and the other way around.
so that is what we have done here,made sure that is clear,
SSLEnabled=true/false - determines if the SSL handshake/enc/dec is done
on the connector itself
scheme = what value to send to the web application
secure = what value to send to the web application
if secure=true -> scheme=https -> SSL on the socket, we would never be
able to achieve the use case in my previous email.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]