-
Notifications
You must be signed in to change notification settings - Fork 13
Open
Description
Let's look at where url/api prefix is eventually used \Enm\JsonApi\Model\Request\Request::parseUriPath:
preg_match(
'/^(([a-zA-Z0-9\_\-\.\/]+.php)(\/)|)(' . $this->apiPrefix . ')([\/a-zA-Z0-9\_\-\.]+)$/',
trim($path, '/'),
$matches
);So the prefix is used in a regex using / as open/close characters. This basically means the prefix cannot contain that character (unless escaped).
Why does the default/test implementation work? Because the prefix is trimmed and the example doesn't try subpaths.
What's the problem with this?
- the
/character is very common in paths, unlike other regex special characters - documentation here doesn't say that this string is part of a regex - it also gives the impression that I have to write
{type}somewhere in the string when in fact, it doesn't seem to be the case - the example here works by coincidence - it should have been
'\\/api'instead
What are the solutions?
- change the regex open/close to something less disruptive (eg:
#theregex#)- pro: ideal case
- con: backward compatibility break
- escape prefix before injecting it into the regex (eg:
preg_match('/...' . preg_quote(...) . '.../'...)- pro: no need to care that the prefix will be part of a regex
- con: backward compatibility break, prefix will become plain text match and cannot be part of regex (eg:
api(-v\d+)will now not work)
- update documentation appropriately (warn about escaping
/and maybe example code for subpaths)- pro: backward compatible
- con: code will still be ambiguous, not ideal case (from code perspective) - this is less of a problem if the parameter is renamed appropriately (eg:
url_prefix=>url_prefix_regex)
See original issue: eosnewmedia/JSON-API-Server#9
javi-p-nt
Metadata
Metadata
Assignees
Labels
No labels