Alfresco Share 5, using “authority.ftl” form control

Last week I was designing an Alfresco Content Model including a property to gather a set of Alfresco users to be sent to an external service.

I remembered about authority.ftl form control, which is a picker that could fit fine with my requirements.

I searched about the control at official documentation

… and also in the Community.

After some research inspecting Alfresco source code, I realised that this control is auto-configured depending on the definition of the property to be rendered.

      itemType: "${field.endpointType}",
      multipleSelectMode: ${field.endpointMany?string},
      itemFamily: "authority"

So to include a form control to select MANY USERS following content model should be declared in Repository part.

<aspect name="ks:defaultSigners">
		<association name="ks:alfrescoUser">

And a simple form control association in Share part makes the work.

<field id="ks:alfrescoUser">
    <control template="/org/alfresco/components/form/controls/authority.ftl"/>

Also relevant for this use case the addon provided by Douglas C. R. Paes at Alfresco Colleagues Picker Form.

Sometimes a small investigation before developing your tasks will save you many time and will produce an easier solution.


How to develop a SOAP client from Alfresco Repository

Due to integration requirements with legacy old systems, it happens that Alfresco Repository must invoke an external SOAP endpoint. As Alfresco Repository web application includes a changing JAR Library catalog, using an out-of-the-box implementation to build SOAP clients is advisable.

The target scenario

I selected a sample Global Weather SOAP Web Service endpoint available at 

Starting from WSDL is always a must when build a SOAP Web Service for both client and server parts.

Alfresco repository will invoke this endpoint from a Web Script to proxy parameters and results in a REST invocation.

Creating an standard JAXWS client project

Source code available at

Once the project is compiled with Maven, client Java classes are packaged into the target JAR. In order to use this client, simple invocations can be done.

GlobalWeather service = new GlobalWeather(new URL(""));
String cities = service.getGlobalWeatherSoap().getCitiesByCountry("Spain");

In order to make the JAR available to Maven for next step, an installation is required.

$ mvn clean install

Creating an Alfresco Repository Module for Web Scripts

Source code available at

As JAXWS client does not include any external dependency, the library can be included directly in pom.xml file.

Web Scripts are defined in a standard way:

SOAP Endpoint URL has been declared as property in to make easier changes in the configuration.

Inside Java controller implementation, SOAP JAXWS standard client is invoked:

String country = req.getServiceMatch().getTemplateVars().get("country");

GlobalWeather service = new GlobalWeather(new URL(url));
String cities = service.getGlobalWeatherSoap().getCitiesByCountry(country);

Map<String, Object> model = new HashMap<String, Object>();
model.put("cities", cities);
return model;


Once the project is deployed or even using script from Maven project, SOAP services can be accessed by using Alfresco REST API.



Including new features inside Alfresco Repository is not a complex project, but using the simplest way is always worthy: upgrading and updating processes will be as safe as the are!


SSL issues and how to debug iOS App for Alfresco

Some days ago we faced a problem connecting from Alfresco iOS App (aka Alfresco Content Services App) to an HTTPs server.

When using the App from a device, checking server connection step was failing.

As there was no clue at HTTP server, we decided to debug the application from Xcode.

The source code is available at but no documentation for newbies is available, so Bhagyas assisted me at Alfresco IRC to configure the environment. He wrote a wonderful shell script to help with this configuration task at Loftux Github.

Once we were able to debug by using a Simulator, we identified the real error.

2017-12-09 09:42:39.451818+0100 AlfrescoApp[4530:53914] DEBUG (null) Network reachable: YES
2017-12-09 09:42:39.457163+0100 AlfrescoApp[4530:53914] DEBUG (null) Network reachable: YES
2017-12-09 09:42:39.461917+0100 AlfrescoApp[4530:53914] DEBUG [AlfrescoDefaultHTTPRequest connectWithURL:method:session:requestBody:outputStream:completionBlock:] GET https://server:443/alfresco/service/api/server
2017-12-09 09:42:39.695423+0100 AlfrescoApp[4530:83456] TIC Read Status [16:0x600000171f40]: 1:54
2017-12-09 09:42:41.668687+0100 AlfrescoApp[4530:83456] TIC Read Status [17:0x600000173140]: 1:54
2017-12-09 09:42:41.875522+0100 AlfrescoApp[4530:68601] TIC Read Status [18:0x600000173c80]: 1:54
2017-12-09 09:42:41.876473+0100 AlfrescoApp[4530:68601] Task <B9FE693B-AB59-4D26-AA6F-644D67A977E2>.<1> HTTP load failed (error code: -1005 [4:-4])
2017-12-09 09:42:41.876724+0100 AlfrescoApp[4530:83005] Task <B9FE693B-AB59-4D26-AA6F-644D67A977E2>.<1> finished with error - code: -1005
2017-12-09 09:42:41.879106+0100 AlfrescoApp[4530:53914] ERROR [AlfrescoRepositorySession authenticateWithUsername:andPassword:completionBlock:] Server info retrieval failed: The network connection was lost.

Extracted from Apple official documentation at

A: NSURLErrorNetworkConnectionLost is error -1005 in the NSURLErrorDomain error domain, and is displayed to users as “The network connection was lost”. This error means that the underlying TCP connection that’s carrying the HTTP request disconnected while the HTTP request was in progress.

So, the device was shutting down the connection for some reason. And that reason should be related with HTTPs, as we tested that the application was running in plain HTTP.

From reading iOS 11 Security Guide,  we extracted relevant requirements:

  • iOS supports Transport Layer Security (TLS v1.0, TLS v1.1, and TLS v1.2, which supports both AES 128 and SHA-2) and DTLS.
  • The RC4 symmetric cipher suite is deprecated in iOS 10 and macOS Sierra.
  • Servers must support TLS 1.2 and forward secrecy, and certificates must be valid and signed using SHA-256 or better with a minimum 2048-bit RSA key or 256-bit elliptic curve key.
  • By default, App Transport Security limits cipher selection to include only suites that provide forward secrecy, specifically ECDHE_ECDSA_AES and ECDHE_RSA_AES in GCM or CBC mode. Apps are able to disable the forward secrecy requirement per-domain, in which case RSA_AES is added to the set of available ciphers.
  • Network connections that don’t meet these requirements will fail, unless the app overrides App Transport Security

We checked configured HTTPs features in our server…

The connection to this site uses TLS 1.2 (a strong protocol), RSA (an obsolete key exchange), and AES_128_CBC with HMAC-SHA1 (an obsolete cipher).

… we changed them to fulfil Apple requirements …

The connection to this site uses TLS 1.2 (a strong protocol), ECDHE_RSA with P-256 (a strong key exchange), and AES_256_CBC with HMAC-SHA1 (an obsolete cipher).

… and Alfresco iOS App started to work with HTTPs!

It’s always great to work with Open Source & Alfresco, as you have the chance to identify and solve every problem!