Bug 811990 - regenerate proxy auth token when hostname changes from url parsing
Summary: regenerate proxy auth token when hostname changes from url parsing
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Proxy Server
Version: 1.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space18
TreeView+ depends on / blocked
 
Reported: 2012-04-12 13:21 UTC by Shannon Hughes
Modified: 2012-11-01 16:18 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-01 16:18:13 UTC
Embargoed:


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

Description Shannon Hughes 2012-04-12 13:21:09 UTC
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 14:59:08 UTC
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 15:03:36 UTC
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 15:37:02 UTC
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 21:19:17 UTC
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 21:36:01 UTC
...and yes, I can test this. Already have a dual proxy setup chained to a satellite.

Comment 6 Miroslav Suchý 2012-04-13 07:36:53 UTC
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 13:01:08 UTC
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 19:23:07 UTC
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 16:18:13 UTC
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.