Github has removed password authentication and now requires an access token

[jlgimeno]

Issue description

Beginning August 13, 2021, Github now requires an access token to access remote repositories. See link to docs here.

Language

Not currently related to any language

Operating system

This will apply to all OS's, as the issue is Github's.

[das-g]

see three possibilities:

1. Let participants set up an SSH key and use SSH for cloning and pushing (for only pulling, as we do on PythonAnywhere, it shouldn't matter if the repo is public)
2. Use personal access tokens
3. Use GitHub CLI for cloning and pushing

Are there any other options?

We'd want to select whatever is most simple (and doesn't make the tutorial much longer) while also being reasonably fool-proof. I'm unsure which option strikes the best balance for these criteria, though.

[DataCerealz]

I just did a remote event end of September. We went for access tokens. That's definitely the easiest way to go in my/our opinion. They can be easily created at the same time the PythonAnywhere Token gets created during the installation party.

I wouldn't use GitHub CLI. Reason: there are already a lot of new tools for participants. Don't make it even harder.

I also would highly favour AGAINST SSH. Reason: there are a lot of new concepts for participants. Like: what are servers? what is a terminal? Python, HTML, CSS, Django? What even is a Framework? What is Git? ... and so on. It's almost impossible to go through the entire tutorial on a single workshop day (ignoring the installation party here as there is no coding involved). Also implementing / Teaching SSH would just add another step of complexity and another new concept to be taught. And to be honest: I am a full time dev. Even a Tech Lead in my current Job. And I forget about SSH all the time. I use a tool to manage my keys as I constantly forget how it works or where they are on different operating systems so I just use a management tool. I think understanding and using and remembering this on top of all the other new stuff is just asking too much. There is a lot of "fuss" around the real Django development already; like hosting, git, a code editor, terminal commands, and so on. But the core of the tutorial is a working Django web app. To archive this in the really limited time of a full day for coding, I'd try to strap away as much as possible that's not strictly needed to achieve this goal.

[eshwaric]

I ran into this issue as well while going through the tutorial in preparation for the tutorial. I think creating personal access token is the easiet solution. However the only problem I had is typing the access token repeatedly as I could not get copy paste to work with pythonanywhere. A mention of this in the tutorial will help as it took me a while to figure out what was happening.

[nikhiljohn10]

I also would highly favour AGAINST SSH. Reason: there are a lot of new concepts for participants. Like: what are servers? what is a terminal? Python, HTML, CSS, Django? What even is a Framework? What is Git? ... and so on. It's almost impossible to go through the entire tutorial on a single workshop day (ignoring the installation party here as there is no coding involved). Also implementing / Teaching SSH would just add another step of complexity and another new concept to be taught. And to be honest: I am a full time dev. Even a Tech Lead in my current Job. And I forget about SSH all the time. I use a tool to manage my keys as I constantly forget how it works or where they are on different operating systems so I just use a management tool. I think understanding and using and remembering this on top of all the other new stuff is just asking too much. There is a lot of "fuss" around the real Django development already; like hosting, git, a code editor, terminal commands, and so on. But the core of the tutorial is a working Django web app. To archive this in the really limited time of a full day for coding, I'd try to strap away as much as possible that's not strictly needed to achieve this goal.

I understand the effort and commitment involved and I appreciate it. But I feel that the SSH keys have a big role in the creation of a multitude of open source projects, a new developer could do on Github. Creating and using a personal access token is easy in one day project. But I do know that using the access token could become hard to manage in the long run since you have to copy and paste it whenever you need to authenticate.

These 4 commands will generate and output your SSH Key. Copy paste it into Github settings:

ssh-keygen -t ed25519
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
cat ~/.ssh/id_ed25519.pub

They only need to set it up once in their system. If there are any plans to add Github authentication to the tutorial, it would be great to at least give SSH authentication as an optional for students to explore as an expandable block in the same section.

[nikhiljohn10]

@das-g I am encountering the same issue often, as the Github section does not mention anything about the configuration of Github. Should we add a small paragraph along with the above ssh-key generation code for copying and pasting for students? Maybe a link for them to explore further later.

[ekohl]

I also ran into this last week. However, it's still possible to push using a personal access token. Perhaps that's easier than dealing with SSH keys, especially considering the multiple platforms we support.

[nikhiljohn10]

@ekohl Either way, there is a missing link in the tutorial. It is the GitHub authentication. If someone does the tutorial alone, they would be confused at this point. How about a hidden page in Github section that will only expand down on clicking on it? So it would not interfere with the normal flow of the tutorial.

[das-g]

We definitely have to cover some way for dealing with this in the tutorial.

While I'm personally more familiar with SSH keys, several here have expressed that they deem access tokens to be the more OS-independent and/or easier-to-convey option.

[nikhiljohn10]

How about this? Both are collapsed by default. Expanded for taking screenshots. I am curious to know how someone doing the tutorial for the first time would feel about this page given below.

[das-g]

Giving instructions for both solutions (and using collapsible sections for them) seems like a good idea to me. However, I think we need a sentence or two before the collapsible sections to tell the reader what to do with them.

Since now we have these collapsible sections for different operating systems. Readers will usually know or be able to find out (maybe with some help) what operating system they are using, and thus, which section to read.

Here though, they have to make a choice, unless they're participating in a workshop that does make the choice for them, which some Django Girls workshops might, or where they can ask their mentors for advice.

For those on their own, we need to at least:

• mention that they have to choose between these two options and follow the according instructions
• help them make the choice
  • This can be in the form of a (maybe even arbitrary arbitrary) recommendation like "If in doubt, use the Access Token method."
  • We could also recommend Access Token for Windows and SSH for MacOS and Linux

Using the SSH method on Windows should be possible, too, as all the required software is AFAIK installed with the Windows Git installation by default and accessible through Git-Bash. However, the tutorial currently has Windows users use CMD as their CLI shell for the tutorial, not the Git-Bash.

[thibaudcolas]

Interestingly we almost didn’t run into this the last time I coached because lots of people were using RunCode connected with their GitHub account, which proposes a more streamlined flow (though with lots of steps). I thought I’d share the steps here for future reference. I don’t know how this all works for RunCode users signing up with something else than GitHub.

Upon using git push, we get three prompts in succession within VS Code within RunCode:

1. "The extension 'GitHub' wants to sign in using GitHub" Cancel | Allow
2. "Your Code: 3AFD-E323", "To finish authenticating, navigate to GitHub and paste in the above one-time code." Cancel | Copy & Continue to GitHub
3. "Do you want RunCode Server to open the external website? https://github.com/login/device" Configure Trusted Domains | Copy | Cancel | Open

Now a new browser tab opens to https://github.com/login/device, and there are three more steps:

1. "Device Activation – Enter the code displayed on your device". With an input field for the code, and then "Continue"
2. "Authorize GitHub for VS Code" – that’s a GitHub OAuth authorization prompt. There is a warning at the top "A This authorization was requested from Falkenstein 142.132.142.58", presumably because the device triggering the request and the user’s browser are detected in different places.
3. Upon authorizing, a success step "Congratulations, you’re all set"

[nikhiljohn10]

What about CodeSpaces from Github itself over RunCode.io? It need zero effort to start coding and committing changes compared to AccessCode or SSH or RunCode.io.

Clone or create repo. Press period/dot key to start coding.

This is only a suggestion. I want to know if it make the tutorial much more simpler and easy for students. Any thoughts on this?