topic Re: How is the user chosen for no authentication web scripts? in Alfresco Forum

How is the user chosen for no authentication web scripts?

thmsdrew — Thu, 17 Aug 2017 00:16:00 GMT

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

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

douglascrp — Thu, 17 Aug 2017 13:04:34 GMT

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?

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

thmsdrew — Thu, 17 Aug 2017 13:20:30 GMT

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.

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

douglascrp — Thu, 17 Aug 2017 13:35:01 GMT

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.

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

thmsdrew — Thu, 17 Aug 2017 13:40:47 GMT

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.

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

douglascrp — Thu, 17 Aug 2017 13:55:21 GMT

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?

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

thmsdrew — Thu, 17 Aug 2017 14:47:05 GMT

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.

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

afaust — Thu, 17 Aug 2017 20:45:14 GMT

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.

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

thmsdrew — Fri, 18 Aug 2017 13:22:00 GMT

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?

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

afaust — Fri, 18 Aug 2017 13:42:04 GMT

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.

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

thmsdrew — Fri, 18 Aug 2017 13:52:19 GMT

Excellent. Thank you!

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

thmsdrew — Fri, 18 Aug 2017 14:06:00 GMT

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.

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

afaust — Fri, 18 Aug 2017 14:18:34 GMT

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