Authorization errors when authenticating via XmlRpc

[Ryan J Ollos]

I'm seeing the following error when trying to execute commands with XmlRpc.

2013-01-24 15:01:29,529 Trac[web_ui] DEBUG: RPC incoming request of content type 'text/xml' dispatched to <tracrpc.xml_rpc.XmlRpcProtocol object at 0x1f6f7290>
2013-01-24 15:01:29,529 Trac[web_ui] DEBUG: RPC(XML-RPC) call by 'anonymous'
2013-01-24 15:01:29,530 Trac[xml_rpc] DEBUG: RPC(xml) call by 'anonymous', method 'ticket.milestone.getAll' with args: ()
2013-01-24 15:01:29,531 Trac[authz_policy] DEBUG: Checking XML_RPC on
2013-01-24 15:01:29,532 Trac[perm] DEBUG: No policy allowed anonymous performing XML_RPC on None
2013-01-24 15:01:29,533 Trac[web_ui] ERROR: RPC(XML-RPC) Error
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/tracrpc/web_ui.py", line 149, in _rpc_process
    req.perm.require('XML_RPC') # Need at least XML_RPC
  File "/usr/local/python26_trac12/lib/python2.6/site-packages/Trac-0.12.3-py2.6.egg/trac/perm.py", line 576, in require
    raise PermissionError(action, resource, self.env)
PermissionError

Further up in the logs I see:

2013-01-24 15:01:29,472 Trac[web_ui] DEBUG: LoginModule._remote_user: Authentication attempted for 'None'
2013-01-24 15:01:29,473 Trac[web_ui] WARNING: LoginModule.authenticate: 'REMOTE_USER' was set to 'jenkins'
2013-01-24 15:01:29,473 Trac[web_ui] DEBUG: LoginModule.authenticate: Set 'REMOTE_USER' = 'None'

The issue seems to be with this bit of code in web_ui's LoginModule.authenticate method:

if not 'REMOTE_USER' in req.environ or self.environ_auth_overwrite:
    if 'REMOTE_USER' in req.environ:
        # Complain about another component setting environment
        # variable for authenticated user.
        self.env.log.warn("LoginModule.authenticate: "
                          "'REMOTE_USER' was set to '%s'"
                          % req.environ['REMOTE_USER'])
        self.env.log.debug("LoginModule.authenticate: Set "
                           "'REMOTE_USER' = '%s'" % user)
        req.environ['REMOTE_USER'] = user

[Steffen Hoffmann]

acct_mgr.web_ui.LoginModule is going in the way of an already successfully authenticated request here.

The successful authentication is most probably done by the xmlrpclib code. But now AcctMgr's LoginModule is not designed to accept another authenticator's decision. The recently introduced 'environ_auth_overwrite' option will only allow to preserve another username on AcctMgr's LoginModule authentication success, if you insist (false by default). Here it (reasonably) invalidates the pre-set authenticated user, because it fails to authenticate the request itself.

Currently there's no option for acct_mgr.web_ui.LoginModule to rely on another authenticator's decision and just pass-through the REMOTE_USER unconditionally. So XMLRPC and AcctMgr's HTML login form can't happily co-exist right now. Given the history of ignorance regarding features requested for XmlRpcPlugin (#1001) this is not a surprise.

Call it a defect or just a documentation issue. I'll be happy to accept whatever osimons recommends as the preferred solution. I just remember vaguely, that he doesn't care much about the AccountManagerPlugin for authentication either.

[Steffen Hoffmann]

Hm, the last comment probably sounds harsh, what wasn't intended at all. Saying it differently here:

Would it be valuable to have another option for handling the REMOTE_USER environment variable in AcctMgr LoginModule's authenticate method? Something, that effectively means "Don't touch previous authentication at all.". Maybe even "Don't care about checking, if already done by some other component'.'"?

[Steffen Hoffmann]

Possibly required development would effectively follow-up on work for #8545.

[osimons]

The RPC plugin has no preference for authentication, and is not involved in any part of the user authentication and permission handling. All it does is access req.authname and req.perm and friends, and will happily use whatever is configured in front.

The general problem is Python xmlrpclib that only knows how to speak Basic Authentication. Not even Digest, just Basic. Other libraries (and in other languages) sometimes support more, but of course none would support Account Manager or any other forms login seeing that can't be done in a generic manner. Nothing stopping anyone from writing client code to do it: In bitten.slave client we rolled our own authentication handling using standard urllib (1 and 2) and added Account Manager form posting as one option. Bitten is not RPC code, but the implementation would be identical as bitten.master like tracrpc is not involved with either authentication or permissions.

The lowest common denominator for RPC is therefore Basic Authentication, and this is the reason why HttpAuthPlugin exists. It provides some pseudo-basic-auth implementation for configured paths (like /login/rpc). If you rely on Account Manager and RPC this plugin (or some other custom auth handling) is required, and whatever issue is raised in this ticket belongs with AccountManagerPlugin and/or HttpAuthPlugin.

Sadly I use neither plugin so I cannot advice further at code-level, but will happily try to answer specific questions if I can.

BTW, #1001 is something completely different as that is about adding a new RPC method to make information about registered users available to calling clients.

[anatoly techtonik]

My opinion that options like environ_auth_overwrite make Trac config overly complicated for occasional user. Implementing #10827 may replace the hacks with interoperable API.

[Steffen Hoffmann]

Replying to techtonik:

My opinion that options like environ_auth_overwrite make Trac config overly complicated for occasional user. Implementing #10827 may replace the hacks with interoperable API.

Great. I remember feeling rather alone with that other-ones issue at that time and would certainly have done differently with more involvement like yours now. I don't like option bloat too. If I had seen a way for going without another option ..., well I'll have a look forward, and thanks for taking care.

Btw, do you feel the default value for the aforementioned option is a bad choice, or why do you think the occasional user will even bother with touching it?