Cookies not working on localhost: redirect to 127.0.0.1

[e2jk]

Turns out by design domain names must have at least two dots to accept cookies:

Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".

Using Chromium in Debian, I was seeing the following error message after first installing Shaarli (while building the newest version of the Debian package) and going to http://localhost/shaarli :

Sessions do not seem to work correctly on your server
Make sure the variable session.save_path is set correctly in your php config, and that you have write access to it.
It currently points to <PHP's session folder>

Click to try again

After some time going through the code and adding debug statements, observing that the server was correctly sending back a set cookie header, not finding any logical reason why this was failing, I found the above-mentioned link and tried going to http://127.0.0.1/shaarli instead, which worked just fine.

I'd suggest adding a check to the install() function's Step 2: if the hostname is localhost, redirect to 127.0.0.1 (still with ?test_session)

[nodiscc]

Turns out by design domain names must have at least two dots to accept cookies

Most interesting. Why not add a simple reminder to the error message? Instead of trying to work around the HTTP cookie spec? Like

echo 'If you're accessing your server via http://localhost/, the HTTP protocol specification forbids settings cookies, causing this error. Please access your server via http://127.0.0.1 and try again.';

[e2jk]

This seems to not be an issue in Firefox, so displaying this error message would be a false positive there. And I have no plans to make Firefox respect this specification more strictly to the letter ;)

localhost is an alias to 127.0.0.1, so I don't see redirecting from the former to the latter as being a "work around" the specs, just a different way to see things.
But on the other hand, as mentioned in the #97, the redirection or you suggested error message would not properly address the case when the server name is e.g. http://NSA310 .
What would address the issue (but might seem a bit too complex maybe) is the following algorithm:

1. If server name doesn't contain a period
2. and browser is Chrom{e|ium}
3. detect the public-facing IP the server is running on (either on the Internet if available, else on the local network) and redirect to the same page using that IP address.

Seems complex to me. I would suggest doing the localhost to 127.0.0.1 redirection (then we address this specific case), and show an error message if the server name doesn't contain a dot, explaining they need to use the IP address instead. That:

• handles a common case (all servers have localhost/127.0.0.1)
• shows an error message for the other cases, while saving us from developing point 3.

(would the error message be shown to all browsers, or only Chrome-family? On the one hand you don't want false-positive mesages in Firefox, but how to make sure you cover all browsers that use Chrome's engine?)
Thoughts?

[nodiscc]

I would suggest doing the localhost to 127.0.0.1 redirection [...] show an error message if the server name doesn't contain a dot

Yep. I don't think the message should only be show for chromium-based browsers (there are many many browsers out there and we don't know which ones are affected, plus the user agent detection is not really reliable). We could even skip the redirection/dot-in-server name detection for simplicity and add this to the current error message:

Check that the hostname used to access Shaarli contains a dot. On some browsers, accessing your server via a hostname like 'localhost' or any custom hostname without a dot causes cookie storage to fail. We recommend accessing your server via it's IP address or Fully Qualified Domain Name

This would prevent occasional confusion like in #97

Thoughts?

[e2jk]

I like the idea. Let's go with that, and maybe in the future "enhance" the experience by automatically redirect localhost (as that one is rather common and easy to figure out), while leaving other options just relying on the error message.