Unable to login

[huston9]

I have started a Docker convertx instance using Docker Compose. Initially, the only change I made was swapping "3000:3000" to "3001:3000" since another container already uses the 3000 port in my setup. I have been able to access the setup page and login page, but when I enter my credentials into the login page, it simply returns me to the login page to reenter my credentials. I am unable to reach the main conversion page. Any help would be much appreciated!

[huston9]

I have tried accessing both by my local network and remotely via Tailscale. Neither case has worked for me so far.

[ztgibby]

Seconding this issue, setup is similar to yours but I left all default configs.

[C4illin]

Set HTTP_ALLOWED=true

[huston9]

I did that - I also set ACCOUNT_REGISTRATION=true, but no luck yet. Am I supposed to be doing anything with the JWT_SECRET variable?

Thanks for the advice btw; this seems like a cool tool and I'd love to get it working on my machine!

On Thu, May 1, 2025 at 12:38 PM Emrik Östling @.***> wrote:

C4illin left a comment (C4illin/ConvertX#272) https://github.com/C4illin/ConvertX/issues/272#issuecomment-2845210571

Set HTTP_ALLOWED=true

— Reply to this email directly, view it on GitHub https://github.com/C4illin/ConvertX/issues/272#issuecomment-2845210571, or unsubscribe https://github.com/notifications/unsubscribe-auth/AETXLTLG54NXCZPA2WXUCQL24JEWZAVCNFSM6AAAAAB4H725KKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBVGIYTANJXGE . You are receiving this because you authored the thread.Message ID: @.***>

[tremor021]

export HTTP_ALLOWED=true fixes it

[huston9]

export HTTP_ALLOWED=true fixes it

As in enter that line into my environmental variables? I'm new-ish to Docker, and am unfamiliar with how to use export in a compose file.

[tremor021]

Yes as environment variable

[huston9]

Tried that, but it didn't work.

Here is the environmental variables section of my docker-compose.yml:

environment:  
      - JWT_SECRET=password # will use randomUUID() if unset  
      - ACCOUNT_REGISTRATION=true  
      - export HTTP_ALLOWED=true

I don't know if this makes a difference in terms of finding a solution, but out of curiosity, I intentionally misentered my password. The "login" button sent me to a bare webpage that simply said {"message":"Invalid credentials."}. When I correctly enter my password, the "login" button simply refreshes the login page.

[tremor021]

no, export is someting you would type in the shell. Remove export from the compose file, leave just HTTP_ALLOWED=true

[huston9]

Ok, so taking export out, I then call sudo docker compose restart; do I then do sudo docker <container> attach and run export from there?

[C4illin]

Ok, so taking export out, I then call sudo docker compose restart; do I then do sudo docker <container> attach and run export from there?

Setting it as an environment should be enough

[huston9]

That didn't work... Also, what would the point of using export be? I'm not sure where it would come in if I don't use it in either the compose file or the console? Still having the same problem; can we reopen the issue, @C4illin? Thanks!

[C4illin]

export is used in bash and similar to set env variables which can also be set in docker compose. I think you are doing something weird with your docker compose. Set the env variable in the compose file and then attach and check what it actually is (using echo for example)

[huston9]

Ok, you're right - despite the environment section of my compose file being this (as above)

environment:  
      - JWT_SECRET=password # will use randomUUID() if unset  
      - ACCOUNT_REGISTRATION=true  
      - export HTTP_ALLOWED=true

...when I run sudo docker exec convertx env in my CLI, I don't see env variables show up for ACCOUNT_REGISTRATION nor HTTP_ALLOWED. I do see JWT_SECRET=password, though. I'm not sure why that shows up but the other two don't.

I thought maybe I had goofed the way I ended that first line (the JWT_SECRET line), causing the next two lines to not be read right, but when I switched the order so that the JWT_SECRET line was last, I still only saw JWT_SECRET in the environmental variables. I'm not sure what's going wrong at this point.

I've tried setting the environmental variables in a .env file and referencing it in the compose file with env_file:, but no dice there either.

I'm at a loss at the moment as to what else could be causing this problem. Any other thoughts? All and any help is much appreciated!

[tremor021]

we told you to remove "export" from environment variables

[huston9]

Oh, I did - I just copied the lines from my previous comment, and forgot I had export in there.

This is what I have:

environment:  
      - JWT_SECRET=password # will use randomUUID() if unset  
      - ACCOUNT_REGISTRATION=true  
      - HTTP_ALLOWED=true

[benwilcock]

I think I may have a suggestion here.

HTTP_ALLOWED=true only works for localhost serving. When self hosting (e.g. on Docker on a NAS etc.), it's quite often the case that you would want any machine on the local LAN network at be able to access and use the service, but when set to localhost, only the users of the actual server are able to access the service. Therefore, if your server for your LAN is on http://192.168.1.5:3001, and you called the service from a browser on 192.168.1.10, then you would be unable to login.

I'd argue this is a bug or a feature request - to allow HTTP on the local LAN. Is that possible already?

[huston9]

HTTP_ALLOWED=true only works for localhost serving.

Ahhhh, that makes sense then. Yep, I'm trying to access the service from other machines on my LAN and Tailscale network. The server itself is headless, so being able to access it only with localhost isn't very helpful for me.

Thanks @benwilcock for the added info!

@C4illin, thoughts regarding the comment above?

[tdigu]

I think I may have a suggestion here.

HTTP_ALLOWED=true only works for localhost serving. When self hosting (e.g. on Docker on a NAS etc.), it's quite often the case that you would want any machine on the local LAN network at be able to access and use the service, but when set to localhost, only the users of the actual server are able to access the service. Therefore, if your server for your LAN is on http://192.168.1.5:3001, and you called the service from a browser on 192.168.1.10, then you would be unable to login.

I'd argue this is a bug or a feature request - to allow HTTP on the local LAN. Is that possible already?

Curious on this, i believe this is my situation as well. I am trying to run convertx on a rpi4 in docker and access it from a different computer. Is there currently a resolution to this? It allows me to create an account but i then can not log in. I tried with https as well but i get a ssl error attempting that.

[huston9]

Yeah @tdigu, exactly the same here, just different hardware. Haven't found a resolution yet, but I remain optimistic. Looks like @C4illin just added a bug ticket two days ago, so hopefully we'll be able to figure out what's up soon.

[C4illin]

I tested it here and if I add HTTP_ALLOWED=true I am able to log in on another device on the local network

Maybe try to clear cookies?

[C4illin]

HTTP_ALLOWED=true only works for localhost serving.

@benwilcock no, on localhost HTTP_ALLOWED=false even works

[benwilcock]

HTTP_ALLOWED=true only works for localhost serving.

@benwilcock no, on localhost HTTP_ALLOWED=false even works

We might be talking at cross purposes. The point though, is that to work on headless systems on LAN, there's an issue with the login flow and using http mode. Should be reproducible.

[C4illin]

Should be reproducible.

I tried the following on my headless system (not a raspberry pi though):

docker run -p 3003:3000 -v ./data:/app/data -e HTTP_ALLOWED=true ghcr.io/c4illin/convertx

then i visited http://192.168.1.4:3003 and create an account and was able to use it as normally

so I cant reproduce the issue

[samudotlol]

Hiya, had this issue and HTTP_ALLOWED=true does work, but not sure how good of a solution it is, as I want to make the service available thru cloudflare, and will have to use https at that point

[C4illin]

Yeah the idea is that you use https and don't change the variable (HTTP_ALLOWED=False)

[orrd]

I spent a lot of time trying to figure out why the login wouldn't work before I happened to find this issue. I did eventually also see it in a note on the install page, but most of us don't read all the instructions thoroughly when this is one of several projects we're installing and just trying to get it done.

I don't know why HTTP is not allowed by default, but if it's going to remain not allowed by default, HTTP_ALLOWED=true (or false) should at least be in the sample docker-compose.yml. And also the login page should really give an error message that explains what's going on.

[wrapperNo1]

Hi, I had the same issue in a fresh installation. HTTP_ALLOWED=true did fix it.

[huston9]

Not sure what happened, but when I wiped and reinstalled the container via Docker Compose, suddenly it started working. I'm now able to connect over HTTP via Tailscale, and just ran my first conversion as a test. Everything seems to be in order now, but not sure why it suddenly decided to start working.

[NibeluR]

I've randomly encountered similar issue too. Convertx logged me out and I couldn't enter with my correct credentials. No error message as well. HTTP is set to=True. No errors in logs or devtools. I tried to connect to the page with other browser/private window and it worked. I rarely use ConvertX but for some reason it managed to broke. I cleared Browser cookies and everything works as usual now 🤔🤔