Control on creating repositories through invite links

[santina]

When an owner of a classroom creates an assignment, a common invitation link is created for that assignment. This link can then be manually sent to the students and through which they create their personal repository within the organization by logging into their GitHub account and simultaneously join the organization.

One possible issue with this set-up is that an unwanted outsider can somehow obtain the link and join the organization by going through the link. There is no control on who is actually a student that belongs to the class. The only requirement is having this one common link. This person would then have at least have the same access privileges as all other default members.

This could be problematic for classes with many students (burden on the admins to check regularly to remove unwanted members) and organizations with very limited number of private repos available with their plan.

It'd be nice if invitation links could be unique to each student or that there is some kind of passcode for students to join an organization through Github Classroom.

(described earlier here)

[tarebyte]

@santina thank you for the feedback!

One possible issue with this set-up is that an unwanted outsider can somehow obtain the link and join the organization by going through the link.

Just out of curiosity have you seen this happen / has this happened to you?

It'd be nice if invitation links could be unique to each student

The only problem with this is that there are some classes where there are more than 100 students and that can get tedious.

or that there is some kind of passcode

I think that is an interesting solution, which wouldn't be too hard to implement.

@johndbritton what are your thoughts on this?

[santina]

(^ Sorry I accidentally closed the issue when commenting)
Hi @tarebyte, no that hasn't happened to me. It's just a scenario that I thought could happen.

[johndbritton]

One possible issue with this set-up is that an unwanted outsider can somehow obtain the link and join the organization by going through the link.

I agree that this is an unwanted consequence of using a single link, but it's a trade-off we made in the interest of simplicity.

no that hasn't happened to me. It's just a scenario that I thought could happen.

If it starts to happen to people enough that they complain about it, we can come up with a solution but for now I think we'll stick to using a single link.

or that there is some kind of passcode

How would you distribute the passcode to students without having the same issue with sharing the private link?

Some possible solutions and related pitfalls

• Unique link per student - hard to distribute links
• Passcode - distributing passcode
• Require approval on first assignment submission - extra work for the teacher
• Create an acceptable list of users - hard to gather usernames at the beginning of class

[santina]

Hi @johndbritton, thanks for the detailed response. I definitely appreciate the interest of simplicity. Each of the suggestions that have been made in this thread has a pitfall.

A new idea: what about having a feature of disabling/enabling the link? Right now once the link is created, it freely floats out there for an indefinite length of time. If someone get the link, they can create a repo and join the organization. Paid users with limited number of private repos certainly wouldn't want that loophole. The only way to get rid of the link seems to be deleting the assignmnent, which would delete all the associated repos all together (is that right?).

That way, teacher can have a sign up period for each assignment. That's also an added bonus of enforcing assignment deadlines.

What are your thoughts on this?

[johndbritton]

what about having a feature of disabling/enabling the link?

That sounds like a reasonable idea to me. Maybe we can combine that with the due date feature to close the invitation link on the due date. Would that make sense to you @santina?

[santina]

Yes that makes sense 😄

[santina]

Hi @johndbritton, just wondering if there's any update on this issue. Thanks :)

[johndbritton]

We don't have a plan to implement this feature right now, but it's good feedback.

Since this hasn't really been a big issue for people, we'll probably leave it out for now but will keep the idea in mind for when we work on due dates.

[hackerkid]

@tarebyte @johndbritton Since GitHub allows multiple email accounts to be linked to a single account, why not verify the student identity by checking whether the account has at least one University email id? We can ask them to add the University id to GitHub to access the assignment in case they have not linked the id. The instructor can provide the University email domain while creating the assignment.

[johndbritton]

why not verify the student identity by checking whether the account has at least one University email id?

I think that's too much complexity for this tool. If we hear that this is a serious problem for folks I think we can implement a simpler solution.

[hackerkid]

I think that's too much complexity for this tool.

Sure. It is sounds a bit complex. How about this?

• Student (who does not have the University id linked to GH) try to access the assignment
• We show a message that you need to have example-university.edu email id linked to your GH account.
• Ask the candidate whether he like to add the email id now.
• If yes, we show up a text box to enter his example-university.edu email id
• Once the student submit the email, the GH email verification mail is being send (I hope POST /user/emails does that Job)

If we hear that this is a serious problem for folks I think we can implement a simpler solution.

Is it possible to have a solution without the University mail verification?

[johndbritton]

Is it possible to have a solution without the University mail verification?

One suggestion has been to have a code that the students have to type in to accept the assignment.

[jayvdb]

I invite my students to the org as either part of a team with low privileges, or as outside collaborators.
It would be nice to restrict assignments to only be used by someone affiliated with the org.

It will be possible to automatically set an invitation used-by date, when there is a deadline for the assignment (#379).
Obviously it doesnt make sense to allow people to create assignments after the due date.

[csorbakristof]

I everyone! This week some of my students created repositories with names causing github to immediately (automatically) flag the organization and disable all the repositories (due to offending names). This happened 2 times. At the third, I managed to avoid this by immediately deleting the repository and disabling the authentication token of classroom (as the assignment cannot be suspended). I suggest a different approach to the above issue:

Adding an optional "awaiting teacher approval to create the repository" round to the student workflow, the teacher could block any unwanted registrations (and unwanted repository names). (The teacher could already see the student and repository name, so they will be able to decide the identity of the student.)

[mine-cetinkaya-rundel]

I agree with @jayvdb's point above -- I would also like to restrict assignments to only be used by someone affiliated with the org. Some of the comments above suggest that this functionality could be prioritized if enough people experience outsiders creating repositories. I haven't had this problem yet, because I don't post my assignment links publicly, specifically to avoid this issue. So I wonder if the lack of reports on this is because faculty has been circumventing the issue in other ways (that add logistical hurdle to their courses).

[csorbakristof]

Hi everyone! Is this issue still in the deep waiting list? In autumn, we plan to start using classroom with some 200+ student courses (or even an 800+ undergraduate course), but I am afraid to do so if my approval is not required for creating a repository and assign students. As mentioned before, with an offending repository name, a student can get the whole organization automatically locked out, which seems to be too risky.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.