Basic Info:
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
Solved! Go to Solution.
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.
Hi,
Have you tried to change port 8080 to 443 in the global-propery file?
Hello,
Did you set the test message in the alfresco-global.properties
# Outbound Mail test message on system start up show mail subsystem up. mail.testmessage.to= myname@mydomain.com mail.testmessage.send=true mail.testmessage.subject=Outbound SMTP Alfresco mail.testmessage.text=The Outbound SMTP email subsystem is working
If you don't receive taht message when you start the system, no need to go further...
@ryo39 Too simplistic - just changing the port number creates a protocol mismatch.
@opsys - Outbound messages are sending/receiving properly, that how I know the links are malformed.
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.
Hi @JasonB,
Glad you resolved your issue & thanks for providing your solution - helpful to other users.
Cheers,
Hi,
Hi,
I'm testing Alfresco Community 7 and had also this issue.
To fix it, in alfresco-global.properties I replaced share.host=localhost -> share.host=mydomain.com
share.context=share
#share.host=localhost
share.host=mydomain.com
share.port=443
share.protocol=https
Thanks
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.