Spaces are not replaced with underscore (config setting) - forbidden blank page instead

[macin]

The problem

I have a config enabled to convert spaces to underscores. However after upgrade to Kaos 6a I started getting feedback from the users, that they are not able to create pages.

AFter investigation, is seems that when user types in the namespace name with spaces, dokuwiki redirects to the page with %20 in the url

I was not able to confirm if this is server problem, or dokuwiki itself

Enter page name here

Version of DokuWiki

2024-0206a Kaos

PHP Version

8.2

Webserver and version of webserver

Ubuntu

Browser and version of browser, operating system running browser

Version 122.0.6261.71 (Official Build) (64-bit)

Additional environment information

No response

Relevant logs and/or error messages

No response

[fiwswe]

AFter investigation, is seems that when user types in the namespace name with spaces, dokuwiki redirects to the page with %20 in the url

Where does the user type in the name with spaces? The URL bar of the browser?

If so then the browser most likely replaces the spaces with %20 because space is not a valid character in URLs.

[macin]

Oh, I wasn't very precise... This is before the page is created. There is a button to create a page and after clicking it, the native browser modal I pasted above appears to type in the name. Once I type that in, the url opens with spaces not replaced with underscores as on screenshot.

Now that you asked, maybe this is not a core dokuwiki, but a page create plugin failure? Need to check which plugin this could be...

In the previous version this worked well, i.e. when I typed in the name with spaces, the redirect to new page was already with underscores...

Just tried similar though right click index menu and similar effect.

[fiwswe]

Yes, probably a plugin. DokuWiki does not have any buttons to create pages or modal dialogs to enter (new) page names.

Also, what template are you using? Might also be related?

I have a config enabled to convert spaces to underscores.

Is this the sepchar setting? I have that set to _ as well and never had any issues.

[fiwswe]

Not a DokuWiki issue. See: https://github.com/SoarinFerret/dokuwiki-plugin-pagebuttons/issues/20

[splitbrain]

I actually think there might be a regression here. Needs investigation.

[splitbrain]

Okay, it seems DokuWiki itself is still working as expected. If an ID with spaces is passed as ID, it will be cleaned up correctly: https://www.dokuwiki.org/doku.php?id=playground:page%20with%20spaces

However when the the ID is passed via mod_rewrite, a forbidden error is issued: https://www.dokuwiki.org/playground:page%20with%20spaces

However I don't think it is triggered by DokuWiki but the web server? But I am not sure why... the rewrite should pass the ID on to doku.php, space or no space?

If @macin is correct and this used to work in Jack Jackrum, I have no idea why. Or what the change is that causes the regression. Would be great if someone could confirm that it works on Jack.

[fiwswe]

Ok, I (also?) tried this and to my surprise it worked: https://www.dokuwiki.org/playground:page_with_spaces

The cleanup of the page id happens when saving the page. While initially editing it, it still had the spaces/%20 in the URL.

I can't say what happens in the mod_rewrite case.

Depends on the exact rewrite rules. If the rules from https://www.dokuwiki.org/install:apache are used then the URL would start out as: https://hostname/ns:page%20with%20spaces&do=edit Thus the QSA modifier would not see a query string (which would need to start with ?) and the B modifier would escape the & -> %26 and = -> %3D yielding: https://hostname/doku.php?id=ns:page%20with%20spaces%26do%3Dedit. Would DokuWiki consider this page name forbidden? I tried https://www.dokuwiki.org/playground:page%20with%20spaces%26do%3Dedit and it does indeed return Forbidden.

[boutmos]

Got the same issue on Jack Jackrum. Fixed %2F and %20 in master/lib/plugins/indexmenu/scripts/contextmenu.js on function getid :

    /**
     * Build a url to a wiki page
     *
     * @param {string} urlbase
     * @param {string} id
     * @returns {string}
     */
    getid: function (urlbase, id) {
      // Replace spaces with + before encoding
      id = id.replace(/ /g, '+');
      // Split the id by slashes, encode each part, and join them back with slashes
      let encodedId = id.split('/').map(encodeURIComponent).join('/');
      let url = (urlbase || '') + encodedId;
      url += (urlbase.indexOf("?") < 0) ? '?' : '&';
      return url;
    },

in local.protected.php put also $conf['sepchar'] = '-';

[fiwswe]

in master/lib/plugins/indexmenu/scripts/contextmenu.js

That seems to be a part of the IndexMenu Plugin, not of DokuWiki itself. How is this relevant to this issue?

[boutmos]

Because I had the same problem with %20 when I use contextmenu with indexmenu

[fiwswe]

@boutmos Well then, even if your observations seem to be similar, that would still make them an a problem with the IndexMenu Plugin. I don't see any issue at the DokuWiki level. And the discussion about the original problem pointed at the Page Buttons Plugin and an interaction with certain optional Apache httpd configuration settings.

You should file an issue for the IndexMenu Plugin at https://github.com/samuelet/indexmenu.

[splitbrain]

After further investigation, it turns out that this is a change in Apache's rewrite module as discussed at https://stackoverflow.com/q/75684314

Adding the B flag to the rewrite rules fixes the issue:

RewriteEngine on                                                                                                        
                                                                                                                        
RewriteRule ^_media/(.*)              lib/exe/fetch.php?media=$1  [QSA,L,B]                                             
RewriteRule ^_detail/(.*)             lib/exe/detail.php?media=$1  [QSA,L,B]                                            
RewriteRule ^_export/([^/]+)/(.*)     doku.php?do=export_$1&id=$2  [QSA,L,B]                                            
RewriteRule ^$                        doku.php  [L]                                                                     
RewriteCond %{REQUEST_FILENAME}       !-f                                                                               
RewriteCond %{REQUEST_FILENAME}       !-d                                                                               
RewriteRule (.*)                      doku.php?id=$1  [QSA,L,B]                                                         
RewriteRule ^index.php$               doku.php 

However, there are a couple of open questions:

• Does adding the B flag pose any security risks? I wouldn't think so, but I have to admit I do not fully understand the description of the flag
• Can we add the B flag without negatively affecting users of older Apache versions?

[macin]

Ok, partial success. Adding the B flag worked on my local env based on dokuwikistick server. However still not working with the production server.

[splitbrain]

Which Apache version are you running in production? Is there any other server in front? Like a reverse proxy?

[macin]

Ok, we looked inside with devops guys, and we found that the htaccess was being overwritten by the some apache config. So one hurdle overcome

The apache version is: Apache/2.4.57 (Debian)

we managed to get to this point (I'd expected to see already an editor) Nevertheless, clicking the button to create page does not work either, so still something is not correct... no ideas what to go for next...