Bug 616175

Summary: When using port forwarding over SSH, some buttons don't respect the port listed in the URL
Product: [Community] Spacewalk Reporter: Ian Forde <ianforde>
Component: WebUIAssignee: Jan Pazdziora <jpazdziora>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: low    
Version: 1.0CC: jpazdziora, slukasik
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: spacewalk-web-1.6.19-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-22 16:48:47 UTC Type: ---
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: 723481    

Description Ian Forde 2010-07-19 19:25:46 UTC
Description of problem:
I have a Spacewalk server located on the other side of a firewall, so I use ssh port-forwarding to access it.  While most things work, I've found 3 buttons that don't respect the new port and just go to https://localhost/whatever rather than https://localhost:<forwardedport>/whatever.  They are:

  1. When deleting a system's registered profile and performing the confirmation, the 2nd confirmation click.
  2. On the System Groups page, clicking on "Use in SSM".
  3. When confirming a scheduled remote command from within SSM.

Version-Release number of selected component (if applicable):
Spacewalk 1.0

How reproducible:
Every time

Steps to Reproduce:
1. (from shell): ssh -L 10443:spacewalk-server:443 user@spacewalk-server
2. (from browser): Go to https://localhost:10443 and login to Spacewalk
3. Go to the System Groups Page and click on "Use SSM"
  
Actual results:
Page (and/or port) not found error in browser

Expected results:
SSM Overview page comes up.


Additional info:
Not much really - it's pretty easy to demo.  As stated above, I've found at least 3 instances of it so far.  Would be fair for any additional instances of this to be attached to this ticket (rather than creating additional tickets)?

Thanks!

Comment 1 Jan Pazdziora 2010-10-27 08:32:41 UTC
Mass-aligning under space12, so that we don't lose track of this bugzilla. This however does not mean that we plan (will be able to) address this bug in Spacewalk 1.2.

Comment 2 Jan Pazdziora 2010-11-19 16:04:19 UTC
Mass-moving to space13.

Comment 3 Miroslav Suchý 2011-04-11 07:32:54 UTC
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 4 Miroslav Suchý 2011-04-11 07:36:58 UTC
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 5 Jan Pazdziora 2011-07-20 11:51:02 UTC
Aligning under space16.

Comment 6 Jan Pazdziora 2011-09-09 15:11:48 UTC
I believe all three cases are the PXT traps -- 302 HTTP redirects that did not put the port in correctly.

Fixed in Spacewalk master, b841b20725abe312655f0a6799ffa4662eedc56f.

Comment 7 Milan Zázrivec 2011-12-22 16:48:47 UTC
Spacewalk 1.6 has been released.