404 On Login.

[MadBloris]

Hiya. I am getting a 404 when trying to login. I get passed through to the authentication page, click allow and then it errors with this message.

{"url":"/api/social.satan-speaks.com/oauth/https:/social-hell.uk?code=*******","statusCode":404,"statusMessage":"Page Not Found: /api/social.satan-speaks.com/oauth/https:/social-hell.uk?code=*****************","message":"Page Not Found: /api/social.satan-speaks.com/oauth/https:/social-hell.uk?code=**************","stack":""}
(Code Excluded)

I've tried via docker, running with nr, and on a second machine (albeit on the same local network)

Any ideas?

nginx conf

server {
    server_name social-hell.uk www.social-hell.uk mail.social-hell.uk;
    listen 192.168.1.60;
    root /home/mastodon/elk/;
    index index.php index.htm index.html;

location / {

  proxy_pass http://192.168.1.60:5314/;
}

    fastcgi_param GATEWAY_INTERFACE CGI/1.1;
    fastcgi_param SERVER_SOFTWARE nginx;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param CONTENT_TYPE $content_type;
    fastcgi_param CONTENT_LENGTH $content_length;
    fastcgi_param SCRIPT_FILENAME "/home/social-hell/public_html$fastcgi_script_name";
    fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    fastcgi_param REQUEST_URI $request_uri;
    fastcgi_param DOCUMENT_URI $document_uri;
    fastcgi_param DOCUMENT_ROOT /home/social-hell/public_html;
    fastcgi_param SERVER_PROTOCOL $server_protocol;
    fastcgi_param REMOTE_ADDR $remote_addr;
    fastcgi_param REMOTE_PORT $remote_port;
    fastcgi_param SERVER_ADDR $server_addr;
    fastcgi_param SERVER_PORT $server_port;
    fastcgi_param SERVER_NAME $server_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param HTTPS $https;
    location ^~ /.well-known/ {
        try_files $uri /;
    }
    location ~ "\.php(/|$)" {
        try_files $uri $fastcgi_script_name =404;
        default_type application/x-httpd-php;
        fastcgi_pass unix:/var/php-fpm/1676978962104934.sock;
    }
    fastcgi_split_path_info "^(.+\.php)(/.+)$";
    location /cgi-bin/ {
        gzip off;
        root /home/social-hell/cgi-bin;
        fastcgi_pass unix:/var/fcgiwrap/1676978962104934.sock/socket;
        fastcgi_param SCRIPT_FILENAME "/home/social-hell$fastcgi_script_name";
        fastcgi_param GATEWAY_INTERFACE CGI/1.1;
        fastcgi_param SERVER_SOFTWARE nginx;
        fastcgi_param QUERY_STRING $query_string;
        fastcgi_param REQUEST_METHOD $request_method;
        fastcgi_param CONTENT_TYPE $content_type;
        fastcgi_param CONTENT_LENGTH $content_length;
        fastcgi_param SCRIPT_NAME $fastcgi_script_name;
        fastcgi_param REQUEST_URI $request_uri;
        fastcgi_param DOCUMENT_URI $document_uri;
        fastcgi_param DOCUMENT_ROOT /home/social-hell/public_html;
        fastcgi_param SERVER_PROTOCOL $server_protocol;
        fastcgi_param REMOTE_ADDR $remote_addr;
        fastcgi_param REMOTE_PORT $remote_port;
        fastcgi_param SERVER_ADDR $server_addr;
        fastcgi_param SERVER_PORT $server_port;
        fastcgi_param SERVER_NAME $server_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS $https;
    }
    listen 192.168.1.60:443 ssl;
    ssl_certificate ;
    ssl_certificate_keyy;
}

[stackblitz[bot]]

Start a new pull request in StackBlitz Codeflow.

[alexgleason]

I'm having roughly the same problem, and it's because the origin isn't URI encoded.

When my application redirects here, it produces a 404: https://elk.zone/api/ditto.pub/oauth/https://elk.zone?code=xxx

When I go here instead, it works: https://elk.zone/api/ditto.pub/oauth/https%3A%2F%2Felk.zone?code=xxx

You can actually edit the URL manually and resubmit it. It will log you in.

I'm not sure this is something I can solve on my end since the redirect_uri is coming from Elk. I think Elk should just be able to handle the unencoded URI, or at least encode the redirect_uri value before giving it to the application. EDIT: It's actually me who is decoding it, but :facepalm: I'm doing that because other clients do send the full redirect_uri encoded, so I need to decode it.

Also it's because routing is handled by filesystem paths like [origin], but the origin itself is a URL with slashes in it: https://github.com/elk-zone/elk/blob/main/server/api/%5Bserver%5D/oauth/%5Borigin%5D.ts

EDIT: I fixed my problem like this:

function maybeDecodeUri(uri: string): string {
  try {
    new URL(uri);
    return uri;
  } catch (_e) {
    return decodeURIComponent(uri);
  }
}

[hjhornbeck]

Just wanted to chime in that I've encountered the same error. I'd prefer to use Docker containers to host elk on my server, so this is a major obstacle at the moment.

[alexgleason]

@hjhornbeck Can you confirm if it's because of slashes in the URL, or?

[hjhornbeck]

It is, though I'm not quite seeing the same thing you are. The URL that's being requested is:

https://[host.domain]/api/[target.domain]/oauth/https://[host.domain]?code=[API code]

But the JSON file returned with the 404 says this URL was being requested instead, via the "url" field:

/api/[target.domain]/oauth/https:/[host.domain]?code=[API code]

One of the forward slashes is being stripped away, which presumably is causing the issue. If I switch to URL encoding (ie. %3A%2F%2F), a slash is still stripped away. If I add a third slash, two slashes are stripped away. Adding a URL-encoded backslash before the two forward slashes leads to the delightful "https:\/" in the "url" field. All of which lead to a 404, of course.

I popped your solution into line six, and it made no difference. I don't have a lot of experience with Javascript, let alone this style of Typescript, so there's a strong chance I did it wrong. I'll also start walking back through the release tags to see if I can narrow down when this bug was introduced, though I see the file you pointed to has been unchanged for three months.

[eliastorres]

When using Apache mod_proxy you can use "mapping=encoded" at the end of the ProxyPass parameter, for example

ProxyPass / http://10.1.2.3:5314/ retry=0 mapping=encoded

I don't know if this is needed on the whole / or just in specific paths.