Acosix
Authentication seems to have some problem with webscripts having the query parameter “alf_ticket” in the url
I was doing some tests with some applications (still old unfortunately, but out of my control) , which still use webscripts and the query parameter “alf_ticket” and I noticed some authentication errors.
After some testing I noticed that this seems to be related only to webscripts that have the query paramater “alf_ticket” in the url.
To give you a real example to test using the alfresco onlyoffice connector (https://github.com/ONLYOFFICE/onlyoffice-alfresco/ version 8.1.0) that I have been using for quite some time I replicated the error for the "download" webscript that uses precisely the “alf_ticket” in combination with the Bearer header Authorization and only for that ! Other webscripts of the same connector like the “callbackUrl” without the “alf_ticket” on the url work perfectly.
Below is the onlyoffice document server side error (not exactly crystal clear):
[2025-03-13T11:53:57.652] [ERROR] [localhost] [03132025125355] [userId] nodeJS - error downloadFile:url=https://XXX/alfresco/s/parashift/onlyoffice/con
vertertest?alf_ticket=TICKET_XXX;attempt=3;code:null;connect:null Error: Error response: statusCode:500; headers:{"server":"nginx/1.26.
3","date":"Thu, 13 Mar 2025 11:53:57 GMT","content-type":"text/html;charset=UTF-8","transfer-encoding":"chunked","connection":"keep-alive","x-frame-options":"SAMEORIGIN","c
ache-control":"no-cache","expires":"Thu, 01 Jan 1970 00:00:00 GMT","pragma":"no-cache"};
at Request.fResponse (/snapshot/server/Common/sources/utils.js)
at Request.emit (node:events:527:28)
at Request.onRequestResponse (/snapshot/server/Common/node_modules/request/request.js:1066:10)
at ClientRequest.emit (node:events:527:28)
at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:631:27)
at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
at TLSSocket.socketOnData (node:_http_client:494:22)
at TLSSocket.emit (node:events:527:28)
at addChunk (node:internal/streams/readable:315:12)
at readableAddChunk (node:internal/streams/readable:289:9)
at TLSSocket.Readable.push (node:internal/streams/readable:228:10)
at TLSWrap.onStreamRead (node:internal/stream_base_commons:190:23)
By removing the "alfresco-keycloack" amps I do not have the error , hence the doubt that it is something related to how the combination “Bearer header” + “alf_ticket” is handled.
This are the version of the project i'm testing
Keycloack Server : 26.1.2 Alfresco Community 23.4.1 Onlyoffice Document Server: 8.2.2
REPO AMPS de.acosix.alfresco.keycloak.repo-latest.amp (git clone) de.acosix.alfresco.utility.core.repo-1.4.5.amp de.acosix.alfresco.utility.repo-1.4.5.amp onlyoffice-integration-repo.amp (8.1.0)
SHARE AMPS de.acosix.alfresco.keycloak.share-latest.amp (git clone) de.acosix.alfresco.utility.core.share-1.4.5.amp de.acosix.alfresco.utility.share-1.4.5.amp onlyoffice-integration-share.amp (8.1.0)
The handling in Alfresco for alf_ticket is a bit weird, since it is a web script-only feature. In a configuration where keycloak.authentication.sso.enabled=false is used, I would not expect any issue, since Bearer authentication is optional here, and the alf_ticket is transparently handled by Alfresco in the BasicHttpAuthenticatorFactory.
Since the default of the Keycloak integration is to enable SSO, things may be a bit different. There is logic to explicitly check for alf_ticket in the KeycloakAuthenticationFilter as part of checkForSkipCondition, and in the default configuration ticket authentication is allowed (property keycloak.authentication.allowTicketLogons). BUT: alf_ticket in combination with a Bearer would not work (currently), as the Bearer in the request is checked first and effectively overrides the alf_ticket as the more complete/explicit user identifier in the request.
But your short log output does not show if the request was sent also with a Bearer in the authorisation header.
Just to confirm the fact that there is the combination of “alf_ticket” + “Beare header” with the onlyoffice use case I pass you the screenshots taken with "tcpdump" displayed with "wireshark".
In the first one the download call which is the one that fails me, in the logs you see it going successfully because to make it work in testing I replaced the webscript authentication from <authentication>user</authentication> to <authentication>none</authentication> and in the java code I use the authentication service "validate" method to validate the ticket on the “alf_ticket” parameter and is work , but is just a patch a workaround, for my use case.
<webscript>
<shortname>ONLYOFFICE Download URL</shortname>
<description>Download file for editor</description>
<url>/parashift/onlyoffice/download/{type}</url>
<authentication>none</authentication> <= replace user with none just to avoid the error
</webscript>
@Override
public void execute(final WebScriptRequest request, final WebScriptResponse response) throws IOException {
// ADD THIS CODE FOR VALIDATE THE TICKET
String alfTicket = request.getParameter("alf_ticket");
if(StringUtils.isBlank(alfTicket)) {
throw new WebScriptException(Status.STATUS_BAD_REQUEST, "Could not find required 'alf_ticket' parameter!");
}
authenticationService.validate(alfTicket); // Validate a ticket. Set the current user name accordingly.
....
In the second screenshot I show the call to another webscript the callback one which also with the Bearer Header on the authenticates without problems, without the "alf_ticket" as parameter.
If you need more specific information let me know.
So far I cannot reproduce any issue with any default Alfresco web script using a request that contains both Bearer and alf_ticket. In order to evaluate the necessity and effectivity of a fix, I would need to first be able to understand and analyse the core issue, ideally without using a 3rd party module.