What's a User?

[brian-c]

Currently a user signs up with:

• Username
• Password
• Real name (for recognition in papers, etc.)
• "Send me beta announcements"

In #38 @edpaget suggested a separate key for URL. That gives us three "name" properties. Can we use the login for the URL, encoding what needs encoding when calling the API? URLs in the browser should render okay: #/ß®ï@ñ-¢.

[brian-c]

Also: is sorta an issue-per-model a good way to talk about what's associated with what and what's returned with which requests?

[edpaget]

Yeah that sounds good me. I'd be fine with using people's logins since they're already case insensitive. Do we currently permit white-space? I'd like to not have to have %20s all over URLs

[camallen]

Login names have spaces and other chars currently with validation only on uniqueness (case_insensitive) and presence. I confirmed there are users in home with spaces in their logins.

[edpaget]

What if we silently convert whitespaces to underscores? Persist "cool user" as "cool_user", and when she tries to login do a login.gsub(" ", "_") before looking her up the database,

[camallen]

Yeah, we could even enforce no spaces for new users / updates to login names and use something like Ed suggested for migrated users

[brian-c]

What about "¢øø£ usér" though?

[brian-c]

I don't think this is a big deal by the way. Maybe we disallow spaces, but I'd hate to tell people they can't use accented characters. I think the number of weird characters in accounts and the number of people who actually look at URLs is small enough that we don't need to worry about this.

[edpaget]

I'm cool with allowing any characters that don't have to be escaped to be
URL encoded. So all the crazy accents look fine to me.
On Jun 6, 2014 7:56 AM, "Brian Carstensen" notifications@github.com wrote:

I don't think this is a big deal by the way. Maybe we disallow spaces, but
I'd hate to tell people they can't use accented characters. I think the
number of weird characters in accounts and the number of people who
actually look at URLs is small enough that we don't need to worry about
this.

—
Reply to this email directly or view it on GitHub
#40 (comment).

[camallen]

+1 for not escaping chars in URL's.

[parrish]

Persist "cool user" as "cool_user", and when she tries to login do a login.gsub(" ", "_") before looking her up the database

"cool user" and "cool_user" can both exist in the database right now. That's not going to work.

Yeah, we could even enforce no spaces for new users / updates to login names and use something like Ed suggested for migrated users

I'm up for setting sane validations for new users. I'm just not sure how we can force changes to old users.

I'd love to get rid of some of the crazy values in that table though. If you're up for a laugh, go take a look at some of the weird junk in there.

[edpaget]

@parrish brought this up at Standup today. What kind of user logins will we allow? I'm for downcased and no whitespace, but otherwise anything goes. When a migrated user signs on, we just prompt them to change their login name, while leaving their display name set to their old user name.

[parrish]

I think a set of restricted characters is fine too. At least ^ and @ since we're using those in Talk. Restricting @ would also prevent people from using their email addresses as their logins, which is not something most people want publicly visible.

[chrislintott]

Have we given up on shifting to allowing Facebook/Twitter/whatever logins? We’ve had that on our desirables list for a long while now.

On 15 Jan 2015, at 08:21, Michael Parrish notifications@github.com wrote:

I think a set of restricted characters is fine too. At least ^ and @ since we're using those in Talk.

—
Reply to this email directly or view it on GitHub.

[edpaget]

Nope already support Facebook and google+ logins. We don't have twitter at
the moment since there isn't a way to get email from that.
On Feb 3, 2015 2:46 PM, "Chris Lintott" notifications@github.com wrote:

Have we given up on shifting to allowing Facebook/Twitter/whatever logins?
We’ve had that on our desirables list for a long while now.

On 15 Jan 2015, at 08:21, Michael Parrish notifications@github.com
wrote:

I think a set of restricted characters is fine too. At least ^ and @
since we're using those in Talk.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#40 (comment).