Hi Craig,
My understanding is that declarative web.xml security rules is the
"official" way to control the protocol scheme with JSF (since I'm unable
to specify it w/ JSF tags).
Sprinkling redirects all over our code and pages to correct the protocol
scheme is rather ugly... I wish there was just a way to specify the POST
scheme with JSF commandLink/Button tags.
As a wrapper around Servlet API, I'd expect to have at least access to
the same functionality. Is this a JSF architecture decision resulting
from technical difficulties allowing the scheme to switch on the command
submission?
Craig McClanahan wrote:
On 1/19/07, Cyril Bouteille <[EMAIL PROTECTED]> wrote:
Hi, I've a problem using JSF/Shale on Sun AS 9.0.1 when deployed behind
an SSL accelerator in production. Because secure requests get to the app
server unencrypted, I am unable to use regular declarative security
user-data-constraint/transport-guarantee/CONFIDENTIAL in web.xml, or it
gets in an infinite loop redirecting to https...
If your accellerator sends the request in on the http port, that is
definitely not going to work ... but why do you need a security
constraint
to enforce this? It seems like something you could do with firewall
rules.
Anyway, so in the meantime, I'd just like to control the schemes on my
links and action post, but JSF doesn't seem to support it!
<commandLink/Button>s don't seem to allow you to change scheme. If you
put a full URL in the action, it fails to find the full URL w/ scheme in
the faces-config.xml...
Is this a Glassfish bug or a JSF oversight?
When you submit a form, JSF is using HTTP POST requests back to the
URL of
the original page URL, which means you cannot change modes. You'll
need to
do a redirect to an appropriate URL to do that.
Or am I missing some other way to programmatically control the scheme of
a JSF command?
I'd appreciate any workaround idea the community would be willing to
share. :)
Thank you,
Craig
