the case of the multiplying arguments (oh no!) in dokuwiki

Once again, I’m back with a web application related post:

This time, it’s dokuwiki. I didn’t notice it myself, perhaps because it only crops up under certain situations, but someone on my wiki told me when they saved a page, it showed up as wiki/pagedo=edit. This was strange, so I started investigating. I finally got it to be reproduceable when logging in, out, then back in again. It ended up with a link like wiki/pagedo=logoutdo=login or similar.

My first thought for this issue was my nginx config, which ended up being correct. If you’re experiencing this, and followed a guide where you rewrite something like ^/(.*)/ to /doku.php?page=$1$args, then you’re missing one small symbol: &

You need to replace that rewrite with /doku.php?page=$1&$args. Otherwise, under certain circumstances (and I still don’t know why it doesn’t happen all the time), the first argument will end up as part of the page. So page will turn into pagedo=edit, etc.

Hope this helped!

-Michael.

P.S. If you’re interested in the wiki I’m talking about (the one that now works properly), you can visit it here.

the odd nginx http to https infinite redirect

After a long, long time of inactivity, I’m back to publish a new post. Hopefully I will be publishing posts more often, depending on when I find things like this to share, anyway, here goes:

I was setting up a site on my vps, and for some strange reason, the standard listen 80 block with a redirect to the 443 block was causing infinite redirects I.E. firefox was saying the request would never complete. So I dug around, and couldn’t find anything different about a site that properly redirected versus this one. So my next course of action was the application itself (my other sites were mainly WordPress, and this was a URL shortener).

So I asked on the issues on github for the URL shortener, and they didn’t seem to have an idea, except for some things I had already tried. This had me pretty stumped for a while, so I basically gave up on it and just had one block that served both http and https… Until:

I switched to another URL shortening software, and the infinite redirect, when the proper code was put back in place, was still happening. So this basically ruled out the application, so where else was I to look.

The answer came, quite by accident, when I was looking at my cloudflare settings for my domain, and noticed the ssl was set to “flexible.” This was when a lightbulb sprang up in my head.

For those who don’t know, cloudflare has a few ways of proxying traffic to and from your web server, including one, flexible ssl, where the ssl is terminated at cloudflare, and the connection is unencrypted from cloudflare to your server. This basically means it presents the client on port 443, but gets the data from your server on 80. However, when nginx receives a request on port 80 in this case, it thinks it’s using plain http, so tries to redirect to https, which, of course, cloudflare just proxies back on port 80 again. And thus the cycle continues.

The fix was to set ssl to either full (ssl from your visitor to cloudflare, and from cloudflare to your web server), or ssl strict (the same, except cloudflare will verify the certificate from your web server). This caused ssl traffic to come into nginx on port 443, as it was expecting.

Hope this helps with anyone who might have a strange problem like this and is using cloudflare.

-Michael.