Non-Github account creation

[ntninja]

http://doc.crates.io/crates-io.html says:

Acquiring an API token

First thing’s first, you’ll need an account on crates.io to acquire an API token. To do so, visit the home page and log in via a GitHub account (required for now).

Any plans to change this? Not publishing on crates.io meanwhile…

---

Current status

The team consensus is summarized in this comment:

Yes there's no particular reason that we don't have anything other than GitHub yet beyond that no one's actually implemented it. It was always the intent to have a variety of login options, and then you could link multiple login varieties to the same account (e.g. you can log in via oauth from either Twitter or GitHub)

That is, we are in favor of adding additional login methods, and we do not need any further discussion or 👍🏻 s on this issue so it is locked.

But there are a number of hurdles to get there:

• crates.io usernames currently match the GitHub usernames, so if we allow a different provider we will need a way to avoid conflicts
• the current system for assigning teams as crate owners is unfortunately directly tied to GitHub teams
• from what I was told, GitHub is somewhat good at preventing spam accounts and other malicious activity, which we can't handle ourselves with the existing resources of the project
• the code and database are quite tied to the assumption that GitHub is the only login (the users table has column gh_login and gh_id for example), so significant refactorings need to take place to enable adding other services

The way forward is to find solutions for all of these, writing RFCs as neccessary to propose these solutions, then implementing the necessary changes.

If you are interested in helping with this work, please feel free to get started!

[steveklabnik]

I don't know of anyone working on additional logins.

Given that you already have a github account, what specifically is the issue? I can think of a few, I'm interested in yours, specifically.

[ntninja]

Particularly my problem is that I don't have crates.io account and that I don't think GitHub has, or should have, anything to do with publishing Rust crates. How is there any (not artificially induced) overlap between what crates.io does and what GitHub does?
There is practicality none, except for the fact that crates.io developers seem to really have taken a liking in using GitHub for everything and one thing more. Using GitHub as public git file storage is similar to this, but in a much less worrying way: GitHub remains a strictly swappable component. Don't like GitHub anymore one day? Just adapt @bors to something else and within a day or two you're done migrating. Also that's something that can easily done by a core developer; switching the user backend? Not so much…

@steveklabnik Is there any benefit to using GitHub Account API, aside from the fact that it happened to be the first user database that attracted some developer's eye?

[steveklabnik]

except for the fact that crates.io developers seem to really have taken a liking in using GitHub for everything and one thing more

The only things dealing with github are the index, which is a plain git repository, and therefore easy to swap, and the login system, which is the usual oauth based thing. Publishing crates, other than oauth being the only way to get a crates.io account at the moment, has nothing to do with github.

The reasons for choosing GitHub for logins was the same as any site that enables OAuth: new users don't have to trust us with storing passwords, nor making Yet Another Account on another website. There's no inherent reason that it has to stay GitHub only, other than nobody has bothered to actually implement it.

[ntninja]

… except that crates.io really isn't a lot more than an index with per-login management.
But we're actually not disagreeing on anything, so let's not argue over what each of us considers a lot in this context.

Since you seem to not be not very fond of the idea of "normal" logins (correct me if I'm wrong). Have you considered an OpenID login option instead?

[steveklabnik]

Well, there's also the hosting of all of the crates' source code, permissions around who and what is exactly allowed to publish, validating that Cargo.toml is filled out correctly......

I'm not opposed to a 'normal' login. I wouldn't be particularly pro-OpenID though, personally. But it's @alexcrichton 's opinion that matters most.

[alexcrichton]

Yes there's no particular reason that we don't have anything other than GitHub yet beyond that no one's actually implemented it. It was always the intent to have a variety of login options, and then you could link multiple login varieties to the same account (e.g. you can log in via oauth from either Twitter or GitHub)

[ntninja]

@alexcrichton: So if I were to come along with an OpenID Auth implementation you'd probably merge it (aside from the usual getting-to-know-the-codebase-mistakes of course)?
Could you give me some pointers to were it'd be a good idea to implement this in the current codebase?

[alexcrichton]

@Alexander255 certainly! Github authorization is currently handled around here, and I suspect that something like OpenID would be similar and we'd just want a landing page to pick which one you want ahead of time (instead of always going to github first)

[grawlinson]

So what's actually required to implement alternative logins? Just hooking into Gitlab's OAuth provider?

Would anyone be willing to mentor me if I choose to work on this?

[jtgeibel]

@grawlinson here are some of the places we have code that interacts with GitHub:

• src/app.rs - configuration of the OAuth client
• src/controllers/user/session.rs - endpoints so that the frontend can obtain the authorization URL to open in a popup, and to verify the code provided by the completed authorization
• src/github.rs - interaction with the GitHub API, mainly for determining team membership
• src/models/team.rs - If the login contains a ":" it is a GitHub team. (A team member can publish and yank owned crates, but cannot add/remove other owners.)
• src/models/owner.rs - If the owner is not a team, then they have full access to the crate.
• src/models/user.rs - The user model includes fields such as: gh_id, gh_login, gh_avatar, gh_access_token

There are several tricky things to keep in mind. It's been a while since I've looked at the details, but there is logic to handle renamed users and teams. If I recall correctly, we use the gh_id field for users and update the gh_login if the user has renamed themselves on GitHub. Teams are handled differently, so that if a team is deleted and a new one with the same name is added, then we pick up the new ID number for the team. I expect that there would be similar issues when dealing with GitLab users and groups and that we would want to extract this somehow to be as generic as possible.

In addition to the backend work, there would also need to be a frontend interface to select the appropriate login provider.

Since this looks like a fairly large amount of work, I think we would want to split this up into multiple PRs, incrementally adding functionality and enabling the frontend interface in the last one. A good place to start might be to see if there is a reasonable way to extract the GitHub specific fields from the user/owner/team models to abstract over multiple OAuth providers.

[grawlinson]

OK, I'll have a look at the models and get started on a PR.