Params part of the routable URL are not escaped, specifically a slash

[maletor]

In reference to #14070, a slash found in the params of a route such as

get 'foo/:token where :token contains a "/" would return a 404 because :token does not get URL escaped.

:token should probably be escaped just as it would a regular param (after the ?).

[heironimus]

@maletor, your comment below from the linked issue seems to describe the issue a little better.

When the param is expected as part of the URL, like this

get 'foo/:param' => 'foo#bar', as: :foo

link_to foo_url(param: 'slash/slash', other_param: 'slash/slash')

The param param is not escaped while the other_param param is escaped.

[pixeltrix]

Fixed by 5460591

[GSI]

This concept causes "unexpected"/"inconsistent" behaviour when to_param is overwritten.

def to_param
  "foo/#{bar}"
end

test "to_param: forward slashes are unencoded" do
   m = FactoryGirl.create(:the_model)    
   assert_equal m.to_param, "foo/#{m.bar}"
end

This test obviously succeeds. On the other hand the _path and _url helpers will generate "foo%2F#{m.bar}".

Unless there's an even better way to handle this use case, I'd consider helper results should equal the strings as generated by (an overwritten) to_param.

[pixeltrix]

@GSI the job of to_param is to convert an object to a representation suitable for use in a path or query string, not to escape it - that's the job of the url generation code because there are different escaping semantics depending on where in the url that param goes.

If there's a need to use / in your path then the solution is to use a glob path segment (i.e. /*path) which tells the router not to escape them - is there a reason this doesn't/can't work for you?

[GSI]

@pixeltrix I've re-checked the docs, but I'm still unsure if I understand your suggestion correctly.

For example, I use get :location/:year/.../:id with contraints on :year - How would someone constrain that if year was missing in the actual route statement? get /*path/:id does neither "know" about year's position in the path nor it's regex constraints.

Also, HTML anchors would point to /123 (the non-globbed part plus the id). Correct? If yes, we'd generate additional, unnecessary requests (GET /123 => some sort of "moved" response => GET /the/actual/path/123), which I avoided by overwriting to_param.

Finally, this breaks assert_redirected_to. That could maybe be fixed in that method itself though, allowing for consistent results across dev and prod.

... or am I missing something?

[pixeltrix]

@GSI I'm not sure what the problem is but you can place constraints on a glob param, e.g:

Rails.application.routes.draw do
  get '/:location/*date/*id', to: 'posts#show', date: %r[\d{4}/\d{2}/\d{2}], as: 'post'
end

>> app.get('/london/2014/09/10/123/foo')
=> 200
>> app.request.params[:date]
=> "2014/09/10"
>> app.request.params[:id]
=> "123/foo"
>> app.post_path('london', '2014/09/10', '123/foo')
=> "/london/2014/09/10/123/foo"

[GSI]

(I was unaware that contraints were possible in the globbing context. Thanks for the hint.)

Regarding URL generation, I'll provide an example:

<%= link_to 'foo', @bar_object %> generates sth like <a href="bars/1">foo</a>.

Now the idea of overwriting to_param is to change the resulting path (href):

def to_param
    "#{location}/#{year}/#{id}"
end

With this, <%= link_to 'foo', @bar_object %> generates sth like <a href="somewhere/2014/1">foo</a>.

Even without that, and I think that is what you mean, bars_path() will generate the correct URL as long as the exact params are given.

So, bars_path({location: :somewhere, year: 2014, id: 1}) would still render as desired, while bars_path(@bar_object) seemingly falls back to the bars/1 variant.

Is there another way of achieving the desired outcome when slashes are technically "denied"?

(Changing all occurances of bars_path(@bar_object) to sth like bars_path(@bar_object.filtered_attributes_for_url) would appear "dirty" to me.
<%= link_to 'foo', @bar_object %> would also fail and thus have to be converted to the longer variant.)

[GSI]

@pixeltrix, I see where our examples differ and what causes the problem. You are using actual database field names in the route (e.g. date).

I am using several things like shortened_id which has no corresponding database field, but is derived dynamically from the id field.

Now that the usage of to_param is no option anymore, is there a solution that somehow allows bar_path() to "know" how to find shortened_id given a certain object (e.g. bar_path(bar_object)).

(Apparently this is not based on the model's attributes.)

[pixeltrix]

@GSI the url helpers don't care about model attributes. The fact that I used date is irrelevant - it could be whatever you wanted it to be. The only thing that matters is :foo vs. *foo - the latter doesn't trigger escaping of slashes. So you can use to_param - just make sure it's a glob param that's being replaced.

[GSI]

Thanks your explanation and patience, @pixeltrix.

I'll try to clarify: Given a bar_object (instance of the Bar model), once I call bar_path(bar_object), model attributes are relevant. Why? Because bar_object is missing an attribute named shortened_id. Thus there will be no param[:shortened_id] be passed to the controller.

Now, your suggestion of course does work if I define a route like this:
get '/*any_and_all_of_the_params_i_need', to: 'bars#show', as: 'bar'

But this leaves me with params[:any_and_all_of_the_params_i_need] containing the full string (e.g. location/year/shortened_id). As you say, it's unescaped, but is it really the intention to have to split the string up manually (location, year, shortened_id = params[:any_and_all_of_the_params_i_need].split('/')) or is there a better solution?