Bug 811990 - regenerate proxy auth token when hostname changes from url parsing
regenerate proxy auth token when hostname changes from url parsing
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: Proxy Server (Show other bugs)
1.8
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Suchý
Red Hat Satellite QA List
:
Depends On:
Blocks: space18
  Show dependency treegraph
 
Reported: 2012-04-12 09:21 EDT by Shannon Hughes
Modified: 2012-11-01 12:18 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-01 12:18:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to regenerate proxy auth token with url parsed hostname changes (975 bytes, patch)
2012-04-12 09:21 EDT, Shannon Hughes
no flags Details | Diff

  None (edit)
Description Shannon Hughes 2012-04-12 09:21:09 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.
http://sat541-rhel5.shughes.sat/ks/cfg/org/1/label/patience 
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
Comment 1 Miroslav Suchý 2012-04-12 10:59:08 EDT
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.
Comment 2 Shannon Hughes 2012-04-12 11:03:36 EDT
the other thought is to separate out the hostname from the auth header. let the hostname have its own header that satellite uses.
Comment 3 Miroslav Suchý 2012-04-12 11:37:02 EDT
self.hostname in your patch is efectively set in broker/rhnBroker.py by reading Host header from incoming request. If you access proxy by 1.2.3.4 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.
I.e.:
    def __cache_proxy_key(self):
-        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?
Comment 4 Shannon Hughes 2012-04-12 17:19:17 EDT
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?
Comment 5 Shannon Hughes 2012-04-12 17:36:01 EDT
...and yes, I can test this. Already have a dual proxy setup chained to a satellite.
Comment 6 Miroslav Suchý 2012-04-13 03:36:53 EDT
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()
Comment 7 Shannon Hughes 2012-04-13 09:01:08 EDT
pushed to master using msuchy recommendation in comment #3, 

To ssh://git.fedorahosted.org/git/spacewalk.git/
   e08c0a1..57598ac  master -> master


Tested using two proxies and server: 

client -> proxyA -> ProxyB -> Server

Kickstart installs passed, Yum updates on client passed
Comment 9 Jan Pazdziora 2012-10-30 15:23:07 EDT
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Comment 10 Jan Pazdziora 2012-11-01 12:18:13 EDT
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18

Note You need to log in before you can comment on or make changes to this bug.