Red Hat Bugzilla – Bug 811990
regenerate proxy auth token when hostname changes from url parsing
Last modified: 2012-11-01 12:18:13 EDT
Created attachment 577067 [details]
patch to regenerate proxy auth token with url parsed hostname changes
Description of problem:
The proxy auth token that is cached in /var/cache/rhn/proxy-auth needs to be
regenerated when the hostname changes that is parsed from the url string that
the apache rhnBorker.py code parses. The issue is sometimes clients that use
both ip based urls and canonical hostnames are receiving incorrect generated
kickstart files from the satellite when going through the proxy since the
satellite uses the X-RHN-Proxy-Auth header to know which host string to
substitute in its kickstart file generation. The first client to hit proxy has
its hostname cached inside the proxy auth token so subsequent requests from
other clients are receiving the cached hostname in their kickstart files they
are pulling down.
I am attaching a patch that compares the hostname from the auth cache to the
current hostname for the request and if different, the cache is refreshed.
Steps to Reproduce:
1. setup a kickstart file that can be accessed through the label, e.g.
2. use wget/elinks to access the above link using the ip of the 1st proxy
attached to satellite
3. now use elinks to acesss the link in #1 using proxy hostname and notice the
hostnames in the generated kickstart file are ips
Hmm, I have fear that this will affect Proxies with cnames. If you will be using cname, then you will be relogin on each request. But I'm not sure by reading the code. I will have to try it.
the other thought is to separate out the hostname from the auth header. let the hostname have its own header that satellite uses.
self.hostname in your patch is efectively set in broker/rhnBroker.py by reading Host header from incoming request. If you access proxy by 188.8.131.52 then it is set to this string. If you use hostname1 then it is hostname1. It can be empty only if you use HTTP/1.0 (who use it today?) and in such case socket.gethostname() is used.
but token in authToken are accessed by systemid (__cache_proxy_key() in rhnProxyAuth.py). And if we do not want to allow constant relogin, we should store those tokens using systemid *and* hostname.
- return 'p' + str(self.__serverid)
+ return 'p' + str(self.__serverid) + sha1(self.hostname)
because we could not use pure hostname, because of IDN hostname, which may contain characters not be allowed in file system.
If this will work, then your change will not be needed, because hostname from token will be always equal to self.hostname.
Can you test it Shannon?
nice, i like that approach. on the sha1 conversion are you using hashlib and do you want to leave it as an object or covert to digest when concat as string?
...and yes, I can test this. Already have a dual proxy setup chained to a satellite.
yes, hashlib and digest. I wrote it just from top of my head without verification, so yes - correct way should be
from hashlib import sha1
.... + sha1(self.hostname).hexdigest()
pushed to master using msuchy recommendation in comment #3,
e08c0a1..57598ac master -> master
Tested using two proxies and server:
client -> proxyA -> ProxyB -> Server
Kickstart installs passed, Yum updates on client passed
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18