Bug 616175 - When using port forwarding over SSH, some buttons don't respect the port listed in the URL
Summary: When using port forwarding over SSH, some buttons don't respect the port list...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: WebUI
Version: 1.0
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jan Pazdziora (Red Hat)
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space16
TreeView+ depends on / blocked
 
Reported: 2010-07-19 19:25 UTC by Ian Forde
Modified: 2011-12-22 16:48 UTC (History)
2 users (show)

Fixed In Version: spacewalk-web-1.6.19-1
Clone Of:
Environment:
Last Closed: 2011-12-22 16:48:47 UTC
Embargoed:


Attachments (Terms of Use)

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 (Red Hat) 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 (Red Hat) 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 (Red Hat) 2011-07-20 11:51:02 UTC
Aligning under space16.

Comment 6 Jan Pazdziora (Red Hat) 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.


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