I'm a little bit concerned about that. First I'm using a different user on Trac than on Github, so everything I wrote so far will getting lost (not that bad problem for me), but I think there are many users who are in the same situation.
The next thing is vendor lock-in. What will happen if Github don't have enough money? Then all usernames would need to migrate back or to another OAuth provider, then everything could be lost a second time. Or that Github gets bad / mad. Currently we already live in a world were everything gets connected. And that is really awful. One must consider that Github is definitely a target for intelligence agencies. And I don't mean the NSA only. Maybe I'm a little bit too paranoid but at the current state of the internet we shouldn't try to connect everything, just it is easier to login. 2014-08-07 8:46 GMT+02:00 Aymeric Augustin < [email protected]>: > To be clear, I have a working implementation of GitHub OAuth that I can > activate as soon as we reach a consensus. > > > > On 7 août 2014, at 02:43, Ben Finney <[email protected]> wrote: > > > −1. I am happy to agree to Django's BTS terms of use, not GitHub's. > > Please don't make the former depend on the latter. > > I didn’t know our Trac installation had terms of use. So, are you > volunteering to jump in and delete spam as it comes in? Or do you > have an alternative proposal? > > > > On 7 août 2014, at 02:47, Shai Berger <[email protected]> wrote: > > > Today, it is possible to contribute to the Django project without a > > Github account. I would like this to remain the case. > > This is possible but in a limited capacity. To be honest, I think that > ship sailed when we moved to GitHub. We would have also moved > issues there if GitHub’s tools were usable. > > > > On 7 août 2014, at 02:58, Andre Terra <[email protected]> wrote: > > > Most importantly, how would Django as a project benefit from this > > choice other than reducing minimal spam? > > Did you just ask “how would Django as a project benefit from having > core devs work on committing patches rather than fighting spam”? > > If you don’t already have a djangoproject.com account, you’re likely to > give up on reporting a small bug just because it’s too complicated to > log in. Considering our target demographic, GitHub OAuth would > eliminate this problem. > > Also, if you’re trying to report a bug anonymously, you’re likely to be > unable to pass the CAPTCHA, and also be unable to report it, because > you’re still getting blocked by the CAPTCHA. See complaints: > https://code.djangoproject.com/search?q=captcha&noquickjump=1&ticket=on > > Finally, to be honest, I’d rather adjust Django’s tools to enthusiastic > beginners than grumpy freedom extremists who refuse to use GitHub. > > > A better solution would be to strengthen what it means to have an > identity > > on djangoproject.com. Rather than restricting user actions to Trac, we > > could motivate users to create something like a Django profile which > would > > be used for Trac (among may other uses) > > We already have that: https://www.djangoproject.com/~aaugustin/ > > > and could later be linked to any OAuth providers, including but not > limited > > to GitHub. > > We don’t have that. > > > TL;DR Identity on djangoproject.com, Authentication linked to multiple > OAuth, > > Authorization in Trac. > > Are you volunteering to do this work, and if so, when will it be done? > > > I hope that idea makes sense. I may be just babbling nonsense. > > > I’m sorry, but ideas don’t matter nearly as much as execution here. > We just need working tools — nothing fancy. > > > > On 7 août 2014, at 02:59, Josh Smeaton <[email protected]> wrote: > > > is it easy enough to support github oauth + the current trac auth > concurrently? > > If a user chooses to go through the harder path, that's fine. > > It may be doable to provide two authentications endpoints, like /login and > /login/github. Trac just looks at REMOTE_USER and creates a session that > lasts until you logout. I’ll look into it. > > That solves the “GitHub is evil, I don’t want to touch their bytes with a > six > foot pole” problem, but only half of the username mismatch problem. You > can keep using your djangoproject.com username is you wish, but if > someone else owns the same username on GitHub, they can impersonate > you e.g. https://github.com/shai / https://www.djangoproject.com/~shai/. > > That said, if you aren’t logged in, you can type anything you want in > Trac's > “Your username or email” field. It provides identification, not > authentication. > This has never been a problem in the past. So I don’t think we’ll run into > too much trouble with usernames in general. > > The only part where Trac usernames are used for authentication is access > control, which only applies to people who have special permissions. > > -- > Aymeric. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/53B41C22-FAB6-49A9-9284-5BCCFC4D28BD%40polytechnique.org > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPDLAU6p0J_bs69e1VP4moxwSAj7-fN89X8fZoO%2B3akRRpVahw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
