08-16-2017 08: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 04: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 09:52 AM
Excellent. Thank you!
08-18-2017 10:06 AM
Is there anything else at all that will set the user context but free up the thread without clearing that context? Like logging into the share GUI and performing any actions there?
We don't really have a lot of custom code. I believe all of our custom code are web scripts with user authentication specified.
08-18-2017 10:18 AM
Only the HTTP requests to Alfresco Repository count for your case - Share only matters indirectly via the web scripts that get called from Share.
There are some sub-divisions that can be made, i.e. HTTP requests can only affect/infect the threads used by the Tomcat connector for handling HTTP requests and authentication issues do not "spread over" to background processes, while background processes / threads are isolated based on the thread pool / factory that is being used. If you are using a Tomcat executor thread pool, HTTP / HTTPS / AJP can affect each other, otherwise those are isolated as well, which can help in pinpointing the type of request that triggers it (e.g. if only HTTP is affected and your SOLR runs via HTTPS, it definitely will not have been caused by any of the SOLR data web scripts)
Most often I have seen such a problem with CRON-based jobs because those do not run in any authentication context by default and it is the responsibility of the implementer to do a runAsUser (and some are lazy and just to setRunAsUser instead).
Explore our Alfresco products with the links below. Use labels to filter content by product module.