Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1408555 - When viewing hosts managed by capsule, hyperlink takes you to "all hosts" instead of filtered view of hosts managed
Summary: When viewing hosts managed by capsule, hyperlink takes you to "all hosts" ins...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Hosts
Version: 6.2.6
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: Unspecified
Assignee: Ondřej Pražák
QA Contact: Renzo Nuccitelli
URL: http://projects.theforeman.org/issues...
Whiteboard: G
: 1329541 1459119 1459299 1481953 (view as bug list)
Depends On:
Blocks: 1426406
TreeView+ depends on / blocked
 
Reported: 2016-12-24 20:45 UTC by Kathryn Dixon
Modified: 2021-09-09 12:03 UTC (History)
20 users (show)

Fixed In Version: rubygem-bastion-3.2.0.13-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1426406 (view as bug list)
Environment:
Last Closed: 2017-09-18 15:23:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Error when clicking overview filter (59.81 KB, image/jpeg)
2017-04-04 17:31 UTC, Renzo Nuccitelli 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 17291 0 None None None 2020-07-01 08:43:02 UTC
Red Hat Knowledge Base (Solution) 3439551 0 None None None 2018-05-10 08:53:42 UTC
Red Hat Product Errata RHBA-2017:1191 0 normal SHIPPED_LIVE Satellite 6.2.9 Async Bug Release 2017-05-01 17:49:42 UTC

Description Kathryn Dixon 2016-12-24 20:45:51 UTC 
Description of problem:

After clicking infrastructure > capsules and choosing the internal or any external capsule under "overview" and "puppet ca" you can see the number of hosts that are "managed" by the specific capsule.

However after clicking the hosts managed hyperlink this takes you to "all hosts" and they are not filtered.


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


How reproducible: 100%


Steps to Reproduce:
1. Register a client to capsule ( or satellite)
2. go to infrastructure > capsule
3. Choose the capsule or satellite you registered the client to
4. Then under puppet ca or overview page you will see hosts managed and correct number of systems.
5. Click hyperlink to view managed hosts

Actual results: this will take you to "all hosts" with no filter from what you'd expect to see from the previous page.


Expected results: to only be able to see the managed hosts 


Additional info:
Comment 6 Daniel Lobato Garcia 2017-01-03 14:52:22 UTC 
This was fixed in Bastion by https://github.com/Katello/bastion/pull/139 - will link the issues.
Comment 7 Daniel Lobato Garcia 2017-01-03 14:53:17 UTC 
Connecting redmine issue http://projects.theforeman.org/issues/17291 from this bug
Comment 8 Daniel Lobato Garcia 2017-01-27 08:44:20 UTC 
Setting as triaged as there's a fix already upstream
Comment 9 Satellite Program 2017-02-23 21:10:44 UTC 
Please add verifications steps for this bug to help QE verify
Comment 10 Ondřej Pražák 2017-03-07 13:48:59 UTC 
Steps to verify:

1) register host(s) to a capsule
2) go to capsules/show page for that capsule
3) in the "Overview" tab, notice there is a correct number of "Hosts managed"
4) click the link, it should lead to a search on a hosts/index page showing the list of hosts registered to the capsule
Comment 13 Renzo Nuccitelli 2017-04-04 17:31:29 UTC 
Created attachment 1268725 [details]
Error when clicking overview filter

When I clicked on "Hosts Managed" on "Overview" page I got an error "Error: Field 'smart_proxy+' not recognized for searching!". I attached "filter_error.jpg" screen shot with it.

The page had the filter 'smart_proxy+=+"some_fqdn"'. When I changed it to 'smart_proxy="some_fqdn"' it worked as expected. So it seems a matter of removing plus signs from the filter (+)
Comment 14 Satellite Program 2017-04-04 18:12:26 UTC 
Upstream bug assigned to oprazak
Comment 15 Tomer Brisker 2017-04-05 08:50:34 UTC 
Walden, this sound very familiar to some other issue you fixed IIRC, does this ring any bells?
Comment 16 Walden Raines 2017-04-05 13:53:06 UTC 
(In reply to Tomer Brisker from comment #15)
> Walden, this sound very familiar to some other issue you fixed IIRC, does
> this ring any bells?

This is on foreman host pages right?  The katello JS that caused a similar (and since fixed) bug wouldn't even be loaded on these pages.  I vaguely remember the bug you are referring to but I couldn't find it readily.

From Renzo's comment#13 it looks like these +s are being correctly encoded to %2B in the link.
Comment 17 Walden Raines 2017-04-05 13:58:48 UTC 
(In reply to Walden Raines from comment #16)
> (In reply to Tomer Brisker from comment #15)
> > Walden, this sound very familiar to some other issue you fixed IIRC, does
> > this ring any bells?
> 
> This is on foreman host pages right?  The katello JS that caused a similar
> (and since fixed) bug wouldn't even be loaded on these pages.  I vaguely
> remember the bug you are referring to but I couldn't find it readily.
> 
> From Renzo's comment#13 it looks like these +s are being correctly encoded
> to %2B in the link.

Found it!

https://github.com/Katello/bastion/pull/105
Comment 18 Tomer Brisker 2017-04-05 14:23:49 UTC 
This is on the smart proxy page, so bastion is loaded there. 
It looks like the "+" signs are escaped in this case when they shouldn't be - they are part of the url used to concat the %3d of the equal sign. Might be that Ondrej's patch to bypass the angular routing also caused it to bypass your fix?
Comment 19 Walden Raines 2017-04-05 14:40:56 UTC 
(In reply to Tomer Brisker from comment #18)
> This is on the smart proxy page, so bastion is loaded there. 
> It looks like the "+" signs are escaped in this case when they shouldn't be
> - they are part of the url used to concat the %3d of the equal sign. Might
> be that Ondrej's patch to bypass the angular routing also caused it to
> bypass your fix?

To concat the %3d?  What do you mean?  Why not just decode the url server side? Both %2B and + should behave the same in my opinion (although I don't really even understand why the + is needed in the first place).

My fix was more of a hack to workaround this issue with foreman.  Ideally all special characters should be encoded (I think the RFC even specifies this) but the server should be able to accept both.
Comment 20 Walden Raines 2017-04-05 14:42:09 UTC 
(In reply to Tomer Brisker from comment #18)
> Might be that Ondrej's patch to bypass the angular routing also caused it to
> bypass your fix?

To answer your question, yes, that is what is happening.  Ondrej's change bypasses my hack.
Comment 21 Tomer Brisker 2017-04-05 15:05:35 UTC 
I mean that we encode the url twice - once gets us the +%3d+ part (encoding the "=" sign) and the second time tries to encode the "+"s which causes the url to break.
Comment 22 Bryan Kearney 2017-04-06 12:57:04 UTC 
Tomer/Walden.. next steps here?
Comment 23 Walden Raines 2017-04-06 13:34:08 UTC 
Oh I see.  But +%3d+ isn't correct encoding for = by itself unless there are spaces (i.e. " = ").  What is the original URL, are there spaces?  The correct url encoding for "=" is "%3d".

As far as next steps, if there are no spaces in the URL then we should fix our encoding if there are spaces then I guess we'll have to add this hack to the capsule URL as well.
Comment 24 Tomer Brisker 2017-04-06 13:45:23 UTC 
The correct URL may contain spaces - even if we strip them from around the "=" sign they are still possible inside the proxy name. 
It looks like Ondrej's patch seems to make angular only ignore links inside the page itself (i.e. those that match 'smart_proxies') so there may be other broken links as well in there (I noticed the link in puppet environments also exhibits the same behaviour). 
So looks like we need your patch applied on that page as well.

bkearney - I'm not sure if this constitutes a blocker for 6.2.9, I'd be happy to get it fixed but I don't think I'd hold the release for it.
Comment 25 Walden Raines 2017-04-06 14:16:58 UTC 
My point is that "+%3d+" decodes to " = " and I'm not sure that's what we want.  In fact, I'm not even sure that is a valid query string.  

If you go to your browser and type in 'http://google.com/search?q = blah' look what happens as opposed to 'http://google.com/search?q=blah' (notice that the +s also don't work).  I believe that +s are only valid in query string keys or names (i.e. 'http://someUrl.com?key+name=value+with+space' would result in 'http://someUrl.com?key name=value with space').

Using +s are only valid in application/x-www-form-urlencoded strings such as query string keys and values.  We should not be using spaces or +s around the equals sign.  

How difficult would it be to remove the spaces/+s from around the =s signs?
Comment 26 Tomer Brisker 2017-04-06 14:33:37 UTC 
it's a valid query, note that the "=" is part of the search, not another request parameter - the url is /host?query=smart_proxy+%3d+proxyname so that the = as well as any other special signs (such as spaces) need to be url-encoded correctly. As I said in comment #24, the proxy name can also include spaces, so even if we get rid of these two we will just be moving the problem to somewhere else, so we need to handle spaces correctly and not double-encode them. TBH I'm not sure why angular tries to re-encode urls at all, but I guess that's beyond the scope of this issue.
Comment 27 Walden Raines 2017-04-06 14:50:46 UTC 
(In reply to Tomer Brisker from comment #26)
> it's a valid query, note that the "=" is part of the search, not another
> request parameter - the url is /host?query=smart_proxy+%3d+proxyname so that
> the = as well as any other special signs (such as spaces) need to be
> url-encoded correctly. As I said in comment #24, the proxy name can also
> include spaces, so even if we get rid of these two we will just be moving
> the problem to somewhere else, so we need to handle spaces correctly and not
> double-encode them. TBH I'm not sure why angular tries to re-encode urls at
> all, but I guess that's beyond the scope of this issue.

Oh I see, sorry about the confusion, I thought smart_proxy was the query key.

Then yes, this seems like a bug with how angular is (re)encoding the URL.  I would be happy to take a look at this for 6.3.  I agree with Tomer that this shouldn't be a blocker for 6.2.9
Comment 28 Bryan Kearney 2017-04-10 14:02:34 UTC 
Per comment 27, I am moving htis out of 6.2.9.
Comment 30 errata-xmlrpc 2017-05-01 13:57:34 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1191
Comment 31 Tomer Brisker 2017-06-06 11:11:03 UTC 
Looks like this was mistakenly marked as closed in 6.2.9, it has not been fixed yet. Reopening.
Comment 32 Tomer Brisker 2017-06-06 11:13:46 UTC 
*** Bug 1459119 has been marked as a duplicate of this bug. ***
Comment 33 Tomer Brisker 2017-07-02 14:22:16 UTC 
*** Bug 1459299 has been marked as a duplicate of this bug. ***
Comment 34 Ondřej Pražák 2017-07-11 14:19:40 UTC 
I do not know what changes were made, but this seems to be fixed in 6.3. Could QE verify?
Comment 35 Kathryn Dixon 2017-07-12 01:32:11 UTC 
*** Bug 1329541 has been marked as a duplicate of this bug. ***
Comment 36 Walden Raines 2017-09-13 16:30:17 UTC 
*** Bug 1481953 has been marked as a duplicate of this bug. ***
Comment 37 Bryan Kearney 2017-09-13 20:43:19 UTC 
ON_QA status is for 6.3, but there exists a bug for 6.3. Moving this to NEW for 6.2.
Comment 38 Bryan Kearney 2017-09-18 15:23:17 UTC 
This will be fixed in 6.3, and I do not see this being backported into 6.2.z. If you have concerns with this, please feel free to reach out to me.
Note You need to log in before you can comment on or make changes to this bug.