[openstreetmap/openstreetmap-website] Allow `user/preferences/[KEY]` to accept arbitrary keys (PR #3787)

Andy Allan notifications at github.com
Wed Nov 9 21:19:39 UTC 2022


I think the underlying problem here is that we are using the keys in our urls, without any validation to ensure that they are url safe. A similar example would be our validation of user display_names, which are validated as url safe, since we use those in urls.

```diff
   validates :user, :associated => true
-  validates :k, :v, :length => 1..255, :characters => true
+  validates :k, :length => 1..255, :characters => { :url_safe => true }
+  validates :v, :length => 1..255, :characters => true
 end
```
It's a bit surprising that this hasn't come up until now! And it's quite funny to me that the problem is highlighted by the keys that we use internally for gpx visibility and diary default language, both of which use "." characters :smile:

Unfortunately I'm not in favour of the proposed solution. We've been trying to move away from plain-text API responses, mostly for consistency reasons between API endpoints but also for developer ergonomics (you don't want to have some responses handled by an xml or json library, but have to handle some responses that aren't). But we have also settled on the convention that you can choose between response formats using extensions e.g. `GET /api/0.6/node/1.json`. If we merged this PR, we would not be able to do `GET /api/.../user/preferences/key.json` in future.

I'm open to further discussion and any suggestions!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1309387342
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/pull/3787/c1309387342 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20221109/dd1f7c1d/attachment.htm>


More information about the rails-dev mailing list