Forbidden error when using Insert Link to text that has a question mark

[gRegorLove]

Short description of the issue

Using the "Insert Link" tool when the selected text has a question mark in it makes the popover show "Forbidden. You don't have permission to access this resource."

Expected behavior

The Insert Link popover should display with the selected text in the Link Text field

Actual behavior

Popover shows "Forbidden. You don't have permission to access this resource."

Steps to reproduce the issue

1. Edit a page with a textarea field that has the visual editor (CKEditor)
2. Enter text: lorem?
3. Highlight that text, including the question mark
4. Click the Insert Link button
5. The popover opens, but in the content section, it has "Forbidden. You don't have permission to access this resource."

Additional information

If it helps, this is the path of the XHR which I copied from Dev Tools > Console. I've replaced the anchors with placeholders because I don't think they're relevant. This XHR request returned 403 Forbidden.

/page/link/?id=17014&modal=1&anchors[]=placeholder1&anchors[]=placeholder2&anchors[]=placeholder3&anchors[]=placeholder4&anchors[]=placeholder5&text=lorem%3F

Our current workaround is to use some arbitrary text without question marks, select that, then in the Insert Link popover, correct the Link Text field. No issue when inserting the link that way.

The process works normally if the selected text doesn't have a question mark.

Setup/Environment

• ProcessWire version: 3.0.229
• PHP version: 8.2.20

[Toutouwai]

Duplicate of https://github.com/processwire/processwire-issues/issues/1952

[ryancramerdesign]

@gRegorLove It's an issue in 2 versions of Apache, but I understand it is fixed in more recent versions of Apache.

[adrianbj]

Unfortunately the fix is still not available - it was committed in July: https://github.com/apache/httpd/commit/a1a93beb58b81f1de2b713ae5f96c41ed5952a74 but hasn't been included in a release yet. I guess we are waiting on 2.4.63 but who knows when that will be released, let alone when package managers will pick it up.

The UnsafeAllow3F might be the best option to fix this for a while, or to make that change to PW's htaccess to the final rewrite.

[ryancramerdesign]

@adrianbj Ah okay I didn't realize that. I've pushed an update to modal.js related to this. Not positive it will fix it, as I don't have the Apache version to test with, but I see I've had that update pending in modal.js so went ahead and committed it.

[gRegorLove]

Thanks! I'll try applying that modal.js patch and report back.

[adrianbj]

That fix works for me - thanks.

[gRegorLove]

Worked for me as well, thanks!

[gRegorLove]

FYI, an edge case this fix still breaks on:

I ran into someone that had a link in the format <a href="[url]" title="[url]">. Since the URL had a question mark in it, the XHR request ended up being like:

/page/link/?id=3239&modal=1&href=https%3A%2F%2Fexample.com%2Fpath?foo=bar&title=https%3A%2F%2Fexample.com%2Fpath?foo=bar&rel=noopener%20noreferrer&text=link%20text

It's pretty rare and for now I've directed them to fix it in source HTML view by removing the title attribute. I think it's bad copypasta from a newsletter service and it's a poor use of title anyway, so good to remove it.

Haven't experimented with a fix, but if someone wants to, I think it would need to break out the query parameters and only apply the %3F fix to the href parameter, not the others.