Re: [pgsql-www] Google signin - Mailing list pgsql-www

From Magnus Hagander
Subject Re: [pgsql-www] Google signin
Date
Msg-id CABUevEz2CAjfAdaXKVmyUbqz1haXsvxVotnK5aLS+JekCoWTqg@mail.gmail.com
Whole thread Raw
In response to Re: [pgsql-www] Google signin  (Magnus Hagander <magnus@hagander.net>)
Responses Re: [pgsql-www] Google signin  (Stephen Frost <sfrost@snowman.net>)
Re: [pgsql-www] Google signin  (Daniel Gustafsson <daniel@yesql.se>)
Re: [pgsql-www] Google signin  (Greg Stark <stark@mit.edu>)
List pgsql-www
On Tue, Aug 15, 2017 at 10:42 AM, Magnus Hagander <magnus@hagander.net> wrote:


On Mon, Aug 14, 2017 at 9:59 PM, Stephen Frost <sfrost@snowman.net> wrote:
* Magnus Hagander (magnus@hagander.net) wrote:
> On Mon, Aug 14, 2017 at 5:17 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Magnus Hagander (magnus@hagander.net) wrote:
> > > On Fri, Aug 11, 2017 at 5:15 PM, Stephen Frost <sfrost@snowman.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.
 

--
Attachment

pgsql-www by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [pgsql-www] Google signin
Next
From: Stephen Frost
Date:
Subject: Re: [pgsql-www] Google signin