cancel
Showing results for 
Search instead for 
Did you mean: 

How is the user chosen for no authentication web scripts?

thmsdrew
Champ in-the-making
Champ in-the-making

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

1 ACCEPTED ANSWER

afaust
Legendary Innovator
Legendary Innovator

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.

View answer in original post

12 REPLIES 12

douglascrp
World-Class Innovator
World-Class Innovator

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?

thmsdrew
Champ in-the-making
Champ in-the-making

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.

douglascrp
World-Class Innovator
World-Class Innovator

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.

thmsdrew
Champ in-the-making
Champ in-the-making

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.

douglascrp
World-Class Innovator
World-Class Innovator

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?

thmsdrew
Champ in-the-making
Champ in-the-making

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.

afaust
Legendary Innovator
Legendary Innovator

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.

thmsdrew
Champ in-the-making
Champ in-the-making

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?

afaust
Legendary Innovator
Legendary Innovator

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.