Emails using wrong {shareUrl}

JasonB

Basic Info:

• Alfresco Community 6.2 build
• Running in Bitnami image on Azure
• SSL secured site with a let’s encrypt certificate successfully installed, and can use Alfresco for other things successfully.

The system generated email messages for the workflow all direct to the wrong URL. I’ve replaced the starting part of the URL with mycompanyURL, but the rest is accurate and functional.
http://mycompanyURL.azure.com:8080/share/page/task-edit?taskId=activiti$1445

If I override the built-in URL manually with the following, I get to the intended workflow task.
https://mycompanyname.azure.com/share/page/task-edit?taskId=activiti$1445

This might be a problem with more system-generated email messages, but this was the first one we encountered trying to use the outbound email setup.

I’m guessing this is a configuration setting, but not sure how to correct it.
In the /opt/bitnami/apache-tomcat/shared/classes/alfresco-global.properties I found the following but messing with those caused all kinds of system chaos, so they are back to original settings.

alfresco.context=alfresco
alfresco.host=mycompanyname.azure.com
alfresco.port=8080
alfresco.protocol=http

share.context=share
share.host=mycompanyname.azure.com
share.port=8080
share.protocol=http
For my setup, http and 8080 are locked down as all traffic needs to be secured via SSL. However, the above is what is the settings are in the alfresco-global.properties file are.

Looking at the Email Templates - Workflow Notification - the link is specified as follows:

${shareUrl}/page/task-edit?taskId=${args.workflowId}
It’s the {shareUrl} that seems to be malformed and pointing to a default setting that is not accurate. My site has to be accessed via SSL, so https via port 443 as noted above. Normally the port is not specified in the URL when using the system. 

Any suggestions on how to fix this would be greatly appreciated.

Regards,
Jason

JasonB

To resolve the issue, I decided to run a series of experiments on the system. Thankfully, it’s not in production yet, as some of these made the system widely unstable.

Each of the following experiments consisted of changes to the global.properties file.

Experiment 1
alfresco.port=8080 (default)
alfresco.protocol=http (default)
share.port=443 (changed)
share.protocol=http (default)
Results
Alfresco Site seems to work.
Emails now include:
http://mycompanyURL.azure.com:443/share/page/task-edit?taskId=activiti$1647
Clicking on that links send me to a “400 Bad Request” error page
You can’t mismatch 443 with http. You either change both or neither of them.

Experiment 2
alfresco.port=8080 (default)
alfresco.protocol=http (default)
share.port=443 (changed)
share.protocol=https (changed)
Results
Alfresco Site seems to work.
Emails now include:
https://mycompanyURL.azure.com/share/page/task-edit?taskId=activiti$1747

Experiment 3
alfresco.port=8080 (default)
alfresco.protocol=http (default)
share.port= (changed)
share.protocol=https (changed)
Results
Alfresco Site becomes completely unstable, with the top frame showing the following error.
An error has occured in the Share component: /share/service/components/dashlets/my-sites.
It responded with a status of 500 - Internal Error.
Error Code Information: 500 - An error inside the HTTP server which prevented it from fulfilling the request.
Error Message: 04210001 Failed to execute script 'classpath*:alfresco/site-webscripts/org/alfresco/components/dashlets/my-sites.get.js': 04210000 04210001 Failed during processing of IMAP server status configuration from Alfresco: 04210000 Unable to retrieve IMAP server status from Alfresco: 401
Server: Alfresco Spring WebScripts - v7.10.0 schema 1,000
Time: May 21, 2020, 2:55:55 PM
Your request could not be processed at this time. Please contact your system administrator for further information.

Final Commentary:
I had also tried other variations that caused the system to be unstable or not have the desired result. Do not mess with the alfresco.port or alfresco.protocol ports, despite the mismatch from the systems SSL requirements. The key seems to be the following:
share.port=443 (changed)
share.protocol=https (changed)
That is not the most obvious change combination, as somewhere in the code when you specify https, it automatically hides the port from being added to the URL. I did not see that combination in the documentation anywhere I could find. This combination is important when securing the site with SSL, as without it, all the emails sent from the system have the wrong link.