Re: Share published but not Alfresco

pitacsk8 · ‎13 Feb 2014

I want to deploy Alfresco (explorer) and Share on the same server with the same Tomcat with HTTPS via AJP using Apache ProxyPass.

But I only want to publish on the Internet the URL of Share. So the URL are:

(public) https://www.myshare.com/share
(internal) https://internalServerName/alfresco

But a very strange behavior occurs.

These are the main settings:

share-config-custom.xml


<alfresco-config>
    <config evaluator="string-compare" condition="Server">
        <server>
            <scheme>https</scheme>
            <hostname>www.myshare.com</hostname>
            <port>443</port>
        </server>
    </config>
    …
   <config evaluator="string-compare" condition="Remote">
      <remote>
   …
     <endpoint>
      …
         <endpoint-url>https://internalServerName/alfresco/wcs</endpoint-url>
     …
     </endpoint>
    </remote>
   </config>
   
   <config evaluator="string-compare" condition="Remote">
      <remote>
         <endpoint>
         …
           <endpoint-url>https://internalServerName/alfresco/s</endpoint-url>
          …
         </endpoint>
   …
      </remote>
   </config>
…
</alfresco-config>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

alfresco-global.properties


alfresco.context=alfresco
alfresco.host=internalServerName
alfresco.port=443
alfresco.protocol=https
share.context=share
share.host=www.myshare.com
share.port=443
share.protocol=https
‍‍‍‍‍‍‍‍‍‍

THE PROBLEM:
When I call the URL: https://www.myshare.com/share
This is the response:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
   <title>Alfresco &raquo; Panel de inicio de usuario</title>
   <meta http-equiv="X-UA-Compatible" content="IE=Edge" />

   <!– Icons –>
   <link rel="shortcut icon" href="https://internalServerName/share/res/favicon.ico" type="image/vnd.microsoft.icon" />
   <link rel="icon" href="https://internalServerName/share/res/favicon.ico" type="image/vnd.microsoft.icon" />

   <!– YUI –>
   <script type="text/javascript" src="https://internalServerName/share/res/js/yui-common.js"></script>
   <script type="text/javascript" src="https://internalServerName/share/res/js/bubbling.v2.1-min.js"></script>
   <script type="text/javascript">//<![CDATA[
      YAHOO.Bubbling.unsubscribe = function(layer, handler, scope)
      {
         this.bubble[layer].unsubscribe(handler, scope);
      };
   //]]></script>

   <!– Common i18n msg properties –>
   <script type="text/javascript" src="https://internalServerName/share/service/messages.js?locale=es"></script>

   <!– Alfresco web framework constants –>
   <script type="text/javascript">//<![CDATA[
      Alfresco.constants = Alfresco.constants || {};
      Alfresco.constants.DEBUG = false;
      Alfresco.constants.AUTOLOGGING = false;
      Alfresco.constants.PROXY_URI = window.location.protocol + "//" + window.location.host + "/share/proxy/alfresco/";
      Alfresco.constants.PROXY_URI_RELATIVE = "/share/proxy/alfresco/";
      Alfresco.constants.PROXY_FEED_URI = window.location.protocol + "//" + window.location.host + "/share/proxy/alfresco-feed/";
      Alfresco.constants.THEME = "chapTheme";
      Alfresco.constants.URL_CONTEXT = "/share/";
…
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I've noticed that the freemarker variable ${url.context} is rendered like "https://internalServerName/share" when it's inside an attribute href or src, but when it's in another place, like for example the javascript code that we can see above, it's rendered only "/share".

Stated another way, if I put the next on a .ftl:


<div>${url.context}</div>
<a href="${url.context}">click</a>
‍‍‍‍

This is the result:


<div>/share</div>
<a href="https://internalServerName/share">click</a>
‍‍‍‍

The expected result is that the value of $ {url.context} was always "/share", but not!

The problem is that if you are on the Internet on https://www.myshare.com/share you cannot see the internal URLs like https://internalServerName/share/res/js/yui-common.js

I am not able to figure out why it can be produced this behavior. Can anyone help me? Thanks.

cristinamr · ‎1 Mar 2014

Hey pitacsk8, did you get the solution for this issue?

Cheers,

Cristina.

--
VenziaIT: helping companies since 2005! Our ECM products: AQuA & Seidoc

pitacsk8 · ‎1 Mar 2014

I've been working a lot on this problem, but I couldn't fix it. Currently, I've to choose between publish both or neither.

Please, can anybody help us? Any track?

cristinamr · ‎1 Mar 2014

I will try to help you. Well, in one client I had the same situation, in my case we did the following configuration and works:

On alfresco-global.properties


alfresco.context=alfresco
alfresco.host=internal.url
alfresco.port=1234
alfresco.protocol=http

share.context=share
share.host=external.url
share.port=80
share.protocol=http
‍‍‍‍‍‍‍‍‍‍‍

ON my share-config-custom.xml


<config evaluator="string-compare" condition="Remote">
      <remote>
         <endpoint>
            <id>alfresco-noauth</id>
            <name>Alfresco - unauthenticated access</name>
            <description>Access to Alfresco Repository WebScripts that do not require authentication</description>
            <connector-id>alfresco</connector-id>
            <endpoint-url>http://internal.url:1234/alfresco/s</endpoint-url>
            <identity>none</identity>
         </endpoint>

         <endpoint>
            <id>alfresco</id>
            <name>Alfresco - user access</name>
            <description>Access to Alfresco Repository WebScripts that require user authentication</description>
            <connector-id>alfresco</connector-id>
            <endpoint-url>http://internal.url:1234/alfresco/s</endpoint-url>
            <identity>user</identity>
         </endpoint>

         <endpoint>
            <id>alfresco-feed</id>
            <name>Alfresco Feed</name>
            <description>Alfresco Feed - supports basic HTTP authentication via the EndPointProxyServlet</description>
            <connector-id>http</connector-id>
            <endpoint-url>http://internal.url:1234/alfresco/s</endpoint-url>
            <basic-auth>true</basic-auth>
            <identity>user</identity>
         </endpoint>
      </remote>
   </config>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Well, in our case we detected that sometimes instead to load /share, it was forcing to load /alfresco and for that issue we did this in the ftls:


 <a href="${url.context?replace("alfresco","share")}/page/result-details?nodeRef=${nodeResult.nodeRef?string}"  target="result">${nodeResult.properties["cm:title"]?string}</a>
‍‍‍

We haven´t anything more configure.. Can you check your config and tell me if it´s persisting your problem?

Cheers,

Cris.

--
VenziaIT: helping companies since 2005! Our ECM products: AQuA & Seidoc

pitacsk8 · ‎3 Mar 2014

Thank you for your reply CristinaMR. The configuration seems to be de same. But I hadn't thought of modifying the ftls. Have you modify all the ftls of Share?

cristinamr · ‎3 Mar 2014

pitacsk8: Nop. We detected some FTLs of Share, when we call them, instead to have Share´s context got the Alfresco´s context, for that reason we did this change.
But in general, I think that you´re behaviour is strange. Give me some time and I will ask to one college (I hope that we can help you).

Cris.

--
VenziaIT: helping companies since 2005! Our ECM products: AQuA & Seidoc

pitacsk8 · ‎4 Mar 2014

Thanks CristinaMR, I hope that someone can help me

cristinamr · ‎4 Mar 2014

pitacsk8, try this:

1. Rename your share-config-custom.xml to share-config-custom.xml.original
2. Create a new xml call share-config-custom.xml and paste this config with your configuration (internal.url and port):


<config evaluator="string-compare" condition="Remote">
      <remote>
         <endpoint>
            <id>alfresco-noauth</id>
            <name>Alfresco - unauthenticated access</name>
            <description>Access to Alfresco Repository WebScripts that do not require authentication</description>
            <connector-id>alfresco</connector-id>
            <endpoint-url>http://internal.url:PORT/alfresco/s</endpoint-url>
            <identity>none</identity>
         </endpoint>
 
         <endpoint>
            <id>alfresco</id>
            <name>Alfresco - user access</name>
            <description>Access to Alfresco Repository WebScripts that require user authentication</description>
            <connector-id>alfresco</connector-id>
            <endpoint-url>http://internal.url:PORT/alfresco/s</endpoint-url>
            <identity>user</identity>
         </endpoint>
 
         <endpoint>
            <id>alfresco-feed</id>
            <name>Alfresco Feed</name>
            <description>Alfresco Feed - supports basic HTTP authentication via the EndPointProxyServlet</description>
            <connector-id>http</connector-id>
            <endpoint-url>http://internal.url:PORT/alfresco/s</endpoint-url>
            <basic-auth>true</basic-auth>
            <identity>user</identity>
         </endpoint>
      </remote>
   </config>
 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

3. Restart and try it

--
VenziaIT: helping companies since 2005! Our ECM products: AQuA & Seidoc

cybermakoki · ‎4 Mar 2014

Hi pitacsk8,

Besides what CristinaMR says, I think that you can use the default configuration of share-config-custom.xml (with localhost) and configure your alfresco-global.properties like this:


alfresco.context=alfresco
alfresco.host=www.myshare.com
alfresco.port=443
alfresco.protocol=https
share.context=share
share.host=www.myshare.com
share.port=443
share.protocol=https
‍‍‍‍‍‍‍‍‍‍

and then, in your apache configuration, only configure access for share with something similar to this:


<VirtualHost *:80>
    ServerName www.myshare.com

    […]
   
    RewriteEngine On
    RewriteRule ^/$ share [R]

    ProxyPass /share ajp://localhost:8009/share
    ProxyPassReverse  /share  ajp://localhost:8009/share

</VirtualHost>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍

cristinamr · ‎4 Mar 2014

I'm agree with cybermakoki: Try this too and close your fingers!

--
VenziaIT: helping companies since 2005! Our ECM products: AQuA & Seidoc

Share published but not Alfresco

Share published but not Alfresco