How is the user chosen for no authentication web scripts?

cancel
Showing results for 
Search instead for 
Did you mean: 
thmsdrew
Member II

Re: How is the user chosen for no authentication web scripts?

Jump to solution

Excellent. Thank you!

thmsdrew
Member II

Re: How is the user chosen for no authentication web scripts?

Jump to solution

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.

afaust
Master

Re: How is the user chosen for no authentication web scripts?

Jump to solution

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).