Martin v. Löwis wrote:
Well, python-openid is written in Python, so it should be possible
to add whatever special functionality you need.
For this, I would like to see contributions.
I found myself that it is absolutely necessary to understand the actual
message flow, so I couldn't have
On Wednesday 18 November 2009 06:46:43 Martin v. Löwis wrote:
Since OpenID is an authentication solution, you should probably just
accept the claimed identity as the username.
It can't work that way, and shouldn't. First, OpenID defines the Simple
Registration extensions (SREG) to
However, it is not clear how this is deployed on the
pypi.python.org server. Is there a staging installation
to be used for testing ?
See
http://wiki.python.org/moin/CheeseShopDev
Regards,
Martin
___
Catalog-SIG mailing list
Catalog-SIG@python.org
I'm not saying that mod_auth_openid will solve all problems instantly, but I
just thought that it could do a lot of the work and minimise changes to the
applications, and that's presumably what its developers intended.
For me, it feels that the only possible users of an openid client
Martin v. Löwis wrote:
Are you using python-openid for this ?
http://openidenabled.com/python-openid/
No, I have written a new OpenID client. The protocol itself
is fairly simple, once you got it.
Why do this rather than using (and maybe improving) an existing library?
Chris
Firstly, thanks to Ben for bringing these discussions to the correct
list. I'd wondered why PyPI's OpenID support was so difficult to use,
now I understand ;-)
Martin v. Löwis wrote:
If I had to verify the user's real name afterwards anyway, and if I
need a verified real name (for some
On Tuesday 17 November 2009 06:44:22 Martin v. Löwis wrote:
[mod_auth_openid]
The problem I have with this (and also partially with python-openid) is
that I don't know how to integrate it with the existing application. How
is the module supposed to know what PyPI accounts are, and how they
Martin v. Löwis mar...@v.loewis.de writes:
Since OpenID is an authentication solution, you should probably just
accept the claimed identity as the username.
It can't work that way, and shouldn't. First, OpenID defines the
Simple Registration extensions (SREG) to explicitly cover a
On Mon, Nov 16, 2009 at 12:45 AM, Martin v. Löwis mar...@v.loewis.de wrote:
No no no. It's called provider because it provides me with
authenticated information, and it's called relying party because
I rely on the provider to do so reliably. That's the whole point.
If I had to verify the
The problem here, I think, is that you're expecting more from OpenID
than it really provides. OpenID lets me make an assertion about a URL
(namely, that I am that URL)
That's not true. The Attribute Exchange extension, and the Simple
Registration extension allow precisely that. See
Since I can create as many gmail accounts as I want and use them to
register as many separate PyPI accounts as I want, what's the point of
trying to enforce this restriction on OpenID-based accounts?
It seems that it only causes problems for people who want to use OpenID,
while not really
On Mon, Nov 16, 2009 at 12:40 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Did you try that out? I can't see a reason why you shouldn't be able
to use that with PyPI - just follow the myOpenID link on the front
page (or, if you have already a PyPI account, login, go to your user
information,
James Bennett wrote:
On Mon, Nov 16, 2009 at 12:40 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
Did you try that out? I can't see a reason why you shouldn't be able
to use that with PyPI - just follow the myOpenID link on the front
page (or, if you have already a PyPI account, login, go to
On Mon, Nov 16, 2009 at 2:08 PM, Martin v. Löwis mar...@v.loewis.de wrote:
This I don't understand. You'll be identified by myopenid.com as
ubernostrum.myopenid.com *anyway*, even if you first enter something
else. So why can't you just go ahead and associate
ubernostrum.myopenid.com with your
Martin v. Löwis mar...@v.loewis.de writes:
The verification, though, should be done by PyPI. You shouldn't be
trusting the OpenID provider to verify an email address, that's not
its job (and, as you rightly point out, you can't trust an arbitrary
OpenID provider to do so).
No no no.
This I don't understand. You'll be identified by myopenid.com as
ubernostrum.myopenid.com *anyway*, even if you first enter something
else. So why can't you just go ahead and associate
ubernostrum.myopenid.com with your PyPI account, and then use that
to login?
My OpenID is www.b-list.org.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
I don't know what the point of OpenID delegation is; to me, it
appears as a work-around to not have people remember long and
complicated IDs, but rather have them type something they can
remember. With PyPI, you don't have
No no no. It's called provider because it provides me with
authenticated information, and it's called relying party because
I rely on the provider to do so reliably. That's the whole point.
That's not a promise ever made by the protocol, so I don't know why
you're expecting that. The
Martin v. Löwis mar...@v.loewis.de writes:
It seems that it only causes problems for people who want to use
OpenID, while not really preventing any opportunities for spammers
(who can always just use non-OpenID authentication).
Is the plan to eventually disable non-OpenID
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
That's right: you can't use the delegation feature of PyPI right
now. But you could certainly use your OpenID with PyPI, as myopenid.com
is one of the accepted providers. I can understand that you may
not *want* to use that
Unfortunately, at the same time, I'm skeptical that OpenID can really
deliver here. For example, I see little chance that distutils could
provide reasonable access to PyPI using OpenID, as OpenID is fairly
bound to be run in a web browser only. So ISTM that package owners
will have to set
Georg Brandl wrote:
Is the plan to eventually disable non-OpenID authentication?
I hope not.
Same here.
This whole OpenID thing appears to introduce more problems than
it solves.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 16 2009)
Are you using python-openid for this ?
http://openidenabled.com/python-openid/
No, I have written a new OpenID client. The protocol itself
is fairly simple, once you got it.
Regards,
Martin
___
Catalog-SIG mailing list
Catalog-SIG@python.org
Martin v. Löwis wrote:
Are you using python-openid for this ?
http://openidenabled.com/python-openid/
No, I have written a new OpenID client. The protocol itself
is fairly simple, once you got it.
Is there any benefit to using mod_auth_openid with Apache, given that as far
as I'm
Martin v. Löwis mar...@v.loewis.de writes:
- [must support provider-driven identifier selection]
This is because I want to avoid ugly login boxes in the UI,
and avoid having to type users in their OpenID.
Provider-driven identifier selection is great, for exactly the reason
you state
Martin v. Löwis mar...@v.loewis.de writes:
[authenticating user-provided attributes is] not a promise ever made
by the protocol, so I don't know why you're expecting that. The
relying party gets information from the provider, but there is no
guarantee that the email address is verified to
Paul Boddie wrote:
Martin v. Löwis wrote:
Are you using python-openid for this ?
http://openidenabled.com/python-openid/
No, I have written a new OpenID client. The protocol itself
is fairly simple, once you got it.
Is there any benefit to using mod_auth_openid with Apache, given that
Chris Withers ch...@simplistix.co.uk writes:
You're forgetting the two working single sign on methods. I'd be
surprised if a developer didn't have at least one google account or a
launchpad account.
I'm happy to surprise you: I am a Python developer, a PyPI user, and I
have neither a Google
Ben Finney ben+pyt...@benfinney.id.au writes:
PyPI currently uses OpenID, but defeats much of the point of that
system by skipping important parts of the authentication protocol and
disallowing all but a small subset of identifiers (those that are
within a small set of domains).
Here's a
Martin von Löwis writes:
Glyph Lefkowitz wrote:
Why do you want [PyPI] to support OpenID only for a very small set
of providers?
There are two reasons, one more technical than the other:
1. I read that there are numerous complaints about interoperability:
[…] In particular, I would
2. I also want the provider to provide me with a verified email
address,
You can get the user's chosen email address during registration, *after*
authentication. The OpenID Simple Registration Extension (SReg)
URL:http://openid.net/specs/openid-simple-registration-extension-1_0.html
is
Martin van Löwis writes:
But then, users can easily create as many fake accounts as they want
to.
What is a “fake account”?
It's one setup with malicious intent, such as spamming.
I have three OpenIDs that I use for different
purposes. On some sites, I will associate them together; on
32 matches
Mail list logo
