Bug 1308831 - Creating discovery rule with too long value does not work
Creating discovery rule with too long value does not work
Status: VERIFIED
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Discovery Plugin (Show other bugs)
6.1.6
x86_64 Linux
unspecified Severity low (vote)
: Beta
: --
Assigned To: Lukas Zapletal
Sachin Ghai
http://projects.theforeman.org/issues...
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-16 04:02 EST by Oleksandr Shtaier
Modified: 2017-02-16 02:46 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot with issue for UI side (23.45 KB, image/png)
2016-02-16 04:05 EST, Oleksandr Shtaier
no flags Details
setting long host_limit in discovery rule raises error: Oops, we're sorry but something went wrong (28.62 KB, image/png)
2016-04-06 06:29 EDT, Sachin Ghai
no flags Details
Screenshot with resolved issue (35.36 KB, image/png)
2017-01-12 04:46 EST, Oleksandr Shtaier
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 13737 None None None 2016-04-22 12:49 EDT

  None (edit)
Description Oleksandr Shtaier 2016-02-16 04:02:15 EST
Description of problem:
Attempt to create discovery rule entity with too long number (e.g. '456456456546546546546546546546546456456456') for hosts limit field. Get next output in WebUI:
---
PGError: ERROR: value "456456456546546546546546546546546456456456" is out of range for type integer : INSERT INTO "discovery_rules" ("created_at", "enabled", "hostgroup_id", "hostname", "max_count", "name", "priority", "search", "updated_at") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9) RETURNING "id"
---
And using hammer
---
hammer -u my_user -p my_pass discovery_rule create --name 'test' --search 'cpu_count = 1' --hostgroup-id 2 --hosts-limit 456456456546546546546546546546546456456456
Could not create the rule:
  PGError: ERROR:  value "456456456546546546546546546546546456456456" is out of range for type integer
  : INSERT INTO "discovery_rules" ("created_at", "enabled", "hostgroup_id", "hostname", "max_count", "name", "priority", "search", "updated_at") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9) RETURNING "id"
---


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

How reproducible:
Always

Steps to Reproduce:
1. Create discovery rule with too long hosts limit value

Actual results:
Get an exception which expose some information about internal product structure

Expected results:
Usual field validation used across entire application

Additional info:
Comment 2 Oleksandr Shtaier 2016-02-16 04:05 EST
Created attachment 1127541 [details]
Screenshot with issue for UI side
Comment 3 Oleksandr Shtaier 2016-02-16 04:11:55 EST
Logs contain same information:
2016-02-16 04:06:43 [W] Operation FAILED: PGError: ERROR:  value "345345345435435435435435345345345345" is out of range for type integer
: INSERT INTO "discovery_rules" ("created_at", "enabled", "hostgroup_id", "hostname", "max_count", "name", "priority", "search", "updated_at") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9) RETURNING "id"
Comment 4 Oleksandr Shtaier 2016-02-16 04:36:47 EST
Priority field has completely the same behavior, so should be fixed in scope of that defect
Comment 5 Lukas Zapletal 2016-02-16 11:12:28 EST
Hello Oleksandr,

our DB structure is public, anybody can read it from our git. This is not a security issue.

I confirm this bug, thanks for your report. This is low severity tho.
Comment 6 Oleksandr Shtaier 2016-02-17 03:39:17 EST
Thanks Lukas for your inputs, that will help me to have better BZ descriptions in future.
Comment 8 Bryan Kearney 2016-02-18 06:10:00 EST
Moving to POST since upstream bug http://projects.theforeman.org/issues/13737 has been closed
-------------
Anonymous
Applied in changeset commit:foreman_discovery|43d7643bf0855da8095dc34d2ef726e8cad5f373.
Comment 11 Sachin Ghai 2016-04-06 06:27:15 EDT
Verified sat6.2 beta snap6

I created a discovery rule with long value of 'Hosts limit" and "priority" and UI raises error:

Oops, we're sorry but something went wrong ERROR: value "456456445645645654654654656546546546" is out of range for type integer 


Ideally, an error should raise on same page after submitting the rule.



Also, in hammer, proper error should thrown:

~]# hammer -u admin -p changeme discovery_rule create --name 'test' --search 'cpu_count = 1' --hostgroup-id 1 --hosts-limit 456456456546546546
Could not create the rule:
  Error: 422 Unprocessable Entity
Comment 12 Sachin Ghai 2016-04-06 06:29 EDT
Created attachment 1144155 [details]
setting long host_limit in discovery rule raises error: Oops, we're sorry but something went wrong
Comment 13 Lukas Zapletal 2016-04-06 08:11:52 EDT
Again, I was expecting foreman_discovery to be rebased, but unfortunately it was not and this bug did not make it into 6.2. It was fixed upstream only:

https://github.com/theforeman/foreman_discovery/commit/43d7643bf0855da8095dc34d2ef726e8cad5f373

Reassigning to 6.3.
Comment 16 Bryan Kearney 2016-08-04 16:10:29 EDT
Moving 6.2 bugs out to sat-backlog.
Comment 17 Bryan Kearney 2017-01-05 11:00:52 EST
This should be in the 6.3 version of discovery. Moving it to ON_QA for verification.
Comment 18 Oleksandr Shtaier 2017-01-12 04:45:50 EST
Verified for latest snap of 6.3

CLI:
hammer -u admin -p changeme discovery_rule create --name 'test' --search 'cpu_count = 1' --hostgroup-id 2 --hosts-limit 456456456546546546546546546546546456456456
Could not create the rule:
  Organizations Host group organization OifHjKRTX must also be associated to the discovery rule
  Max count must be less than 2147483648

UI:
Also fixed
Going to attach a screenshot
Comment 19 Oleksandr Shtaier 2017-01-12 04:46 EST
Created attachment 1239833 [details]
Screenshot with resolved issue

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