In general you have two solutions for 2FA with iTunes Connect TestFlight:
Create a CI/bot/âmachineâ user on iTunes Connect which does not have 2FA enabled, and will only be used for automations, e.g. to use it on bitrise.io. This is probably the easiest solution, as once you create the user itâll just work, no future changes are required. Simply just register a new iTunes Connect account, just like a regular account, the way you registered your own iTC account, and simply never use it for development / login, only for integrations.
Follow the official instructions (if any) of the tool you use to do the deploy.
In this case specifically / what the reported issue might be
Now, the guide here states that you can run a command locally, and you should provide the output of the command as an environment variable. For environment variables you can use App Env Vars and Secret Env Vars - from the screenshot it seems you used Secret Env Vars. Thatâs OK, but as you can see in the orange notice Secret Env Vars are not available in pull request builds. This is one thing what might cause the issue for you.
Another thing is, on the screenshot you did set FASTLANE_SESSION as mentioned in the guide, but you should also make sure to turn off the Replace variables in input? option of that env var, so that Bitrise (CLI) wonât treat the $ characters in the value as env var references.
Last but not least, and Iâd say in your case this is the most likely cause, you should replace the \n characters in the value printed by fastlane spaceauth, because if you do provide \n there, it will be encoded properly to represent the \and the n characters, while what you can see in the fastlane docs is for bash, where \n means newline. To do this simply replace all the \n with an actual newline (hit enter/return) in the env var value on bitrise.io. That will be the same as if youâd print \n in bash / the way the fastlane docs expose the env var.
Iâm running in circles and canât quite figure out the reason. I read like half a github about it, and in the end i figured out that it is somehow related to the Bitrise and how it interprets the cookie itself rather than a problem with Fastlane
Bitrise does not interpret anything in the env vars, except the $ANOTHER_ENV_VAR references if thereâs any and the âexpandâ option is enabled. Other than that itâs just an env var, like any other.
ok, well thanks for help anyway. this Bitrise CLI will be a big help for me for future anyway (cause pushing always to git repo is quite a pain if i do some changes locally to the pipeline or code).
If i wonât figure out the problem (maybe i screwed up the logging in in spaceauth) then I will ask guys on fastlane what might be the reason.
Sure, and if we can help with anything please let us know!
Iâd also advise you to try to generate & set the value again - a quick tip: if you set the value directly in bitrise.yml mode then you donât have to modify it, \n should remain \n, you only have to replace \n if you input the value on the Web UI / in the Editor. Simply just generate a new value and replace the value in bitrise.yml with the new one basically:
- opts:
is_expand: false
FASTLANE_SESSION: "PASTE THE VALUE HERE"
Setting it through the web ui should work as well of course, but in that case youâll have to replace the \n chars with actual newlines, which will be serialized as \n when written into YML.
I tried to generate new one and right now I get the message
"Two Factor Authentication for account âxxx@xxx.comâ is enabled
Your session cookie has been expired.
Please enter the 6 digit code: "
Which is 100% fastlane related. Though sadly no idea how to solve that one, but now Iâm a one step closer.
We just discovered one more edge case when 2FA / the Fastlane Session wonât work: our servers are running in US and it seems that the (fastlane / apple) session is location aware. This means that it might not work if youâre not in the same âregionâ as where itâs used. It should work if youâre in the US where our runners are, but otherwise if you generate a session on your Mac it might not work on our US build machines.
Did you try the things mentioned before in this thread?
If you did, Iâd suggest you to contact the fastlane guys as our step just runs the relevant fastlane tool - you can see the exact command the step runs in the stepâs log.