[BUG] unable to create first user on ip-based server

[jadwigo]

If you want to setup the first user on a site that that you get to without a domain name you will get the following error: The CSRF token is invalid. Please try to resubmit the form.

If you do the samething on the exact same site with a domain it works.

Details

• Relevant Bolt Version: 3.0
• Install type: Zip/tarball install http://bolt.cm/distribution/bolt-3.0.0-alpha8.tar.gz
• PHP version: PHP Version 5.5.9-1ubuntu4.14
• Database: sqlite 3.8.2
• Used webserver: Nginx nginx/1.4.6

Reproduction

I tried this on a digitalocean lemp droplet and when I accessed it through the ip address of the droplet it did not allow me to setup the first user.

I checked if all folders were writable to the webserver user and I tried different cookie settings for https://github.com/bolt/bolt/blob/master/app/config/config.yml.dist#L343

When I accessed it through a domain it worked.

[rixbeck]

I had a similar challenge yesterday. I was unable to create first user with the same CSRF error. My server is a LXC container based VM under my Ubuntu box. Tried with a clean checkout/compser-install/update setup with Nginx first then Apache. I was careful about running the same user with both webserver on the same webroot folder, and file permissions was okay.

Requests look like

• http://bolt.d64:8080/bolt/userfirst in Nginx
• http://bolt.me/bolt/userfirst in Apache

Both of them produced same result repeating CSRF error messages while session entries created under cache folder. Also tried with different browser and cleared browser cookies, until I lowering login session hardening level with

cookies_use_httphost: false in config.

At this moment the first user has been created with Apache and able to log in under http://bolt.me
but can't with http://bolt.d64:8080.

I'm trying to get into deeper...

[jeffpfoster]

I can confirm this bug is happening as well. I was testing the upgrade path to 3.0.x and setup a new server which didn't have an IP address entry yet. Received the error mentioned above. I am adding a DNS entry now to test if getting through user setup with the domain name works.

Testing: verified issue does not exist in version 2 with a fresh install. Pointed the webroot at a version 3.0.1 and 3.0.4 and reproduced the issue.

[rixbeck]

Are you on port 80?

On 1 June 2016 7:39:28 a.m. Jeff Foster notifications@github.com wrote:

I can confirm this bug is happening as well. I was testing the upgrade
path to 3.0.x and setup a new server which didn't have an IP address entry
yet. Received the error mentioned above. I am adding a DNS entry now to
test if getting through user setup with the domain name works.

Testing: verified issue does not exist in version 2 with a fresh install.
Pointed the webroot at a version 3.0.1 and 3.0.4 and reproduced the issue.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#5014 (comment)

[jeffpfoster]

I'm on port 80 with an nginx and php 7 install. Initial setup attempt was on sqlite3.

[jeffpfoster]

Further details after playing around with this some more. Not an IP address issue. It appears to be an issue with nginx and bolt 3.0.x.

Testing Configurations: Both with and without DNS hostname mapping.
Ubuntu 16.04
Nginx 1.9.15 (ubuntu modifications) - same site configuration used for nginx for all tests
Php 7.0.4 (ubuntu modifications)

Bolt Version	Result
2.2.21	Success
3.0.1	Fail
3.0.4	Fail

Differences seen between the 2.x and 3.x builds. I noticed that the bolt_session cookie is not being created with the 3.x versions.

[jeffpfoster]

@SahAssar I've got a server with the issue if you want to look at it to verify the issue. I would say it is more of an issue with nginx and not the ip-based server so I can create a new issue if you'd rather track it that way.

[SvanteRichter]

@jeffpfoster I'd love to. I run nginx on all of my sites and while I had issues with the first user signup in early 3.0 dev I have not had those issues since then (that was late last year, early this year), so having a look at it would be very helpful.

I suspect that the problem is rooted in the difference in how we handle sessions between 2.2 and 3.0, but even then a sizeable part of the core dev team uses nginx, so I don't think it's the actual webserver that's the issue.

[jeffpfoster]

@SahAssar So I was able to get it up and running with the nginx using the FQDN (folder permissions, used the more secure command originally but when I ran the chmod 777 version it worked) but the IP address doesn't set cookies correctly as the title of the bug states. I've still got the server in a state where you can test it if you want before I blow it away. If you want to check it out send me an email or DM on twitter.

[neosin]

I have this same issue with Bolt 3.1.5 using 127.0.0.1:8080 as host, cannot create first user at all due to CSRF issue

[bobdenotter]

This is something that we can't easily fix. I suggest to use http://localhost:8080 instead. :-)

[SvanteRichter]

Closing because of all the reasons in #5746 (comment)

[jadwigo]

This is something we will need to keep in mind for troubleshooting if someone is setting up a bolt site on a new server that has no DNS entry yet.

People will have to add an entry to their own hosts file or setup a temporary dns to access their site.

[djaed]

simply adding entry to /etc/hosts finally solved my 'CSRF token is invalid' problem on fresh local bolt 3.2 install running in docker containers (php7,nginx,mariadb) ... thanks @jadwigo ... its been a long day of troubleshooting ... wish i had found your comment sooner

[bobdenotter]

Added a configuration notice for this one: bolt/configuration-notices#14