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:
Created attachment 1127541 [details] Screenshot with issue for UI side
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"
Priority field has completely the same behavior, so should be fixed in scope of that defect
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.
Thanks Lukas for your inputs, that will help me to have better BZ descriptions in future.
Moving to POST since upstream bug http://projects.theforeman.org/issues/13737 has been closed ------------- Anonymous Applied in changeset commit:foreman_discovery|43d7643bf0855da8095dc34d2ef726e8cad5f373.
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
Created attachment 1144155 [details] setting long host_limit in discovery rule raises error: Oops, we're sorry but something went wrong
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.
Moving 6.2 bugs out to sat-backlog.
This should be in the 6.3 version of discovery. Moving it to ON_QA for verification.
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
Created attachment 1239833 [details] Screenshot with resolved issue
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/RHSA-2018:0336