Cannot create user or login

[loranger]

Hello,

In order to have a generic setup for my grav projects, I tried to create a bootstrap procedure, but I'm stuck with the admin plugin.

The aim is the following : Installing grav from git in order to being able to use git pull for upgrades and pushing my project on any git(hub/lab/olite) host, and deploying easily. All of this should be automated using ansible or any shell script.

Before trying to deploy online on a linux machine, I tried to bootstrap it manually on my Mac OSX 10.12.2... and failed.

I use an hombrew-ed nginx, with php 7.0 fpm. I used to use grav and my other (manually installed) existing grav projects works flawlessly with this osx setup.

Here is the steps I followed :

• cloning grav develop branch git clone https://github.com/getgrav/grav.git myproject
• entering myproject cd myproject
• installing grav bin/grav install
• installing admin plugin bin/gpm install admin

Everything seems to be installed perfectly (“Grav is running!”) Before going further, I verify the Admin plugin by opening the corresponding url http://myproject.dev/admin (dnsmasq is resolving my .dev projects locally)

The Admin plugin detects no user account and provides me the usual form in order to create the very first user. I fill in the form, being carefully respecting the validation rules, but I'm always redirected to the same empty form with the following error message : Oops there was a problem, please check your input and submit the form again.

I tried with a CLI user creation but the result is the same.

I also tried with the manual user creation but I cannot log-in : I always get a Invalid security token error (and my password is not hashed and remains clear)

I thought it was a permission issue, but comparing the existing project permissions with the fresh one did not show me anything special, so in order to be sure, I tried to chmod -R a+w . and did not notice any better changes.

What did I miss ? Could you help me to figure out where is my mistake, please ?

[flaviocopes]

What is your nginx config for the Grav site? https://github.com/getgrav/grav/blob/develop/webserver-configs/nginx.conf ?

Also post the nginx.conf you're using in order to replicate the problem.

[loranger]

Thanks for your support,

Here is the nginx conf I use :

server {
    listen          80;
    server_name     ~^(?<project>.+)\.dev$;

    root /Users/loranger/Developer/projects/$project/;
    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ /index.php?_url=$uri&$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

I really don't understand, my previous grav+admin, installed from skeletons works perfectly. Is there an issue with the develop version of grav ?

[flaviocopes]

Not any known issue, nothing changed regarding that functionality so that's likely an environment problem. I can't replicate it, maybe try posting your whole nginx.conf, not just the site config, so I can try that too?

Also try clearing your browser cache.

[Kuurusch]

Hallo, I have the same problem. My Grav-installation runs on an openWRT system and I use lighttpd. Strangely I tried to use the console command to create a user and it gives me "no php found" or something like this. But everything works. So it's not a php problem. Could it be that it has something to do with the php installation path? Maybe this is under openWRT different?

[rhukster]

You need php available via the CLI not just webserver. Maybe it's not installed or just not in your path?

[Kuurusch]

Ok, thanks! I lokated the problem now, that php-cli is installed, but the system only finds it, when I tipe in php-cli. php alone it dont knows. Have you an idea, how I can fix that?

[Kuurusch]

Hey rhukster, hm so I'f figured it out, this runs in the console and I can create over the console a new user. But in the webgui it still doesen't work. Have you an idea? How could I debug it somehow? It said something like "Uups, someting went wrong!" And now because I've created over the console a new user I come to the login-screen but it sais "Invalid Security Token". Have you an idea what could lack in my installation? Some other php module? By the way, the normal Grav installation runs and I can see the standard front page.

[flaviocopes]

@Kuurusch the problem is caused by the security token being different when the Admin login page is built, and when it's verified after the form is submitted.

If you feel confident in doing some debugging, you can error_log() the $nonce variable and the self::getNonce($action) return value here https://github.com/getgrav/grav/blob/develop/system/src/Grav/Common/Utils.php#L727

If they are different, you can further debug the Utils::generateNonceString method, in the same file.

---

Edit: Normally, the 2 values should be the same. In this case, for some reason it seems they are not, could be caused by the environment but first we need to check if this is the case, and how they differ.

[Kuurusch]

@flaviocopes Ok, I've checked it! They are not the same! $nonce is => bf5a5183a213c7c43e12717fc66c4633 and self::getNonce($action) is => 42cb945bafc1130978367f27dae2cb1e

What should be the nonce? Should it be the hashed password like in the yaml file of the user?

[flaviocopes]

In that same file, the generateNonceString method contains the string not hashed, with all its components (this line: https://github.com/getgrav/grav/blob/develop/system/src/Grav/Common/Utils.php#L638) try dumping that?

[Kuurusch]

@flaviocopes okdoky, this line gives me that: 34400|admin-form||5bdf3960b6ef7a3c184e6a521bb9e898|q3j80lFzyLnS7r

But the string after admin-form|| changes every time, I perform it

Hm I see, the string $username is empty

From where takes Grav::instance()['user']; the username?

Ou, could it be something with my .conf file (.htaccess)? I downloadet the .conf file from grav, but maybe I have to edit it for the admin tool?

[flaviocopes]

Looks like the session_id() result changes on every request, while it should be the same across your session.

Could be a configuration issue? Like http://stackoverflow.com/a/36061324 (related to WP, but still applicable to your php.ini)

[Kuurusch]

@flaviocopes Hm, but shouldn't the session id change every time, I logg in? So I try to logg in and it creates a new session id. But because I cant logg in, the next time when I try to logg in, it creates a new session id. Is this behavior not normal? I think the problem is more with the empty $username variable, isn't it? Or do I miss something? And I don't understand, why the $username variable is empty. From where it takes normally the user name?

And an other question: in your link they speak from a wp-config.php file. Does this exist in the grav installation? I've changed the php.ini file but no advantages... (I've restarted the server)

An other question, could it be something with https? I use no https because im in a CJDNS-Network, someting like a intranet ;)

[flaviocopes]

(wp-config.php is related to WordPress, I mentioned it. The relevant part was the php.ini setting)

$username is only available after you're logged in. You're not yet logged in at that point.

Simply reloading the page changes the string? Or they are always the same, before/after submitting the form?

[Kuurusch]

@flaviocopes Ah ok, yea I tried with the php.ini and nothing changed. Yea, each time, I klick on the button "Login" it chanes the session id.

I also looked in the /tmp folder, where the sessions where stored. And they are there!

What I thought about session.cookie_secure, in my case it should be Off, because one can reach my website only over http, https makes in my case no sense because the connection is already secured over CJDNS. Its a new protocol where each connection is encrypted by default.

Edit: Also the reload changes the session ID!

[flaviocopes]

Do you have an option to install the site on another LAMP stack, like MAMP to see if the same issue persists? Need to isolate the problem.

[Kuurusch]

Hm, no, thats not as easy.

[Kuurusch]

@flaviocopes Hear are my php.ini settings for sessions, maybe you see something problematic:

[Session] session.save_handler = files session.save_path = "/tmp" session.use_cookies = 1 session.cookie_secure = Off session.use_only_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.cookie_httponly = session.serialize_handler = php session.gc_probability = 1 session.gc_divisor = 100 session.gc_maxlifetime = 1440 session.bug_compat_42 = On session.bug_compat_warn = On session.referer_check = session.entropy_length = 0 ;session.entropy_file = /dev/urandom session.entropy_file = ;session.entropy_length = 16 session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 0 session.hash_function = 0 session.hash_bits_per_character = 4 url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="

Edit: Have you an idea which settings could be important beside de session settings in the php.ini file? So other php.ini settings I mean?

[Kuurusch]

In whitch php file is the session firstly generated?

[flaviocopes]

You could first check if /tmp is writable (http://stackoverflow.com/a/15911876)

[Kuurusch]

Yea, it's writable, I've checked it!

Edit: An other question, my server is at the moment only reachable under a blank IPv6 adress. Could that be a problem? I remember that this produced problems in Jomla and at that time I've helped theme to fix the prolem there.

Edit2: Something else, OwnCloud is running on the same Server without a problem and I think it uses also session ID's.

[flaviocopes]

Is this a blank skeleton / grav site, or you have other plugins? I asked to test a local install since that would help figure if the problem is on the server, or just replicable anywhere.

[Kuurusch]

Yes, it's a blank skeleton. Just downloaded the Grav installation with the admin-tool

[Kuurusch]

@flaviocopes Update to my Problem!!!! I've found the Problem, it's really the IPv6 adress!!! I've set up a human readable adress and with this it works! But with this, my Problem is not finally solved, because I need to use also raw IPv6-Adresses in our system and I think today a system should be capable to work with IPv6-Adresses.

I can help you to fix the problem. Have you an idea, where and in which file I have to search for the Problem?

[flaviocopes]

I tried accessing my local site using IPv6 and I could login without issues.. didn't try a remote server but that should not be any different.

[Kuurusch]

Hm, I have the following adress and with this it does not work:

http://[fc2d:2895:8328:2bd0:1493:48a6:2ce5:366d]/HypeSite/admin

(You can't reach it from outside CJDNS)

But like this it works:

http://paulrobert.eb/HypeSite/admin

[loranger]

Sorry for the delay, @flaviocopes 😞

Here is my reply to your two monthes'old answer:

worker_processes  1;

error_log  /var/log/nginx/error.log  info;

#pid        logs/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

      access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    client_max_body_size 5m;
    #tcp_nopush     on;

    keepalive_timeout  65;

    gzip on;
    gzip_comp_level 2;
    gzip_proxied any;
    gzip_types text/plain text/css text/javascript application/json application/x-javascript text/xml application/xml application/xml+rss;

    server {
        listen       80;
        server_name  localhost;
        root /Users/loranger/Developer/;

        location / {
            index  index.html index.htm index.php;
            try_files $uri $uri/ /index.php$is_args$args;
        }

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root /Users/loranger/Developer/etc/nginx/errors/;
        }

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        location ~ \.php$ {
           fastcgi_pass   127.0.0.1:9000;
           fastcgi_index  index.php;
           fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
           include        fastcgi_params;
        }

        location ~* \.(eot|ttf|woff)$ {
            add_header Access-Control-Allow-Origin *;
        }

    }

    include /usr/local/etc/nginx/sites*.conf;
    include /Users/loranger/Developer/etc/sites/*.conf;

}

I can confirm it's an nginx settings issue: The fresh install I try is woking perfectly using the built-in PHP webserver.

I can't tell what happened exactly, but with the same setup, those versions works flawlessly (I can login with an existing account)

• Grav 1.0.10 + Admin Panel 1.0.9
• Grav 1.1.5 + Admin Panel 1.2.2

[flaviocopes]

@loranger please test with Grav's example nginx configuration which you can find in https://github.com/getgrav/grav/blob/develop/webserver-configs/nginx.conf - that is known to work in all cases. I see yours is quite different, so first make sure the official one is working, and then compare it with yours.

[loranger]

As you suggested @flaviocopes, I've disabled every other nginx websites configuration except the default one (localhost with the correct path) and it worked.

So I tried a lot of workarounds, accused dnsmasq, and broke a lot of configurations.

Here is where I stand right now: If the domain name contains an underscore, admin always return an invalid token.

Here is my test:

First I install a brand new Grav setup at /Users/loranger/Developer/projects

$ git clone https://github.com/getgrav/grav.git testgrav
$ cd testgrav
$ bin/grav install
$ bin/gpm install --all-yes admin

I've disabled all nginx website configuration except the default nginx conf and have changed those two lines only

root /Users/loranger/Developer/projects/testgrav;
server_name test.grav my_test.grav project.test.grav project.my_test.grav my_project.test.grav my_project.my_test.grav my_project.another.grav;

I've forwarded the .grav tld to 127.0.0.1 using dnsmasq, but using /etc/hosts works too.

I've tried, one by one, all the server names defined in the conf file. Before each test, I was removing the user/accounts/*.yaml files if exists I've always been forwarded to the /admin route where I tried to create an account. I've always filled in the form with the same values.

Here are my results:

Server name	Account creation
http://test.grav	✅
http://my_test.grav	❌ Oops there was a problem, please check your input and submit the form again.
http://project.test.grav	✅
http://project.my_test.grav	❌ Oops there was a problem, please check your input and submit the form again.
http://my_project.test.grav	✅
http://my_project.my_test.grav	❌ Oops there was a problem, please check your input and submit the form again.
http://my_project.another.grav	❌ Oops there was a problem, please check your input and submit the form again.

I suspect a regular expression issue but wasn't able to find it. I don't know where it could be, and I start searching but it was like pulling the wire of a yarn ball ;)

Anyway I hope you could reproduce it and I really hope it would help

[takmatumot]

Hello, I also test the Server name above and found it is not working also if the url include "-" such as http://matumot-3.test.grav

[zanami]

I'm really lost

In Safari @ Mac OS

1. Admin login doesn't work (Invalid Security Token)
2. Forms don't work (Oops etc, same reason I believe)

Clearing Grav cache, browser cookies — same story. I don't know what else to clear/reset/remove to resolve this.

Everything works fine in Chrome and in Firefox on the same Mac Also works in Safari on a different Mac which never has accessed the site. Works in Safari @ iOS

[flaviocopes]

Seems a weird issue. Did you try in a Private window?

Maybe try downloading the latest WebKit Nightly https://webkit.org/nightly/ and see if you can replicate as well.

[zanami]

Yeah, weird. Today everything is back to normal. Yesterday I fiddled with nginx.conf but it didn't change anything noticeably at that time. Still have no idea what was the difference between Safari and Chrome in that respect.

Thanks!

[flaviocopes]

Does your theme override the templates/form/* templates? Is the form plugin up to date?

[zanami]

It did before but at some point I deleted them. Plugin isn't the latest ver (2.7, 2.8 available), but it's fairly up to date and works fine in other browsers.

I believe there was something wrong with Safari. Clearing cache/cookies/reboot resolved the problem. Now it works.

[MisterAO]

I have the same issue, can someone help me debug?

[jervtub]

Hi, I just wanted to let know how I fixed this particular issue.

When my sessionID in PHP remained persistent on browser refreshes the problem got resolved.

I run GRAV with the build-in PHP server over HTTP. It sits behind a reverse-proxy that handles the SSL connection.

I did a fresh install of GRAV with the Admin plugin. Starting the server with php -S mywebsite:80 didn't give a single error.

I updated the system.yaml blueprint (system/blueprints/config/system.yaml) to set a default of true for the reverse_proxy_setup.

                        reverse_proxy_setup:
                            type: toggle
                            label: PLUGIN_ADMIN.REVERSE_PROXY
                            highlight: 0
                            help: PLUGIN_ADMIN.REVERSE_PROXY_HELP
                            options:
                                1: PLUGIN_ADMIN.YES
                                0: PLUGIN_ADMIN.NO
                            default: true
                            validate:
                                type: bool

I ensured the server would listen to the actual domain name the client is requesting. When I made this match I noticed the Session ID remained persistent after reloads. php -S <actual-domain-name>:80

To check for the persistence of the Session ID. I updated system/src/Grav/Framework/Session/Session.php

    public function getId()
    {
        error_log(session_id());
        return session_id();
    }

[stphane]

I faced the Oops there was a problem... issue because my grav website is exposed as a sub-directory: https://mydomain.tld/myblog. I had set the .custom_base_url configuration key accordingly in user/config/system.yaml once Grav was installed.
I finally figured out that the .session.path configuration key also had to be changed and set to "/myblog/" for the admin plugin user-creation form to be processed successfully.

Setup: _php-7.3-fpm and Redis session handler ; NGINX : location block + named location block for fastcgipass.