[Bug]: The "open" and "closed" did not navigate properly.

[Hoshino-Yukino]

Is there an existing issue for this?

• I have searched the existing issues

Version

v0.6.4

In which part of the application does the error occur?

Frontend

Current Behavior

Opening will redirect to http://127.0.0.1:3000/?status=open
Closing will redirect to http://127.0.0.1:3000/?status=closed

Expected Behavior

Opening will redirect to https://mysite.com/?status=open
Closing will redirect to https://mysite.com/?status=closed

Steps To Reproduce

docker:
docker run --name modmail-viewer -p 3000:80
--env "MODMAIL_VIEWER_MONGODB_URI="
--env "MODMAIL_VIEWER_URL=https://mysite.com"
--env "MODMAIL_VIEWER_DISCORD_OAUTH_CLIENT_ID="
--env "MODMAIL_VIEWER_DISCORD_OAUTH_CLIENT_SECRET="
--env "MODMAIL_VIEWER_DISCORD_GUILD_ID="
--env "MODMAIL_VIEWER_SECRETKEY=***"
-d ghcr.io/khakers/modmail-viewer:latest

Environment

- OS:Ubuntu 20.04

Relevant log output

No response

[khakers]

Are these the links in question?

[Hoshino-Yukino]

yes

[khakers]

That's an odd bug, I'll look into it later.

I suspect it's fixed in 1.0.0-alpha.1 since that section has been rewritten.

[Hoshino-Yukino]

ok

[khakers]

So far I haven't been able to reproduce this in testing. Do you have some sort unusual environment that might be causing some confusion?

[Hoshino-Yukino]

I tested it. When I only use modmail-viewer, there will be no problems. But when I use nginx reverse proxy before modmail-viewer, problems will arise. The nginx configuration is as follows:

#user  nobody;
worker_processes  1;

events {
    worker_connections  1024;
}

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

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    server {
       # listen       443 ssl;
       listen       80;
       server_name  34.85.114.87;

       add_header 'Access-Control-Allow-Origin' '*' always;
       add_header 'Access-Control-Max-Age' '1000' always;
       add_header 'Access-Control-Allow-Methods' "POST, GET, OPTIONS, DELETE, PUT" always;
       add_header 'Access-Control-Allow-Headers' "x-requested-with, Content-Type, Origin, authorization, Accept, client-security-token" always;

       error_page 497 https://$host$uri?$args;

       location /{
            proxy_pass http://127.0.0.1:3000/;
       }
       error_page   500 502 503 504  /50x.html;
       location = /50x.html {
           root   html;
       }
    }
}

[Hoshino-Yukino]

I've started using Cloudflare for reverse proxy, and the problem is now solved 😂.

[khakers]

I'm reasonably sure this is an nginx configuration issue then. Unfortunately I'm not sure what the correct configuration would be for proxying, but at least the issues solved for you.

[khakers]

That said there's more I can do on my end to improve handling of this issue.