Re: Google signin

On Tue, Aug 15, 2017 at 10:42 AM, Magnus Hagander <magnus(at)hagander(dot)net>
wrote:

>
>
> On Mon, Aug 14, 2017 at 9:59 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
>> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>> > On Mon, Aug 14, 2017 at 5:17 PM, Stephen Frost <sfrost(at)snowman(dot)net>
>> wrote:
>> > > * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>> > > > On Fri, Aug 11, 2017 at 5:15 PM, Stephen Frost <sfrost(at)snowman(dot)net>
>> > > wrote:
>> > > > > We should really have a DB constraint which enforces uniqueness on
>> > > > > lower(username), imv, and perhaps try to proactively do something
>> about
>> > > > > accounts which have invalid characters, but that's a different
>> > > > > discussion.
>> > > >
>> > > > I could've sworn we had a constraint on the lowercase part. It must
>> be
>> > > in a
>> > > > different one of our systems though, because I can't see it in this
>> one..
>> > >
>> > > I wouldn't have mentioned it if I had seen one there. :)
>> > >
>> > > Having it in a downstream system but not in the authorative one
>> strikes
>> > > me as a bad idea..
>> >
>> > Yes. That's a recipie for trouble.
>>
>> Ok, so, you going to fix it, or should I, and do we need a migration for
>> it..?
>>
>
> I've got it on my list.
>
>
>
>> > > > > Given that we're offering to do this, I almost wonder if we
>> should just
>> > > > > automatically do it rather than making them jump through the extra
>> > > > > hoop.. That would have to be after we figure out a way to have
>> > > accounts
>> > > > > support multiple email addresses tho.
>> > > >
>> > > > We need them to pick a username, that's why we need an extra form
>> to be
>> > > > filled out. We could remove the name part of it to make it even
>> simpler,
>> > > > and have them change that after the fact, but I'm not sure that
>> actually
>> > > > simplifies things that much.
>> > > >
>> > > > We could get away with that if we could use the email address as the
>> > > > username, but that breaks with mediawiki at least.
>> > >
>> > > I think you missed my point here- technically we need a username which
>> > > isn't their email address, but they don't necessairly have to pick one
>> > > and, indeed, this code actually builds one for them as a
>> > > recommendation. Given that they don't need to know their username for
>> > > logging in with Google or similar, it really could just be something
>> > > that we internally keep track of.
>> >
>> > We could, but that username is *visible* on systems. Anybody logging in
>> > that way and then using the wiki, or the cf app, or redmine, etc, will
>> have
>> > that username exposed and will probably come asking to change it. And we
>> > can't change usernames since it's the primary key across the distributed
>> > system...
>>
>> Hrmpf. I agree, that's slightly annoying, but that strikes me as a
>> reason to make it something other than a transposed email address, not
>> that the idea is a terrible one. What about something like first-name,
>> last-initial, followed by a number to avoid dups?
>>
>
> Agree that it's a bad flow for most users.However, I'm not sure *not*
> giving them the choice is going to be very helpful either. We can change
> the cf app to just use the full name for example, but there is no way we
> can get these names out of being very prominent on the wiki or redmine. So
> I think we *have* to let people choose.
>
> We can certainly change how we create the initial suggestion for them. And
> maybe firstname/lastname is a better choice, I agree.
>
>
>
>> > > That does bring up a question though- does the code make sure to
>> avoid a
>> > > conflict with an existing username in the one that's suggested? I
>> > > didn't see that, and we should probably do that.
>> >
>> > In that case it will propose an invalid username and you will get the
>> error
>> > when you hit save. That's definitely a flow that could be improved if we
>> > think this risks happening often.
>>
>> Using the email address as the basis likely makes that unlikely (though
>> not impossible), but if we change the basis of the username then it may
>> become more likely...
>>
>
> Agreed.
>
> Though if we have a retrying method as you suggested above we can make the
> check first and just try again until we present something that was at least
> not used when the form was *built*. Of course if somebody else signs up
> with that userid while we wait for them to submit the form it's still going
> to give them an error and require a change, but that seems acceptable.
>

Here's an updated patch that does this. It will try in order:
<firstname><lastinitial>, e.g. stephenf
<firstinitial><lasdtname>,e.g. sfrost
<firstname><lastinitial><number>, e.g. stephenf0, stephenf1, stephenf2 etc

Since usernames are truncated at 30 it might be that all those generate
duplicates, in which case it falls back to the previous way of doing it off
the email.

It now also prevents password recovery on accounts that don't have
passwords, instead saying that it's using a third party login method.

> I do think there's value in removing the need for this form to be filled
>> out, particularly for $user who doesn't have a .Org account and isn't on
>> the .Org site but is actually on some other website (eg:
>> postgresopen.org or pgconf.eu) and just wants to register for a
>> conference- they could possibly just hit 'login with google' or whatever
>> and then have everything happen magically for them without ever actually
>> seeing the .Org website.
>
>
> I fully agree. I just don't see a way to do it, without changing the core
> of community auth to be based off email instead of username, and stopping
> the use of software like mediawiki. Which I don't think we are willing to
> do.
>
>

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>