Failed to log in

[bluesquall]

Describe the bug The old approach with the login credentials in a volume worked for me. Ever since the container switched to using environment variables for the username and password, it fails to log in initially. (The Zwift UI says to "Check internet connection.")

If I manually type the password, it logs in just fine.

To Reproduce

• Install zwift.sh and pull the latest image.
• Put ZWIFT_USERNAME & ZWIFT_PASSWORD in $HOME/.config/zwift/config
• Run zwift.sh

Expected behavior Container logs into Zwift with the provided credentials.

Screenshots If applicable, add screenshots to help explain your problem.

Additional context I have zwift.sh installed to $HOME/.local/bin instead of /usr/local/bin.

I’ve tried enclosing the password in double quotes, with no apparent change in behavior.

The username (email) field does get populated correctly.

Attaching to the running container and executing printenv shows the correct password. (I’ve literally copy-pasted from the environment variable in the terminal to the Zwift login screen to confirm.)

I can't tell whether this is an issue with the way the container is loading the credentials, or an issue with the order of operations — perhaps the network interface is taking an extra moment to spin up?

[netbrain]

Could you try to run host networking?

[bluesquall]

Here's another clue:

When I attach to the container after it has failed to log in, and try to run zwift-auth manually, that script errors out with the message:

grep: cookie.jar: No such file or directory

Adding double quotes around the URL assigned to ZWIFT_REALM_URL on line 8, and changing the path for COOKIE to "/tmp/zwift-cookie.jar" gets a bit further:

{"error":"invalid grant","error_description":"Code not valid"}

[bluesquall]

Could you try to run host networking?

Tried adding NETWORKING=host to $HOME/.config/zwift/config with no apparent change in behavior — it still "Failed to log in."

I was able to confirm this results in a different condition for the container. Without NETWORKING=host podman ps --format json shows a block with "Networks": ["podman"],, and with NETWORKING=host the block is just "Networks": [], with no internal bridge.

I'll try to make more time for tinkering & debugging on a different machine tomorrow or Friday.

[sHedC]

does it tries to login, then Fail?

Do you have any special characters in your password or spaces? It is possible or that you have some special hidden characters, how did you create the file?

[netbrain]

Could simply try to change pwd to something simple just to see if it's an issue with special characters...

But now that I mention it, I think your said you tried to copy paste the password evaluated from the Zwift auth script and this worked. Am I right?

[sHedC]

Actually it seems to pass eactly as you put in the ZWIFT_PASSWORD so $pass goes as $pass and 'pass' goes as 'pass' make sure there are no extra characters.

[sHedC]

@bluesquall - did you check any special characters or did you put the ZWIFT_PASSWORD in quotes? are there quotes in your password or back slashes?

[bluesquall]

Busy week/end. I’m aiming for time to Zwift later today, and will try to troubleshoot this a bit more.

• The only characters in my present password are hyphens, numbers, and letters.
• The screenshot @sHedC posted is representative of the result, just with my username instead. I’ll try to test on a different machine that is easier to screenshot today.
• I wrote $HOME/.config/zwift/config using vim.
• Like I mentioned in the original ticket, I’ve tried with and without double quotes surrounding the password.

I will try single quotes today. I’ve also tried with & without double quotes on the username, and that seems to get populated the same either way. That seems a bit different from what @sHedC observed with the password.

For the sake of completeness, here are sections from two versions of $HOME/.config/zwift/config, both of which have the same character classes as my password, and neither of which worked:

ZWIFT_USER=name@eg.com
ZWIFT_PASSWORD=Pass-Word-123

ZWIFT_USER="name@eg.com"
ZWIFT_PASSWORD="Pass-Word-123"

• I’ll try single quotes with my existing password first, then
• I’ll try removing the hyphens from my password.

[sHedC]

Don't use quotes it actually translates to quotes when trying to authenticate. So you are correct should be Pass-Word-123 without any quotes.

I have a password that is numbers/ letters and underscores works fine. I used nano, going to try vim.

[sHedC]

Ok just tried failed, I had a space at the end of the line. I removed that it worked, maybe that?

[sHedC]

I notice that with nano I move the cursor to the end of the line and the cursor is after the last character so if i have

password the cursor blinks after the d password the extra space the cursor blinks after the space

with vim the cursor is on the d when no space and after the d with the space.

[bluesquall]

I usually have vim set to remove trailing spaces, but I’ll double-check on that machine.

On Wed, May 29, 2024, at 12:03, Richard Holmes wrote:

I notice that with nano I move the cursor to the end of the line and the cursor is after the last character so if i have

password the cursor blinks after the d password the extra space the cursor blinks after the space

with vim the cursor is on the d when no space and after the d with the space.

— Reply to this email directly, view it on GitHub https://github.com/netbrain/zwift/issues/139#issuecomment-2138077872, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5PZXY422DRPY7HGIYOTTZEYRBTAVCNFSM6AAAAABIEMIVKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZYGA3TOOBXGI. You are receiving this because you were mentioned.Message ID: @.***>

[bluesquall]

Tried to fix the formatting in the comment I sent via email reply, but apparently GitHub won't reprocess that as markdown. Oh well.

[bluesquall]

Troubleshooting from my other machine didn't work because the version of podman on there is too old (3.4.4 in Pop!OS 22.04) and does not support --userns keep-id:uid=$ZWIFT_UID,gid=$ZWIFT_GID. It seems like there might be a workaround using --uidmap and --gidmap but I'm not sure you would be interested in maintaining a special condition just to support old versions of podman.

[bluesquall]

Went back to the original machine to confirm that there was no trailing space after the password, and there was not.

But I did still have double quotes around my email (in the ZWIFT_USERNAME variable). Removing them let the authorization succeed.

I really thought I had tested removing double quotes from both fields, so I'm sorry for this goose chase.

The red herring is that the username field on the Zwift login screen still gets populated correctly -- without the double quotes -- even if the field in $HOME/.config/zwift/config has the double quotes. I'm not sure where they would get stripped, but apparently they do.

Some of the confusion comes from the subtle difference in how bash and podman ... --env-file=... treat assignment.

To illustrate:

• put the variable in a new file with echo 'ZWIFT_USERNAME="name@eg.com"' > ./test-env
• source ./test-env; printenv | grep ZWIFT yields nothing[^a]
  • Actually, I should have tested this with[^b]:
  • source ./test-env; set | grep ZWIFT, which yields ZWIFT_USERNAME=name@eg.com, or simply
  • source ./test-env; echo "ZWIFT_USERNAME=$ZWIFT_USERNAME", which also yields ZWIFT_USERNAME=name@eg.com,
  • Sorry for my confusion, I'm used to having everything in printenv
• export ZWIFT_USERNAME="name@eg.com"; printenv | grep ZWIFT yields name@eg.com without the double-quotes
• podman run --rm --env-file=./test-env docker.io/debian:stable-slim /bin/bash -c "printenv | grep ZWIFT" yields ZWIFT_USERNAME="name@eg.com" with the double-quotes

I do think the current README is clear, and adding the double-quotes was something I automatically did for some habitual reason. And perhaps it's worth adding a sentence or a footnote to the README in case anyone else does the same thing.

In any case, thanks for all your help.

---

[^a]: I'm actually a bit confused why you source $HOME/.config/zwift/config at line 62 & line 69, since the variables within shouldn't be available without using export unless you've put set -a or set -o allexport somewhere I can't find. [^b]: Apparently those variables are still available in the script or the current shell session, but just not in the actual environment.

[sHedC]

her machine didn't work because the version of podman on there is too old (3.4.4 in Pop!OS 22.04) and does not support

I can put a note in the README about older versions. I was looking at an OS for a gaming build and Pop OS seems to be getting really out date. Not sure about older versions then as Ubuntu 22.04 is still supported willl think about it.

[sHedC]

I do think the current README is clear, and adding the double-quotes was something I automatically did for some habitual reason. And perhaps it's worth adding a sentence or a footnote to the README in case anyone else does the same thing.

Noted I will update the readme in my current PR.

I'm actually a bit confused why you source $HOME/.config/zwift/config at line 62 & line 69, since the variables within shouldn't be available without using export unless you've put set -a or set -o allexport somewhere I can't find. ↩

Apparently those variables are still available in the script or the current shell session, but just not in the actual environment. ↩

This is purely used as you can put startup environment variables in the config file I have WINE_EXPERIMENTAL_WAYLAND=Y it is used only in the script and works in both docker/ podman. The AUTH script re-reads the config file to get the User/ Password.

[sHedC]

Added issue #143 to look into this.

[bluesquall]

her machine didn't work because the version of podman on there is too old (3.4.4 in Pop!OS 22.04) and does not support

I can put a note in the README about older versions. I was looking at an OS for a gaming build and Pop OS seems to be getting really out date. Not sure about older versions then as Ubuntu 22.04 is still supported willl think about it.

I switched to Pop!OS on this machine because it let me avoid snaps but still have most of Ubuntu for a dev machine on projects where everyone expects you to have Ubuntu. It seems like they keep some packages more up-to-date than Ubuntu, but others just stay even with the base LTS. This is the first problem I’ve really run into with it.

The machine I mostly run Zwift on uses SteamOS, based on Arch, and everything seems pretty solid.