Non-Github account creation

[alexander255]

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…

[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.

[alexander255]

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.

[alexander255]

… 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)

[alexander255]

@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.

[maghoff]

@grawlinson, did you get anywhere with this? :) Now that login (again?) is required for publishing, I think there's renewed interest in this. From the comment history it looks like you are working on it, but it's been a while since the last update. Can you confirm if you're still on the case? :)

[grawlinson]

I'm still interested in implementing this, but real life takes up all my free time at the moment.

I can probably spare a day or two per week, if anyone's willing to mentor/guide.

[tarcieri]

This really feels to me like something that should go through the RFC process. Identity and its relationship to access control are touchy topics, and ones which should, IMO, get proper design and security review before implementation work starts.

[grawlinson]

Agreed. I’ll start drafting and submit a RFC over at the rust-lang/rfcs repository.

…

On 31/03/2019, at 04:47, Tony Arcieri ***@***.***> wrote: This really feels to me like something that should go through the RFC process. Identity and its relationship to access control are touchy topics (and also an area of personal expertise for me), and ones which should, IMO, get proper design and security review before implementation work starts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jolhoeft]

Last month I added OAuth support for several providers to my nickel.rs based site (https://virtuarasa.com/), so a lot of these issues are fresh in my mind, although I've not yet looked at the crates.io code yet. @jtgeibel 's outline of the issues above maps to much of what I needed to deal with. If it won't step on anyone's toes, I'd like to take a swing at this. My oauth identity module may generalize for this application (if so I'll make a separate crate of it).

I would treat linking accounts, e.g. having a login with Google the same as a login with Github, as a completely separate issue after multiple providers are supported.

Is there a desire to support local accounts, i.e. users create a username and password on crates.io?

[carols10cents]

Is there a desire to support local accounts, i.e. users create a username and password on crates.io?

Not at this time, no.

[tarcieri]

@jolhoeft perhaps you could help @grawlinson work on an RFC?