If you save a relative path for a redirect, anonymous users can be confronted with a white screen "The website encountered an unexpected error. Please try again later."
e.g. a redirect can be entered as node/438
but should be specified as the absolute path /node/438
Anonymous users will then be correctly redirected.
This is then consistent with the requirements of specifying all path aliases with a leading slash.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 2922902-internal-page-redirect-validation-10.patch | 1.26 KB | colincalnan |
| #9 | 2922902-internal-page-redirect-validation-9.patch | 1.23 KB | colincalnan |
| #2 | 2922902-internal-page-redirect-validation.patch | 1.74 KB | sandboxpl |
Comments
Comment #2
sandboxplUsers shouldn't be able to provide invalid URLs for internal page redirects,
validation fails in Drupal\Core\Url::fromUserInput() , when provided url doesn't start with "/" , "#" , or "?" character.
This should be fixed in UI, user input should be validated before saving it, I was able to add validation for rh page redirect, initial patch attached
Comment #4
dylan donkersgoed commentedThis patch looks complete and seems to work well, so I infer you just forgot to move this to "Needs Review". I've merged this in, thanks.
Comment #5
dylan donkersgoed commentedComment #7
anacolautti commentedI have an issue with this. I'm trying to redirect the anonymous users to a file uploaded in the content using tokens. The tokens available are [node:field_file:entity:path] which starts with public/... and [node:field_file:entity:url] which is an absolute URL (and my choice).
If I try to use [node:field_file:entity:path] the validation doesn't let me save even though the token represents a full URL. It forces me to add a '/' and messes the URL up.
Comment #8
matt.mendonca commentedWe've also run into the same issue as #7, albeit with redirecting anonymous users to the file URL for media files. In order to get around it, I exported the config with the leading slash (so that the form would save), removed the slash in the config yaml, then reimported config (kind of hacky). Doing this stops the You are not allowed to specify an external URL together with internal:/ exception from being thrown. The downside, however, is this breaks the form.
Comment #9
colincalnan commentedI also ran into the issue with #7, I'd like to work to come up with a more robust patch that validates the token but for now this small patch does a quick string check for the presence of the `:entity:url]` string in the token and skips the validation if that's the case.
There needs to be a case to the `:entity:path]` scenario which would then translate that scheme `public://` etc. into a valid URL.
Comment #10
colincalnan commentedTurns out I had the same issue for Link fields, the `:uri]` token will not work with this patch, so I've added that also.
Again, this seems like it could do wit a bit of a re-think.