-
Notifications
You must be signed in to change notification settings - Fork 118
Generalized the find_build service's parameters #254
base: master
Are you sure you want to change the base?
Conversation
we should probably whitelist params which are accepted, as this could become a DDOS vector by creating slow queries, and also potentially a security attack vector. |
I think just |
@henrikhodne @joshk: Does this look good? |
@@ -30,7 +32,7 @@ def all_resources | |||
end | |||
|
|||
def result | |||
@result ||= scope(:build).find_by_id(params[:id]) | |||
@result ||= scope(:build).where(params.select { |k| ALLOWED_PARAMS.include? k.to_sym } ).first |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd use params.slice(ALLOWED_PARAMS)
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That might have to be params.slice(*ALLOWED_PARAMS)
, now that I think about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 to slice
On 13/09/2013, at 12:03 AM, Henrik Hodne [email protected] wrote:
In lib/travis/services/find_build.rb:
@@ -30,7 +32,7 @@ def all_resources
enddef result
@result ||= scope(:build).find_by_id(params[:id])
That might have to be params.slice(*ALLOWED_PARAMS), now that I think about it.@result ||= scope(:build).where(params.select { |k| ALLOWED_PARAMS.include? k.to_sym } ).first
—
Reply to this email directly or view it on GitHub.
@henrikhodne @joshk: Okay, fixed |
@@ -3,6 +3,8 @@ module Services | |||
class FindBuild < Base | |||
register :find_build | |||
|
|||
ALLOWED_PARAMS = [:id, :request_id, :repository_id, :owner_id, :commit_id, :pull_request_number] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are all those params currently used for the where
search? Does it make sense to allow all these? Especially as the previous implementation was find_by_id
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshk: I need to add at least owner_id
and pull_request_number
for my other PR to cancel builds when a PR is closed. I don't think the others are necessary right now, so we could remove them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you point me to the related PRs again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see owner_id
being used here, and although pull_request_number
is needed, it feels like the interaction can be encapsulated a little better. I need to think about this a little. Will look at it more this week.
@joshk: Ping |
1 similar comment
@joshk: Ping |
No description provided.