ntninja commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

… 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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

maghoff commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

jolhoeft commented 5 years ago

I've got some time to focus on this. Should I just draft an RFC and create a PR, or would it be better to post it here for discussion first? Also, is there a good example of a crates.io RFC to look at? There seem to be mostly language RFCs, which seem to be looking for somewhat different things than this would.

grawlinson commented 5 years ago

Looking at the RFC process, it may be more desirable to discuss it some more on this issue. Plus, this issue does have all the related links/issues/etc posted on it so far.

Would you say that "support for alternative OAuth providers" is a good starting point, @jolhoeft?

jolhoeft commented 5 years ago

Yes, maybe "Support Configurable OAuth providers". Sadly, login with OAuth is not particularly standardized, with most providers rolling their own identity schema. There is OpenIDConnect, which Google and I think PayPal support, but most others supply some custom defined Json blob. That said, I think we could manage to cover most providers with just configuration values, so providers could be enabled and disabled at startup or even while running.

Some question I need to go through the code to find out:

What information are we getting from Github? I just needed the provider's user id, email address, and display name, which have always been available with a single api call.
- Annoyingly, Google recently stopped providing the display name
What struct are we using for users and where are we storing it, presumably a database table?
- Can we extend the table for the OAuth, or is it better to add another table? I suspect the latter.
(Not the code) What providers are important to support?
- I initially supported five, and I fear I may have opened myself up for some operational headache, as they periodically change or break. Fewer may be less burden.

We are using diesel for persistence, conduit as a web framework, and a rather old version of oauth2. I may create a PR to upgrade oauth2 before I get too deep into this.

jolhoeft commented 5 years ago

BTW, how does crates.io interact with the private cargo repositories? That seems like that would impact this.

tarcieri commented 5 years ago

Also, is there a good example of a crates.io RFC to look at?

@jolhoeft one example is the RFC for signing registry index commits: https://github.com/rust-lang/rfcs/pull/2474

ghost commented 5 years ago

Waiting for GitLab login or email login!

ghost commented 4 years ago

Any Updates on this issue?

jolhoeft commented 4 years ago

I need a week free to code this up, but that doesn't look likely before late January. I stalled out on the RFC initially. I should probably have just create a pull request and let the discussion go from there.

ghost commented 4 years ago