08-16-2017 05:16 PM
Hi all,
Just curious... if I have a web script with no <authentication> tag in the definition XML, and let's say this web script is responsible for updating document properties, how is the user that the web script runs as chosen? I have seen some very inconsistent results and I'm curious as to what is going on.
Thanks,
Tom
08-17-2017 01:45 PM
Normally, if you use authentication "none", then there will be no authenticated user active and there should not be a "random user" being picked for modifier etc. BUT, I have seen a lot of 3rd-party code that messes up authentication handling.
E.g. if you do a AuthenticationUtil.setRunAsUser(xy) then you are setting that user in the thread context. If that context is not reset at the end of handling a request, then it stays tied to the thread. Since Tomcat reuses threads for HTTP calls (non-predictively, so you could call it "random"), any future request that does not explicitly authenticate a user (like your "none" authentication web script) may "accidentally" run in that user context if it gets processed by the affected thread.
I have rarely seen a valid use case for working with authentication "none". If you do, always use the callback-based AuthenticationUtil.runAsUser(callback, user) variant. NEVER EVER use AuthenticationUtil.setRunAsUser(user) code because chances are - once in a while - you will forget to properly clean up that context.
08-17-2017 06:04 AM
Hello.
When you write your webscript's code, at least using Java, you can use the AuthenticationUtil to run your code as a named user, or as System, with higher privileges.
You said you are seeing inconsistent results. Is this a custom webscript or one of the OOTB ones?
08-17-2017 06:20 AM
This is a custom webscript using Javascript. I assume AuthenticationUtil is similar to specifying <authentication>{none, user, admin, etc.}</authentication> in the desc.xml file.
08-17-2017 06:35 AM
Take a look at this link authentication | Alfresco Documentation
As you can see, you can have an webscript the does not enforce the authentication (with the none) parameter, but that is executed as a nominated user, using the runas parameter.
08-17-2017 06:40 AM
Yes, I'm wondering specifically how a user is chosen if the <authentication> element (which is optional in the first place) is not provided at all.
08-17-2017 06:55 AM
From the Learning Alfresco Web Script book
If you are deploying a JavaScript-backed web script using the repository option, make sure that the web script has the authentication level set and it should not be set as none.
If you do not include the authentication section, the the none option is the default. Again, from the same book:
This is the default value when the authentication tag is also not specified in the description document. It indicates that there isn't any authentication required to run the web script.
In a web script that has authentication specified as none, it will not be possible to interact with the repository.
Can you describe the inconsistent result you are seeing?
08-17-2017 07:47 AM
Basically, the web script is responsible for updating a bunch of documents' properties. First it executes a query via the search API, then it updates a property, then saves for each document returned. I was getting inconsistent errors, but also sometimes it would work. These are the scenarios...
1. It runs successfully, but the documents are showing as updated by a random user... not a user that ran the script, and not the same user each time.
2. It returns instantly with no error.
3. It returns instantly with an "access denied - user does not have the authorization to perform this operation" error
4. It returns instantly with a "Query could not be executed" error
By the way, I've resolved this issue by adding user authentication and passing in an alf_ticket value in the URL... but I'm just curious about why it was behaving so weird in the first place.
08-17-2017 01:45 PM
Normally, if you use authentication "none", then there will be no authenticated user active and there should not be a "random user" being picked for modifier etc. BUT, I have seen a lot of 3rd-party code that messes up authentication handling.
E.g. if you do a AuthenticationUtil.setRunAsUser(xy) then you are setting that user in the thread context. If that context is not reset at the end of handling a request, then it stays tied to the thread. Since Tomcat reuses threads for HTTP calls (non-predictively, so you could call it "random"), any future request that does not explicitly authenticate a user (like your "none" authentication web script) may "accidentally" run in that user context if it gets processed by the affected thread.
I have rarely seen a valid use case for working with authentication "none". If you do, always use the callback-based AuthenticationUtil.runAsUser(callback, user) variant. NEVER EVER use AuthenticationUtil.setRunAsUser(user) code because chances are - once in a while - you will forget to properly clean up that context.
08-18-2017 06:22 AM
Good information, thanks.
I'm assuming that with user authentication configured, my JS web script handles resetting the context itself at the end of the script's run. Is that right?
Also, when I had NO user authentication configured and a seemingly "random" user was being chosen... does this mean we may have other code that is not properly cleaning up its context?
08-18-2017 06:42 AM
Correct, if you set the required authentication than the web script framework takes care to reset the thread-context after completion of the web script call.
And yes, such a problem would mean that you have other code in the system that is not properly cleaning up its context. Finding such instances can be an annoyingly hard task. I did this in one customer project by adding a servlet filter at the top of the web.xml to log out the currently set authentication context (via AuthenticationUtil.getRunAsAuthentication()) at the end of a request along with the URL / HTTP method of that request. That allowed me to pinpoint which requests were leaking for a follow-up analysis of the code handling those URLs.
Explore our Alfresco products with the links below. Use labels to filter content by product module.