standalone arts and mcop authentication

[Kevin Stefanik]

I'm attempting to use the standalone arts and artsd's network transparency to 
handle sound from a server (kde is running on the server) on a diskless 
workstation.  It works fine with no authentication, but I think there's a 
fundamental problem in the mcop authentication protocol when artsd and, say, 
artsdsp are running on different computers.  

From the documentation, the ServerHello includes the random cookie that is to 
be mangled with the secret cookie to make an md5 hash.  The client does this 
and sends it back to authenticate - proving it has the secret cookie.  Then 
the server sends back a response that includes the 'hints' about what 
GlobalComm mechanism to use.  

In the Dispatcher, the connectUrl call causes the authentication exchange to 
occur before the TmpGlobalComm or X11GlobalComm has been selected or 
initialized - so there's no secret cookie yet.  The mangling fails on an 
assertion that the cookie has been initialized (md5_init).

To see this quickly, look in dispatcher.cc, where the connectUrl preceeds the 
//MD5-Auth initialization section.  This problem only occurs when ARTS_SERVER 
is set.

One relatively easy fix would be to create an AuthDenied message that still 
had the hints attached.  The client could connect, fail to authenticate 
correctly, but still get the hint back to use, for instance X11GlobalComm, to 
find the secret-cookie.  Any down side to this?

What I've done is just delay connecting at all until after the mcoprc file is 
used to find the GlobalComm or TmpGlobalComm is initialized.  The hints are 
ignored. This solution could also use the GlobalComm get() to also figure out 
the ARTS_SERVER instead of the environment variable.  That makes it easy to 
tie the sound output to the X server that's managing the relevant window.

If it has a reasonable chance of getting into future releases, I'll be glad to 
do some coding on this.  Please cc me on any replies.

Thanks,
Kevin Stefanik