It should be looking at the passed in primary_collection_name
Current logic to validate ID will fail when sub collection objects have different ID patterns, it works only when all objects have the same regex pattern.
For example: if a task object's ID has uuid pattern, the API call /sources/:id/tasks may fail with error: ID is invalid.
This PR replaces the cached regular expression with a hash, keyed of the primary_collection_name
The first call will go thru the task controller and cache the regexp pattern for task which is the GUID format.
The second call is to get the sub collection of tasks under the primary collection (source), the second call is also handled by task controller. So now when it tries to validate the ID of the source it uses the previously cached GUID regex and it fails.
dippy-bot
commented
3 years ago
This line caches the incorrect regex pattern
https://github.com/RedHatInsights/insights-api-common-rails/blob/b53ab53fab0c965886fba1bc46e3757b52dcdaf2/lib/insights/api/common/application_controller_mixins/request_path.rb#L47
It should be looking at the passed in primary_collection_name
Current logic to validate ID will fail when sub collection objects have different ID patterns, it works only when all objects have the same regex pattern.
For example: if a task object's ID has uuid pattern, the API call
/sources/:id/tasksmay fail with error:ID is invalid.This PR replaces the cached regular expression with a hash, keyed of the primary_collection_name
If the user makes 2 API calls
"/api/v2.0/task/1234-5678-8899-90000...." "/api/v2.0/sources/2334/tasks"
The first call will go thru the task controller and cache the regexp pattern for task which is the GUID format. The second call is to get the sub collection of tasks under the primary collection (source), the second call is also handled by task controller. So now when it tries to validate the ID of the source it uses the previously cached GUID regex and it fails.