PrettyURLs doesn't work for /agreement

[MegaBrutal]

For some reason, the /agreement link on my forum leads to 404 with PrettyURLs 4.2.

https://asperger.hu/agreement/

It works with its non-pretty form:

https://asperger.hu/index.php?action=agreement

Hilariously enough, the agreement link without a trailing slash gives the raw BBCode text of the agreement... don't even understand how that may happen.

https://asperger.hu/agreement

The Apache rewrite rule is in place, and generally PrettyURLs works throughout the forum aside from the agreement.

Code Select Expand

RewriteRule ^(agreement|acceptagreement|activate|admin|announce|attachapprove|buddy|calendar)/?$ ./index.php?pretty;action=$1 [L,QSA]

What might be the problem?

I know it's a third party mod, might not be supported...

[GL700Wing]

@MegaBrutal You should post this request for support in the Pretty URLs support topic.

[MegaBrutal]

Thank you, posted:
https://www.simplemachines.org/community/index.php?msg=4185088

[live627]

I clicked that link and it works.

[MegaBrutal]

Yep, managed to fix it since then. It was really an Apache server config problem: the MultiViews option was enabled to the directory. Probably I copied over from a template. Pretty nasty and security concerning option to be enabled on an SMF installation directory. All the time I was blaming Rewrite and even made the forum unusable for users because it turns out SMF forces to accept the agreement on existing users after being set, thus all of them got redirected to the defunct URL immediately after login.

[Kindred]

...turns out SMF forces to accept the agreement on existing users after being set, thus all of them got redirected to the defunct URL immediately after login.

Yes, this is a legal requirement in the EU and many other places -- if the terms of service (aka the user agreement) changes - users must be informed and must accept the new version

[vbgamer45]

Thanks MegaBrutal that's where very interesting to hear never heard of that issue.

[MegaBrutal]

...turns out SMF forces to accept the agreement on existing users after being set, thus all of them got redirected to the defunct URL immediately after login.

Yes, this is a legal requirement in the EU and many other places -- if the terms of service (aka the user agreement) changes - users must be informed and must accept the new version

You know the irony is that these are the same rules established in 2013, I only had to set them again because the 2.1 upgrade has overwritten it. I'm already getting complaints about it... Is there a way to force SMF to don't consider these new? Like, can I just touch the agreement file to an earlier date?

Thanks MegaBrutal that's where very interesting to hear never heard of that issue.

I provide some more details. So the MultiViews option serves files on partial matches, so if you manage to hit the first part of an otherwise valid filename, Apache will serve you the file despite you didn't provide the full filename. In this case, /agreement was expanded to /agreement.hungarian.txt and thus you got the raw text file; /agreement/ was expanded to /agreement.hungarian.txt/ which is – since not a directory, got 404. This expansion happens before the Rewrite rules get evaluated, thus the rules are applied to the expanded filename, not the original request. This also explains why the other prettified URLs worked, as they didn't collide with existing filenames.

In case of SMF it might be a security concern because it allows potential wrongdoers to search for internal files by providing partial filenames (although I can't think of an actual exploit, now I checked that it still doesn't allow to get the source code of Settings.php thankfully). I actually suggest the SMF install documentation to include that MultiViews should be disabled, as well as PrettyURLs install and troubleshooting guides to be extended with this information.

I don't know if this is a thing with other webservers, such as IIS, IHS, Nginx, etc., whether they support a similar setting that needs to be avoided (IHS probably, being a fork of Apache).