"no token present in request"

[DaytonG]

Version: 0.7.1 release 1

(Noticed this was mentioned in #272, but version 0.7.1 doesn't seem to have the offending code. At least as far as I can see it)

I upgraded a functional uchiwa server from a very old version (0.2.4-1) to 0.7.1-1, and I can no longer log into the server. The /login call seems to go fine, but then /get_config and /get_sensu return a 401 saying "no token present in request" and I get kicked back out to login.
My config is...

{
    "uchiwa": {
        "port": 3444, 
        "stats": 10, 
        "user": "uchiwa", 
        "refresh": 10000, 
        "pass": "*****"
    }, 
    "sensu": [
        {
            "ssl": false, 
            "host": "127.0.0.1", 
            "name": "Sensu", 
            "timeout": 5000, 
            "pass": "", 
            "path": "", 
            "port": 4567, 
            "user": ""
        }
    ]
}

And I have nginx proxying the traffic with the following config

server {
        listen 3443;
        server_name monitor.example.com;
        location / {
            proxy_pass http://localhost:3444;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
    }
}

What am I doing wrong?

Thanks!

[palourde]

Hi @DaytonG

Did you upgraded using the packages or directly from the source code? I would also recommend you to restart Uchiwa and clear your browser cache.

Thanks

[DaytonG]

Upgraded using an RPM. Uchiwa was restarted about 2 dozen times as I was debugging. If I disable simple authentication (user = pass = ""), it works perfectly.

As for browser cache, I definitely cleared it, plus I was running firebug with the "disable caching" enabled. I also tried Chrome (which definitely had nothing cached). Same deal.

[palourde]

Hi @DaytonG

Can you try to by-pass your reverse proxy and access directly Uchiwa? Starting from Uchiwa 0.5.0, we changed the authentication method so there's possibly some tweaking to do on the nginx configuration.

Thanks!

[DaytonG]

Hm. I can't reproduce it now. The only difference that I can determine is a simplification to the nginx config.

server {
        listen 3443;
        server_name devops-monitor.example.com;
        location / {
            proxy_pass http://localhost:3444;
        }
}

Doesn't seem like it'd be the culprit. PEBKAC, perhaps.