Staging Issue (Bug or Configuration?)

[Graham Horne, geändert vor 9 Jahren.]

My problem is that staging only works from the initial (parent) instance of Liferay but not for the other 2 portal server instances on my servers. The production system has 2 x Liferay servers as a cluster and 1 x separate staging server. There are 3 portal instances (different virtual host names) on each environment with slightly different virtual host names for staging and production. Both environments have the same user accounts with the same details created in different databases during the initial install. The properties for both the production and staging environments are largely the same other than the minor differences to support clustering, different databases etc. There is a portal-ext.properties file which defines the bulk of the properties for all instances with a separate instance properties file for each portal instance containing only the differences between instances (LDAP baseDN for user search, OpenAM login & logout URL’s). I actually use OpenAM for authentication in production but that just uses the same ldap data for authentication and for this problem I have also removed both LDAP and OpenAM from the scenario just to keep it simpler so it is using the Liferay DB for authN. This is starting to look like a bug as I think I have tried this anyway possible with the same result or worse. This is not a live system but is getting ready for TEST and then UAT.

Using tcpdump on the REMOTE_SERVER (production) and listening for packets from the LOCAL_SERVER (staging), I have captured the different network conversations.

1. After the initial TCP handshake the LOCAL_SERVER sends a POST to http://REMOTE_IP:8080/portal/api/liferay/do
2. After more TCP handshaking the REMOTE_SERVER sends a HTTP 200 (Success) back to the LOCAL_SERVER along with a JSESSIONID COOKIE

On failure the LOCAL_SERVER then sends a FIN (End the conversation)
On success there is an ongoing conversation between the servers with more LOCAL_SERVER POST to http://REMOTE_IP:8080/portal/api/liferay/do and more replies from the REMOTE_SERVER as HTTP 200 (Success) back to the LOCAL_SERVER including new JSESSIONID COOKIE’s
Clearly they are talking but the LOCAL_SERVER does not like what it hears somehow.

The properties on the REMOTE_SERVER are:
tunnel.servlet.https.required=false
axis.servlet.https.required=false
tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx.xxx.xx.xx.xx
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx
tunneling.servlet.shared.secret=XXXXXXXXXXXXXXXXXXXXXXXXXXX
auth.verifier.TunnelingServletAuthVerifier.hosts.allowed=

The properties on the (Staging) LOCAL_SERVER are:
tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx.xxx.xx.xx.xx
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx.xxx.xx.xx.xx
tunneling.servlet.shared.secret=XXXXXXXXXXXXXXXXXXXXXXXXXXX
auth.verifier.TunnelingServletAuthVerifier.hosts.allowed=

By setting the TunnelingServletAuthVerifier to debug I get the following stack trace and output on the REMOTE_SERVER which would lead me to think there is an authentication issue so I have changed the shared keys on all servers, changed the user passwords in both REMOTE and LOCAL environments with the same result. Computer say no…..
14:48:32,396 DEBUG [http-apr-10.1.1.176-8080-exec-2][TunnelingServletAuthVerifier:122] Encoded credentials xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
14:48:32,403 DEBUG [http-apr-10.1.1.176-8080-exec-2][TunnelingServletAuthVerifier:129] Decoded credentials [e-mail]:xxxxxxxxxxxxxxxxxxxxxxxxQ=
14:48:32,414 DEBUG [http-apr-10.1.1.176-8080-exec-2][TunnelingServletAuthVerifier:70] null
com.liferay.portal.security.auth.RemoteAuthException
at com.liferay.portal.security.auth.TunnelingServletAuthVerifier.verify(TunnelingServletAuthVerifier.java:200)
at com.liferay.portal.security.auth.TunnelingServletAuthVerifier.verify(TunnelingServletAuthVerifier.java:60)
at com.liferay.portal.security.auth.AuthVerifierPipeline._verifyRequest(AuthVerifierPipeline.java:325)
at com.liferay.portal.security.auth.AuthVerifierPipeline.verifyRequest(AuthVerifierPipeline.java:75)
at com.liferay.portal.security.ac.AccessControlImpl.verifyRequest(AccessControlImpl.java:96)
at com.liferay.portal.security.ac.AccessControlUtil.verifyRequest(AccessControlUtil.java:69)
at com.liferay.portal.servlet.filters.authverifier.AuthVerifierFilter.processFilter(AuthVerifierFilter.java:134)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:59)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:204)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:109)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:169)
at com.liferay.portal.servlet.filters.jsoncontenttype.JSONContentTypeFilter.processFilter(JSONContentTypeFilter.java:42)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:59)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:204)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:109)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:169)
at com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter.processFilter(VirtualHostFilter.java:226)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:59)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:204)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:109)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:185)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:96)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:738)
MORE BELOW……

[Abderrazak Abidallah, geändert vor 9 Jahren.]

Hi,

I have exactly the same problem actually.
did you find an issue please ?

[Juan Gonzalez, geändert vor 9 Jahren.]

Did you try adding the staging server IP in live server portal-ext.properties?

auth.verifier.TunnelingServletAuthVerifier.hosts.allowed=<staging_server_ip></staging_server_ip>

[Abderrazak Abidallah, geändert vor 9 Jahren.]

Yes, I try it.

I'am tring to call a service builder web service trough the tunnel axis configured like this :

The properties on the REMOTE_SERVER are:
tunnel.servlet.https.required=false
axis.servlet.https.required=false
tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx.xxx.xx.xx.xx
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx
tunneling.servlet.shared.secret=XXXXXXXXXXXXXXXXXXXXXXXXXXX
auth.verifier.TunnelingServletAuthVerifier.hosts.allowed=

The properties on the (Staging) LOCAL_SERVER are:
tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx.xxx.xx.xx.xx
axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP,xxx.xx.xx.xx,xxx.xx.xx.xx,xxx.xx.xx.xx.xxx.xx.xx.xx
tunneling.servlet.shared.secret=XXXXXXXXXXXXXXXXXXXXXXXXXXX
auth.verifier.TunnelingServletAuthVerifier.hosts.allowed=

BUT the web service calls pass on BasicAuthHeaderAutoLogin instead of being trusted by tunnelling authentification .
On a DEV Environnement (not clustered) the web service calls functionned without putting the password on the URL connection (tunnel authentification)
http://[screename]:@xxx.xxx.xxx.xxx:8080/[service-builder-portlet-name]/api/axis/[Service-name]
On an clustered environnement ( 1 Staging, 2 serveur Live clustered ) with the same configuration the calls alwas pass on BasicAuthHeaderAutoLogin and i have to put the password for it functionned, but it's not good.

Serveur Staging Trace :
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.rmi.RemoteException: Authenticated access required
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}hostname:zer33scj

java.rmi.RemoteException: Authenticated access required
at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)

Serveur Live Trace :
11:25:44,511 DEBUG [liferay/audit-3][PortletSessionFactoryImpl:108] Session is using connection release mode on_close
11:25:44,516 INFO [liferay/audit-3][LogAuditRouterProcessor:53] "{"headers":"{\"map\":{\"content-type\":[\"text/xml; charset=utf-8\"],\"cache-control\":[\"no-cache\"],\"host\":[\"xxx.xxx.xxx.xxx:8080\"],\"soapaction\":[\"\\\"\\\"\"],\"accept\":[\"application/soap+xml, application/dime, multipart/related, text/*\"],\"content-length\":[\"8631\"],\"user-agent\":[\"Axis/1.4\"],\"authorization\":[\"Basic c3VwZXJhZG1pbjpub3QtdXNlZA==\"],\"pragma\":[\"no-cache\"]},\"javaClass\":\"java.util.HashMap\"}","reason":"Failed to authenticate by screen name"}","com.liferay.portal.model.User","10203","","","10159","LOGIN_FAILURE","","","0","","20150218112544516","10203","Super Administrateur"
11:25:44,523 ERROR [http-bio-8080-exec-16][AuthVerifierPipeline:331] Skipping com.liferay.portal.security.auth.BasicAuthHeaderAutoLogin
com.liferay.portal.security.auth.AuthException: com.liferay.portal.security.auth.AutoLoginException: com.liferay.portal.security.auth.AuthException