Page MenuHomePhabricator

Using upper case letters in URL, calendar isn't shown
Closed, InvalidPublic


  • Our DokuWiki installation uses the general URL https://<server>.<domain>.de/dokuwiki/doku.php.
  • Invoking the URL https://<server>.<domain>.de/dokuwiki/doku.php?id=… shows all contents of selected page including the calendar – as expected.
  • Using similar URL https://<server>.<domain>.de/DokuWiki/doku.php?id=… (note the two upper case letters in directory name DokuWiki) doesn't show the calendear but all other content.


Event Timeline

Short answer: dokuwiki and DokuWiki are - usually - two separate folders and you should *never* mix them.

That being said: The calendar uses some internally defined variable (DOKU_BASE) to determine the URL it needs to retrieve calendar pages from. This variable is initialized based on the folder name on the file system and thus uses only one of the two names. I assume that later on a CSRF check fails because the paths do not match.

Could you check whether inserting a link using the link wizard in the edit page dialog works? The link wizard uses a very similar logic to retrieve the pages to link to.

Sorry, I've forgotten to write that we are using IIS. You are right, DokuWiki and dokuwiki are separate folders – on UNIX systems. But using IIS on Windows Server, both names refer to the same directory. Therefore, we are able to use both styles. It works with all pages except pages using davcal.

I've tried to insert a link using the link wizard. It doesn't matter if the link contains DokuWiki or dokuwiki.

OK, then my theory is probably wrong :(

I would like to investigate this, but I do have neither Windows nor IIS - do you think you could create a (limited) account for me or a public page with a calendar so I can check at least the requests the browser sends? An empty calendar would be OK.

Unfortunately, that's not possible. We are using DokuWiki in our Intranet. Access from outside isn't possible.

Then we need to go the more complicated route and I have to ask for more details:

  • Browser Network Log (requests and responses related to davcal)
  • JavaScript console output
  • DokuWiki debug log
  • DokuWiki version
  • davcal version
  • Browser version
This comment was removed by charlykwr.

Thanks - DokuWiki thinks the request is a CSRF attack. The reason is that some requests are performed to your uppercase URL and some to your lowercase URL. I suppose that IIS invokes separate PHP instances for the different URLs and thus the security tokens do not match.

IMHO this is not a bug. I would try to use some rewrite rules to redirect all requests from DokuWiki to dokuwiki or some other fancy configuration changes to fix this issue on your side.

OK. Thank you for your analysis. I will try it. Many thanks.