Martin v. Löwis wrote:
Michael Foord wrote:
Martin v. Löwis wrote:
Would it be possible to detect a change of provider and then offer the
option to migrate the account to the new provider (so long as it does
not conflict with another account)?
That would be possible - but
Michael Foord wrote:
> Martin v. Löwis wrote:
>>> Would it be possible to detect a change of provider and then offer the
>>> option to migrate the account to the new provider (so long as it does
>>> not conflict with another account)?
>>>
>>
>> That would be possible - but again complicate the
Martin v. Löwis wrote:
Would it be possible to detect a change of provider and then offer the
option to migrate the account to the new provider (so long as it does
not conflict with another account)?
That would be possible - but again complicate the UI.
Why? You should only need to pr
> Would it be possible to detect a change of provider and then offer the
> option to migrate the account to the new provider (so long as it does
> not conflict with another account)?
That would be possible - but again complicate the UI.
Regards,
Martin
Martin v. Löwis wrote:
Even not having provider changes supported would still allow me to use
my openid with PyPI which would be great. The only problem with changing
provider that I can see is when the provider a user changes to would
then be a duplicate - in which case I think just refusing to
Martin> It's far from obvious. It's called "provider-driven identifier
Martin> selection". PyPI redirects your browser to Google. Google looks
Martin> at the Google cookie, and finds your identity; they also see
Martin> that you have opted to automatically log into PyPI. So without
> Even not having provider changes supported would still allow me to use
> my openid with PyPI which would be great. The only problem with changing
> provider that I can see is when the provider a user changes to would
> then be a duplicate - in which case I think just refusing to allow the
> login
Martin v. Löwis wrote:
[snip...]
Why not allow users to login with their own openid, but
only allow one account to refer back to the same delegated account?
That sounds good. I'm not sure how to implement a provider change
in that scenario, though.
Even not having provider changes sup
s...@pobox.com wrote:
> Martin> That's indeed what PyPI attempts to do. At the "claim openid"
> Martin> place, follow the Launchpad link. It should guide you through
> Martin> the procedure.
>
> Well, since I use Google a lot more I'd prefer to use that. If I click the
> Google OpenID
> This doesn't seem to be a problem for all the other sites I use my
> openid with.
Perhaps they don't care about fake accounts at all? That would, in
particular, be the case if they accept arbitrary OpenID providers
(which means that essentially no real authentication happens).
> Why not allow u
Martin> That's indeed what PyPI attempts to do. At the "claim openid"
Martin> place, follow the Launchpad link. It should guide you through
Martin> the procedure.
Well, since I use Google a lot more I'd prefer to use that. If I click the
Google OpenID link I now get
OpenID is al
Martin v. Löwis wrote:
Can't you then produce hundreds of IDs, all delegating to the same
identity?
Yes.
But then, users can easily create as many fake accounts as they want to.
This is not something I want to happen (it's still possible to setup
fake accounts, but it should be mor
On Sun, Nov 15, 2009 at 2:44 PM, "Martin v. Löwis" wrote:
> But then, users can easily create as many fake accounts as they want to.
>
Why not do something more robust, then? For example, when a user enters an
OpenID that hasn't been seen by PyPi before, make them enter a CAPTCHA.
--
Daniel Stu
> I've never found OpenID at all intuitive to use. Are there instructions on
> pypi.python.org which detail the steps necessary to use OpenID to login? I
> saw the "Claim OpenID" link on my PyPI profile page. So now I have an
> OpenID URL. What am I supposed to do with that? If I visit that UR
>> Can't you then produce hundreds of IDs, all delegating to the same
>> identity?
>
> Yes.
But then, users can easily create as many fake accounts as they want to.
This is not something I want to happen (it's still possible to setup
fake accounts, but it should be more difficult for the average
Martin> Then I recommend that you get a google account for your email
Martin> address, and register to PyPI using OpenID.
I've never found OpenID at all intuitive to use. Are there instructions on
pypi.python.org which detail the steps necessary to use OpenID to login? I
saw the "Claim
On Sun, Nov 15, 2009 at 11:31 AM, "Martin v. Löwis" wrote:
>
> > Well, when I login my registered ID is www.voidspace.org.uk and *not*
> > fuzzyman.myopenid.com - so I believe you are incorrect (and in fact this
> > very point was touted as one of the advantages of openid - that your
> > account i
> Well, when I login my registered ID is www.voidspace.org.uk and *not*
> fuzzyman.myopenid.com - so I believe you are incorrect (and in fact this
> very point was touted as one of the advantages of openid - that your
> account is independent of your provider and that you *can* change
> provider wh
Martin v. Löwis wrote:
So the only thing users gain with delegation is that they don't need
to remember the tedious URL that their provider assigns them. When they
switch providers, their claimed ID will still change, and they'll have
to reregister in all services they use.
No, the wh
>> So the only thing users gain with delegation is that they don't need
>> to remember the tedious URL that their provider assigns them. When they
>> switch providers, their claimed ID will still change, and they'll have
>> to reregister in all services they use.
>>
>>
> No, the whole point of d
Martin v. Löwis wrote:
Fred can use his own OpenID ‘fred.example.org’, initially set up behind
the scenes to delegate to ‘bigcorp.example.com’ as the provider. Any
time he likes, Fred can *change* which provider is actually used for
authentication, without changing his OpenID. PyPI gets to find o
"Martin v. Löwis" writes:
> > Fred can use his own OpenID ‘fred.example.org’, initially set up
> > behind the scenes to delegate to ‘bigcorp.example.com’ as the
> > provider. Any time he likes, Fred can *change* which provider is
> > actually used for authentication, without changing his OpenID.
Martin v. Löwis wrote:
Why? I already have python tracker account and a python wiki account
which is already 2 too many. The latter was a pain because the site lost
my registration and as of a year ago, the registration process was
broken. I would much prefer just one python site registration.
> Fred can use his own OpenID ‘fred.example.org’, initially set up behind
> the scenes to delegate to ‘bigcorp.example.com’ as the provider. Any
> time he likes, Fred can *change* which provider is actually used for
> authentication, without changing his OpenID. PyPI gets to find out which
> provid
"Martin v. Löwis" writes:
> > And that registration should be using any OpenID, so that I don't
> > need any new identities to participate on the Python sites: I can
> > re-use existing identities.
>
> PyPI actually does support OpenID.
I commend the PyPI administrators for this step, but the im
"Stephen J. Turnbull" writes:
> Ben Finney writes:
>
> > I would make a bug report for that, but the Python bug tracker also
> > requires yet-another-identity. It's lunacy.
>
> No, it's legacy. The software predates the availability of OpenID.
I don't agree that's a “no”; it's a “yes, and” :-
> And that registration should be using any OpenID, so that I don't need
> any new identities to participate on the Python sites: I can re-use
> existing identities.
PyPI actually does support OpenID.
Regards,
Martin
___
Python-Dev mailing list
Python-D
> Why? I already have python tracker account and a python wiki account
> which is already 2 too many. The latter was a pain because the site lost
> my registration and as of a year ago, the registration process was
> broken. I would much prefer just one python site registration.
Then I recommend t
Ben Finney writes:
> I would make a bug report for that, but the Python bug tracker also
> requires yet-another-identity. It's lunacy.
No, it's legacy. The software predates the availability of OpenID.
If you'd like to integrate Open ID authentication into Roundup, I will
personally be happy
Terry Reedy writes:
> Martin v. Löwis wrote:
>
> >>> This is indeed intentional: people like you won't upload packages
> >>> to PyPI, nor will they take part in the rating system, as both
> >>> require a PyPI account.
>
> Why? I already have python tracker account and a python wiki account
> whic
Martin v. Löwis wrote:
This is indeed intentional: people like you won't upload packages to
PyPI, nor will they take part in the rating system, as both require
a PyPI account.
Why? I already have python tracker account and a python wiki account
which is already 2 too many. The latter was a pa
31 matches
Mail list logo
