You can clone with
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.
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.
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.
This sounds like a good story for new accounts for the main Hackage server. What about legacy-imported accounts and minimal (private) Hackage servers?
@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.
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.
@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...)
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.)
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?
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.
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.
I should also point out that the "full name" and "email" fields would only be visible to hackage admins.
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:
In order to contribute your own package:
In order to contribute to others' packages:
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:
@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.
I'm not confident public real name adds much value either, for what it's worth. The rest seems sensible.
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.)
So, here's what I've implemented:
Page where you can request an account. You enter:
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.
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.)
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.
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.
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).