Filemanager and jwt not working?

[targodan]

Heya,

I am new to caddy and after a successful inital setup, I wanted to use the filemanager plugin, secured by the jwt plugin. A little php-script of mine generates the token and sets it as a cookie.

Reading files works but editing/deleting/uploading doesn’t. I might just be to stupid to set it up correctly but I did my best to solve it including massive amounts of googling. So here I am now, hoping you guys can help me.

My config:

files.MYDOMAIN {
    root /var/www/MYDOMAIN/files
    internal /users.json
    import config/php7.conf # This includes a fastcgi directive for php7 (this works)
    browse /public/
    jwt {
        path /MYNAME
        allow user MYNAME
    }
    jwt {
        path /share
        allow role admin
        allow role member
    }
    browse /share/
    filemanager {
        on /MYNAME/
        show /var/www/MYDOMAIN/files/MYNAME
    }
}

This is the interesting part of my php skript using lcobucci/jwt version 3.2:

<?php

require 'vendor/autoload.php';
use Lcobucci\JWT\Builder;
use Lcobucci\JWT\Signer\Hmac\Sha256;

$jwt_secret = 'I wont show this but it also is exported to the JWT_SECRET environment variable. ;)';
$expiration_time = 3600;

$users = json_decode(file_get_contents('users.json'), true);

$username = array_key_exists('username', $_POST) ? $_POST['username'] : null;
if($username !== null) {
    $user = array_key_exists($username, $users) ? $users[$username] : null;
    $pwd = $_POST['password'];
    if($user !== null && password_verify($pwd, $user['pwd'])) {
        $hmac = new Sha256();
        $token = (new Builder())
                        ->setIssuer('https://files.MYDOMAIN')
                        ->setAudience('https://files.MYDOMAIN')
                        ->setIssuedAt(time())
                        ->setNotBefore(time())
                        ->setExpiration(time() + $expiration_time)
                        ->set('user', $username)
                        ->set('role', $user['role'])
                        ->sign($hmac, $jwt_secret)
                        ->getToken();

        setcookie('jwt_token', $token, time()+$expiration_time, '/', 'files.MYDOMAIN', true);
        header("Location: https://files.MYDOMAIN/".$username);
        $result = "success";
    } else {
        $result = "failure";
    }
} else {
    $result = "";
}

So again: Reading files works.

However, when I want to delete, edit or upload a file I get a 403 Forbidden response. I looked into the headers that were sent and the cookie is being transmitted correctly.

Is this some problem with the jwt middleware and xhr requests? I didn’t find anything in the jwt middleware issues on GitHub.

Has anyone experienced something like that? I wanted to make sure it’s not a dumb mistake of mine before opening an issue.

[targodan]

Here are the headers of me trying to create a folder called “test”:

Request URL:https://files.MYDOMAIN/MYNAME/
Request Method:POST
Status Code:403 
Remote Address:MYIP:443

Response Headers
content-length:14
content-type:text/plain; charset=utf-8
date:Sun, 21 Aug 2016 19:05:46 GMT
server:Caddy
status:403
x-content-type-options:nosniff

Request Headers
:authority:files.MYDOMAIN
:method:POST
:path:/MYNAME/
:scheme:https
accept:*/*
accept-encoding:gzip, deflate, br
accept-language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
cache-control:no-cache
content-length:0
cookie:view-list=false; jwt_token=VALID-JWT-TOKEN
dnt:1
filename:test
origin:https://files.MYDOMAIN
pragma:no-cache
referer:https://files.MYDOMAIN/MYNAME/
token:SOME-TOKEN-FROM-FILEMANAGER
user-agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

[matt (Matt Holt)]

/cc @hacdias

[hacdias (Henrique Dias)]

Hey!

Do caddy has permission to write on those files? Check their permission. I think that that’s what’s causing the 403 error.

[targodan]

I will double check that in a sec but it did work with basicauth, so I doubt that is the problem.

[targodan]

It definitely is not a file permissions problem. I just 777ed the target folder and still get the same result.

[hacdias (Henrique Dias)]

Unfortunately, I don’t what the problem can be File Manager only returns 403 when it can’t access the files due to permissions. Is there a way to contact @BTBurke (BTBurke (Bryan Burke) · GitHub)? He’s the creator of JWT and he might help.

By the way, take a look at this issue.

[targodan]

Ok, thanks for your help. I will do some more tests to narrow down the source of the problem and then open an issue at caddy-jwt.

Thanks and keep up the work on caddy, it’s amazing!

[BTBurke (Bryan Burke)]

I think the issue is with conflicting headers. It looks like both JWT and FileManager are trying to use a token header. I just pushed a change to eliminate this header because it was more a nice-to-have and rarely used. Haven’t tested it, but believe this will fix the issue.

[targodan]

I closed the issue. It works when I build caddy myself.

When are the downloads on caddyserver.com being updated?