Filtering route parameters - ruby-on-rails

Question

So I have a route in routes.rb like:
get "example/:token" => "example#example"
and even though I have config.filter_parameters += [:token] in production.rb, I still get a log output like:
Started GET "/example/fjiaowevnieninr3"
Parameters: {"token"=>"[FILTERED]"}
where as you can see "token" is filtered in the Parameters, but still appears in the URL path. I'd always assumed filtered_parameters would filter it there as well but I guess not. Is there an official way to filter out named route parameters like this from the logs?

Answer 1

In general it depends on why do you need this kind of behaviour. allenbrkn answer is correct you can send it through query string and it will be filtered from the query string. That said there are more things to consider when you are trying to do this.
There are more type of logs
In the production environment you use some webserver like Apache or Nginx, they have their own access logs, in which they log some headers, paths with query strings and so on (it is configurable).
It means that even if you filter out URL token from the rails log, they will probably appear in the webserver access logs.
Also don't forget these parameters can be sent to external services eg. exception tracking or performance tracking softwares.
Things in the URL are public
Tokens in the URL should not be considered as a secret. Your user can see them manipulate them, send the url to anyone or randomly show it to someone.
I think there two main reasons to put the token into the URL
Hard to guess URL
User authorisation
Hard to guess URL
In this case token is always the same. It is not changed with every access of the URL. It can be usually used as an ID of some resource or something.
For example we are using it as public URLs for invoices so we can send just a link to our clients and they can download the PDF from our site and there are some things to help them with the payments. In the URL is some token so they cannot guess the URL and access invoices of other clients. The token is always the same, so they can access the invoice from the email several times. And the URL is still in the rails log and server access log and we are fine with it because we know the tokens anyway - they are part of the invoice ID.
In these cases it also helps you with the debugging. If some exception kicks in or if there is some issue with the resource it will be really hard to find out why.
User authorisation
This is a bit more complicated. When it comes to authorisation you shouldn't put your tokens into the URL. They should always be in the body and filtered out of the log or in the authorisation headers. Unfortunately sometimes you don't have much of a choice if you need to use it during the GET requests eg:
Single sign on (redirect flow)
Password reset
etc
(Of course you can use request body even with GET requests but you are risking to loose the data eg if the user puts in the URL manually etc)
In these cases you should make possible exposition to valid tokens as short as you can:
Always issue new token on demand never reuse same tokens
Work with very short expiration times
Every token should be invalidated immediately after its use
With these rules it should not matter whether they appear in the logs or not.
For example we have single sign on implemented in our application. The valid token is issued only on demand with 1 minute expiration time and it is invalidated immediately when it is used. In this case it can appear in the log because at the time of appearance it is already invalid and useless.
With password reset it can be a bit more complicated you need token to be valid at least tens of minutes probably and it will appear in the log before it is invalidated. But there are probably not too many things you can do about it - btw if someone has some good ideas I will be very happy to read it.
Conclusion
You can filter the tokens from rails logs but they still probably appear in other logs or even other services if you use them. You should work with your tokens in the URL as if they can appear there and make it as safe as possible for you if they do. Rails log is just one piece of puzzle you have to consider.

Answer 2

As far I know, there is no in-built way of filtering the URL like GET /example/[FILTERED]. But you can create your own method to do that.
After a little examining of https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/http/filter_parameters.rb file, I found that filtering params will also filter the query_string of the path.
For example: In your case above, if you make a request to /example/fjiaowevnieninr3?token=fjiaowevnieninr3, the result in logs would be:
Started GET "/example/fjiaowevnieninr3?token=[FILTERED]"
Parameters: {"token"=>"[FILTERED]"}
So I would suggest you to send your token as a query parameter and do something like this:
In your routes add:
get "example/auth" => "example#example"
Then you can make a request like /example/auth?token=123456
You can catch this token in controller with params[:token]
This way your logs will show:
Started GET "/example/auth?token=[FILTERED]"
Parameters: {"token"=>"[FILTERED]"}
Also, config.filter_parameters is moved from config/application.rb to it's own file at config/initializers/filter_parameter_logging.rb file.
Add the token symbol to your config/initializers/filter_parameter_logging.rb:
Rails.application.config.filter_parameters += [:password, :token]
Also, don't forget to restart the server.