Hi,
I’m having trouble getting glassfish 3.1.1 to work correctly with SSL
redirection when used with iptables redirect.
I am using iptables to route port 80 to port 8282, and port 443 to port 8383
(similar to how things are described at
http://www.nabisoft.com/tutorials/glassfish/installing-glassfish-31-on-ubuntu).
I have two new http listeners for ports 8282 and 8383. 8282 has security
off, while 8383 has it on (so it is SSL).
I have the originals listeners still at 8080 and 8181 (with SSL on 8181).
Listener 1 has no redirect port specified, so it does the default which
appears to be 8181. For the 8282 listener I have SSL redirection specified
as 443.
I’m testing all of this behind the firewall, so the firewall is not the
issue.
My app requires SSL, and is set as such. So docroot pages can be requested
with either http or https, but any links to my app URL’s cause redirect to
the SSL port and to the logon page.
Going direct works for all four ports: http to 8080, 8282, https to 8181 and
8383. Also, direct http client requests to 80 work (redirected via iptables
to 8282) and direct https SSL client requests to 443 work (redirected via
iptables to 8383).
If I access my app (that requires SSL) via 8080, glassfish redirects the
request nicely to 8181. If I access my app URL’s via http on 8282,
glassfish redirects the request to SSL port 443 (which is redirected by
iptables to 8383) and works fine. However, if I access my app via http and
port 80 (no port override), glassfish attempts to SSL redirect to 443 but
fails. I get a blank page and the following exception:
******
[#|2011-10-02T16:48:00.259-0500|INFO|glassfish3.1.1|javax.enterprise.system.core.security|_ThreadID=29;_ThreadName=Thread-2;|JACC
Policy Provider:Failed Permission Check: context (" myapp/myapp-war_war ") ,
permission (" (javax.security.jacc.WebUserDataPermission /logon.faces GET) ")
|#]
[#|2011-10-02T16:48:00.262-0500|WARNING|glassfish3.1.1|org.apache.catalina.authenticator.FormAuthenticator|_ThreadID=29;_ThreadName=Thread-2;|Unexpected
error forwarding or redirecting to login page
java.lang.ArrayIndexOutOfBoundsException: 1
at
com.sun.web.security.RealmAdapter.getHostAndPort(RealmAdapter.java:971)
at com.sun.web.security.RealmAdapter.redirect(RealmAdapter.java:1090)
at
com.sun.web.security.RealmAdapter.hasUserDataPermission(RealmAdapter.java:941)
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:450)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:253)
at
com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1326)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:327)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at
com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
|#]
So even though iptables is causing accesses on 8282 and 80 to both end up at
port 8282 when glassfish gets it, glassfish is having trouble with the
redirect if the original request actually was sent to 80.
I also tried changing the 8282 listener’s SSL redirect port from 443 to be
the default (8181) and when client http requests to port 80 needs to be
redirected by glassfish to do SSL, I get the same failure. But again http
client requests to port 8282 redirects to, in this case, https requests on
port 8181 just fine with no failure.
3.0.1 does NOT seem to have this issue, things are working fine with that
install. 3.1.0 might have worked, but I'm not sure on that.
I searched and could not find any links about this issue (a couple seemed
close perhaps). I would think a lot of glassfish installs would have
iptables doing redirects (to avoid running as root) and thus this would be a
big issue. Does anyone know what I could be doing wrong, or if this is a
known bug, hopefully with a work around.
Thanks,
Mark
--
[Message sent by forum member 'markkr2']
View Post: http://forums.java.net/node/849730