Closed BuggyAl closed 2 months ago
Duplicate of #2303. The reasoning behind not having HTTP-only logins is covered there, but TL;DR quote:
What prevents you from being able to register via HTTP?
Passwords over HTTP are not secure. Anyone can read them. Leaking password is worse than showing the minecraft data - as passwords are often reused elsewhere. Logged in users can be impersonated, as any access token is also readable by anyone, they can add the token to their browser and appear as that person.
You can install certbot on your own pc and after creating the certificate there (following the tutorial), transfer the cert to the Minecraft server
The tutorial says I need to add a TXT record to my DNS. How would I do this on a server host such as Minehut? A clearer tutorial for Option B: If you can't install on your host
would be greatly appreciated.
If you don't control your domain you can't get a certificate for it.
You need to do one of the alternatives listed at the top of the tutorial because the requirements for the tutorial is a domain you control.
I generated my own self-signed certificate, but the page now responds with a ERR_INVALID_HTTP_RESPONSE response.
I generated my own self-signed certificate, but the page now responds with a ERR_INVALID_HTTP_RESPONSE response.
I tested the self-signed certificate locally and it worked perfectly. Does anyone know if this will work on a server host such as Minehut?
Minehut uses a double layer port system, in which server data is sent to an "internal" port of your choosing and sent to an "external port" of a specified domain, randomly assigned a port by Minehut. (ex. Dynmap for me uses 8123 but I connect using http://ext1.minehut.me:10324)
You need to put https:// in front when you have a certificate installed
This issue still applies. The certificate page now shows up but upon proceeding to the "unsafe" site through https://ext1.minehut.me:10322/ the page just stalls until resetting. I tested the same certificate locally and the Plan provided one and they both worked fine.
Doing curl to the address seems to return 404 from a non-plan webserver 🤔 Plan would respond 301 redirect to /login on first request
curl --verbose --insecure https://ext1.minehut.me:10322
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 23.92.73.70:10322...
* Connected to ext1.minehut.me (23.92.73.70) port 10322 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
} [5 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [15 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [879 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=TRAEFIK DEFAULT CERT
* start date: May 29 11:59:18 2024 GMT
* expire date: May 29 11:59:18 2025 GMT
* issuer: CN=TRAEFIK DEFAULT CERT
* SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: ext1.minehut.me:10322]
* h2h3 [user-agent: curl/7.87.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x177ca7a1fa0)
} [5 bytes data]
> GET / HTTP/2
> Host: ext1.minehut.me:10322
> user-agent: curl/7.87.0
> accept: */*
>
{ [5 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [122 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
} [5 bytes data]
< HTTP/2 404
< content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
< content-length: 19
< date: Wed, 29 May 2024 11:59:22 GMT
<
{ [5 bytes data]
100 19 100 19 0 0 42 0 --:--:-- --:--:-- --:--:-- 43
404 page not found
What solution do you suggest? The IP whitelist tends to be unreliable for me.
It's difficult to say - it seems that there is Cloudflare-proxy deployed in front of ext1.live.minehut.me before it reaches the Plan webserver. I'm not sure if it's a problem with minehut port allocation or if they're limiting HTTP traffic specifically
I would like to be able to..
I would like to be able to restrict access to my Plan panel without messing with HTTPS or SSL certificates. Plugins such as Dynmap have login systems that work without much setup. There should be a config section that allows server operators to set a password that is presented upon loading the web page. To improve on this, you could add a new file called
users.yml
in the config folder that allows for creating "accounts" with different usernames and passwords, along with configuring permissions for each "account".Is your feature request related to a problem? Please describe.
Players using server hosts are almost always not allowed to have admin access and resort to the IP system. This new login feature would allow for easier panel protection while avoiding complicated IP whitelists and HTTPS.