[Lock] MongoDbStore::skimUri may strip repeated query string keys #37864
Labels
Comments
kralos
pushed a commit
to kralos/symfony
that referenced
this issue
Aug 18, 2020
kralos
pushed a commit
to kralos/symfony
that referenced
this issue
Aug 18, 2020
kralos
pushed a commit
to kralos/symfony
that referenced
this issue
Aug 18, 2020
kralos
pushed a commit
to kralos/symfony
that referenced
this issue
Aug 18, 2020
kralos
pushed a commit
to kralos/symfony
that referenced
this issue
Aug 19, 2020
fabpot
added a commit
that referenced
this issue
Aug 19, 2020
…ongodb uri when stripping (kralos) This PR was squashed before being merged into the 5.1 branch. Discussion ---------- [Lock] MongoDbStore handle duplicate querystring keys in mongodb uri when stripping | Q | A | ------------- | --- | Branch? | 5.1 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #37864 | License | MIT | Doc PR | Allow duplicate querystring keys when stripping `collection`. `readPreferenceTags` is currently allowed to be specified twice so re-assembling the querystring with `http_build_query` will also strip duplicated `readPreferenceTags`. Use `preg_match` instead. Commits ------- c1ea9ae [Lock] MongoDbStore handle duplicate querystring keys in mongodb uri when stripping
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Symfony version(s) affected: 5.2-dev
Description
As mentioned in https://github.com/symfony/symfony/pull/37218/files#r471609509, the current implementation of
MongoDbStore::skimUri()may silently corrupt a MongoDB connection string by stripping repeatedreadPreferenceTagskeys in a query string (permitted use case, as mentioned in the URI options spec).How to reproduce
An example connection string is:
After
MongoDbStore::skimUri()processes this string, only a singlereadPreferenceTagsoption would remain.Possible Solution
I think it would be preferable to capture the URI option with a regular expression and then, if anything was found, strip it from the returned string. While collection names have their own restrictions, for purposes of URI parsing I think it'd be suitable to use a pattern like
/collection=([^&]*)/i(case-insensitive and only stopping at the end of a string or a&character that might precede the next key).Additional context
Related to #37180 and corresponding PR (#37218).
The text was updated successfully, but these errors were encountered: