Skip to content
This repository

Improve user signup etc #1029

Open
igfoo opened this Issue September 07, 2012 · 18 comments

6 participants

igfoo Erik Hesselink Ben Millwood Matthew Gruen Leon P Smith Duncan Coutts
igfoo
Owner

User signup should ask for username, password, e-mail address, and perhaps optionally other information (e.g. name etc).

It should then send a confirmation mail to the e-mail address, which includes a URL. The URL must be visited to activate the account.

Similarly, there should be an 'I forgot my password' button which also sends a mail containing a URL. That URL will include a 'reset my password' button, which sets the password to a random string and shows and/or e-mails that password to the user.

As well as requiring e-mail confirmation, accounts must also be confirmed by an admin before they can upload. There should be a page listing the outstanding requests, with 'accept' and 'reject' buttons (and perhaps 'drop' too, for silent rejects?). Admins should be mailed either when a new request is made, once a day if there are outstanding requests, or both.

Erik Hesselink

I think the usual flow for password resets is for the page to allow users to enter a new password, not show them an autogenerated one. Passwords should never be sent by email.

Ben Millwood

Well, you've got to send some authentication token by e-mail, but I'd agree that it probably helps if it's a temporary one.

Matthew Gruen

This sounds like a good story for new accounts for the main Hackage server. What about legacy-imported accounts and minimal (private) Hackage servers?

Erik Hesselink

@gracenotes A private hackage could use the same mechanism and add everyone to the 'trustees' or 'admins' group. That gives them permissions to do pretty much everything. This is what we do, and it's hardly any work.

Leon P Smith

If we import the old accounts, I don't think this needs to be a blocking issue per se. However, I do think it is very important for admins to have full name and email address associated with each hackage account that hackage admins can refer to.

Matthew Gruen

@hesselink Okay. Email confirmation still seems best to make optional for minimal servers though, e.g. if a server is running on someone's laptop for a LAN. It would be turned on for main Hackage then.
@lpsmith Having an email address seems important, but I'm not sure about full name. (This was discussed a while back...)

Leon P Smith

I said full name, not real name. Personally, I'm ok with pseudonyms as long as there is a commitment to using that name within the Haskell community. So for example, I'm fine with Heinrich Apfelmus as the "full name" behind the corresponding hackage account, as that's what he's known by in the community (and he's very open about it being a pseudonym.)

Matthew Gruen

Okay, so then someone should not be able to register for Hackage unless they have both a unique handle (something to put in a URL) and a full name. If I can pick your brain about it, how would you like to validate names? Non-blankness?

Leon P Smith

Yeah, I wouldn't validate names too much. Actually; I don't see any need for any level of validation. I don't want to create hackage accounts automatically, I'd much rather that it be an account request form. I've posted a bit about what I'd like to have on the cabal-devel mailing list.

http://www.haskell.org/pipermail/cabal-devel/2012-September/009060.html

Leon P Smith

However, that's an ideal that, like I said, doesn't need to be in place to go live as long as we import old accounts.

Leon P Smith

I should also point out that the "full name" and "email" fields would only be visible to hackage admins.

Matthew Gruen

Hm. I did some comparing and contrasting of passably related user-contributed package repositories. (Will be glad to correct any errors.) And, yes, we will import old accounts, but they will have to go through a manual auth format upgrade.

For these repositories, in order to get registered, you need:

  • RubyGems/PyPi: Handle, working email.
  • Arch (and Github): Handle, working email, optional name.
  • Current Hackage: Name and working email. Brief manual review.
  • CPAN: Real name, working email, and intentions for contribution. Moderate review.
  • Debian: Real name, working email, advocates and sponsors, philosophical background check, etc.

In order to contribute your own package:

  • Current Hackage/Debian/Arch: Upload whatever you want.
  • RubyGems/PyPi: Uploading a name makes it unavailable for others.
  • CPAN: Likewise. However, a package may not get indexed if its module name is not approved in advance.

In order to contribute to others' packages:

  • Current Hackage/Debian/Arch: No technical barriers.
  • RubyGems: Owners can add and remove other owners.
  • PyPi: Owners can add and remove owners and maintainers; maintainers cannot add or remove anyone.
  • CPAN: Maintainers can add co-maintainers. If the maintainer does not respond to many many emails over several weeks (with proof of non-response), admins can grant co-maintainership.

Hackage both has an amazingly long tail and a stable useful head. This juxtaposition makes Hackage 2 seem great for both easier signup and a web interface which highlights the most useful packages. This will also make it feasible for people who are consumers of packages (I tend to moreso fall here...) to be involved in the development process. Like RubyGems and PyPi, maybe we don't even need to approve uploaders. What do you think of:

  • Registration: Name (public), handle, working email (private), captcha, profile information etc.
  • Contributing your own package: Uploading a name makes it unavailable for others.
  • Contributing to others' packages: Ask to be added as maintainer, or use libraries list to contact trustees in the case of absentee maintainers.
Erik Hesselink

@gracenotes That final plan sounds almost exactly like what I would like to see. I'm still not sure about have a public real name as a requirement, but a lot of people seem to be in favor of that.

Ben Millwood

I'm not confident public real name adds much value either, for what it's worth. The rest seems sensible.

Matthew Gruen

As Leon was saying, it wouldn't have to be a real name; psuedonym-looking names are also fine. It would mainly be a continuation of the current Hackage usernames for those who'd like to use non-name handles instead.
(Don't feel hugely strongly either way.)

Duncan Coutts
Owner

So, here's what I've implemented:

Signup

Page where you can request an account. You enter:

  • a login name (ASCII only, no spaces),
  • a (public) "real" name, i.e. the name by which you wish to be known on the site
  • a (private) email address

It sends you an email with a link, you follow the link to a page where you enter your new password. At this point the account actually gets created.

You are not yet a member of the uploaders group. That requires action by the admins. There is nothing yet to automate making requests for that.

Password reset

Similar to signup. Go to a reset request page, enter username and email address (which must match the ones on file). An email is sent with a link, follow the link and you can enter a new password.

(The signup and reset links are intended to be time-limited but that's not implemented just yet.)

Old account imports

We can import all the existing accounts, including username, real name, email address. All these accounts will be members of the uploader group, and the maintainer groups are pre-populated based on who has uploaded each package in the past. We can also import all the old password hashes and there is a simple one-time procedure to update to the new auth system.

Erik Hesselink

Why have a login name and an email address? Other users are shown the "real" name, so the login name is only an extra thing you can forget. That means you need an extra reset, etc.

Duncan Coutts
Owner

Mainly because that's the way it's always been done, and so it matches the data we have for existing users, and it's not a change of behaviour for those existing users (in fact they probably don't know that we remembered the email address they used to sign up with).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.