Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 811990

Summary: regenerate proxy auth token when hostname changes from url parsing
Product: [Community] Spacewalk Reporter: Shannon Hughes <shughes>
Component: Proxy ServerAssignee: Miroslav Suchý <msuchy>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.8CC: dyordano, jpazdziora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-01 16:18:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 871344    
Attachments:
Description Flags
patch to regenerate proxy auth token with url parsed hostname changes none

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 (Red Hat) 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 (Red Hat) 2012-11-01 16:18:13 UTC
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18