From martin at paljak.pri.ee  Wed Jul  2 10:01:50 2008
From: martin at paljak.pri.ee (Martin Paljak)
Date: Wed, 2 Jul 2008 18:01:50 +0100
Subject: How to set expires_in from python-openid server?
Message-ID: <6EAFCA8A-9D3E-4AD4-805C-55E0F43E4CE7@paljak.pri.ee>

Hi!

I don't seem to find a path through the code to set expires_in ( see http://openid.net/specs/openid-authentication-2_0.html#anchor20 
  ) of an outgoing response.
Also, how to upgrade to SHA256 and drop no-encryption? Reading from  
the association.py there should be a special negotiator created for  
that.


Hints ?

-- 
Martin Paljak
http://martin.paljak.pri.ee
GSM: +3725156495






From andrewarnott at gmail.com  Wed Jul  2 10:06:14 2008
From: andrewarnott at gmail.com (Andrew Arnott)
Date: Wed, 2 Jul 2008 10:06:14 -0700
Subject: How to set expires_in from python-openid server?
In-Reply-To: <6EAFCA8A-9D3E-4AD4-805C-55E0F43E4CE7@paljak.pri.ee>
References: <6EAFCA8A-9D3E-4AD4-805C-55E0F43E4CE7@paljak.pri.ee>
Message-ID: <216e54900807021006u3f1a4ce8h7ef0eebf0ea0ba71@mail.gmail.com>

Has anyone else noticed that Yahoo doesn't seem to support SHA-256?

--
Andrew Arnott

On Wed, Jul 2, 2008 at 10:01 AM, Martin Paljak <martin at paljak.pri.ee> wrote:

> Hi!
>
> I don't seem to find a path through the code to set expires_in ( see
> http://openid.net/specs/openid-authentication-2_0.html#anchor20
>  ) of an outgoing response.
> Also, how to upgrade to SHA256 and drop no-encryption? Reading from
> the association.py there should be a special negotiator created for
> that.
>
>
> Hints ?
>
> --
> Martin Paljak
> http://martin.paljak.pri.ee
> GSM: +3725156495
>
>
>
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.openidenabled.com
> http://lists.openidenabled.com/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080702/1a988b4e/attachment.html 

From cygnus at janrain.com  Mon Jul  7 15:15:46 2008
From: cygnus at janrain.com (Jonathan Daugherty)
Date: Mon, 7 Jul 2008 15:15:46 -0700
Subject: [ANN] Moving lists.openidenabled.com to new hardware
Message-ID: <e56baffa0807071515s395f6ddbg1f889c6af52bb927@mail.gmail.com>

Hi folks,

We're going to be moving lists.openidenabled.com to new hardware
shortly; the lists will be offline for a short time while we make sure
the new environment is working correctly.  DNS changes will take some
time to propagate, so SMTP and web will both be unavailable until they
do.

Sorry for the inconvenience!

-- 
 Jonathan Daugherty


From please.no.more.spam at gmail.com  Wed Jul  9 15:31:46 2008
From: please.no.more.spam at gmail.com (=?ISO-8859-1?Q?S=E9bastien_Brault?=)
Date: Thu, 10 Jul 2008 00:31:46 +0200
Subject: Php OpenID consumer in dumb mode
Message-ID: <33842acb0807091531w5275dd11n617e822ee56c8436@mail.gmail.com>

Hi all,

I have always a problem trying to run the Janrain library in dumb
mode. I add some logs in the library to best understand what's wrong.

I use the 2.1.1 version of the php library and use the sample client
code provided with the library.

In the sample code I just replaced the file store by a dumb store, the
code of the getStore method became :

   function getStore() {
       return new
Auth_OpenID_DumbStore('qsfdf5876q56f46sfffsf0709csff09870994dfqqs84df6iz56s4f64s4q4f');
   }

When I try to authenticate, the library starts with and association
request (strange in dumb mode, no ?)

- request parameters:
                                 openid.assoc_type : HMAC-SHA1
                         openid.dh_consumer_public :
f1qFEK5UOlCPwDjs3vFaw10FM69Iz+FBNSHa11lvBHv94h4cWVZMlXZKqBdJls2/7Odevh62tTR7PJ/rIsxEUHw4vxJaICMVQgHk5mHrQd4xaeAVfACt0epP8XempjPsEjeFgwqBHghjVNk+lfBVB5Ffr0mMKBmV4Z91RCLK6oI=
                                     openid.dh_gen : Ag==
                                 openid.dh_modulus :
ANz5OguIOXLsDhmYmsWizjEOHTdxfo2Vcbt2I3MYZuYe91ouJ4mLBX+YkcLiemOcPym2CBRYHNOyyjmG0mg3BVd9RcLn5S3IHHoXGHblzqdLFEi/368Ygo79JRnxTkXjgmY0rxlJ5bU1zIKaSDuKdiI+XUkKJX8Fvf8W8vsixYOr
                                       openid.mode : associate
                               openid.session_type : DH-SHA1


  response parameters:
                                      assoc_handle :
{HMAC-SHA1}{4874d64d}{HtI3sA==}
                                        assoc_type : HMAC-SHA1
                                  dh_server_public :
bNCiNRWXtFI6Ppyz9BYytkL0Clx6TcHq9jpfkJwuiBoiYXuOhS2wxzPH1cjQkmgzEuTDDmfHNFkqOsGibMIvICBINxbSP8U7fWyD3VxFdrxlWNlJhB6TUp9TIDkrJ7yu6rreRz+LRmtbcBLpbFWQK+Bf3zqAJzwn0yJ68kSlq+U=
                                       enc_mac_key :
nR7MsWf2g9Ifwjn8C110ZZwuMVw=
                                        expires_in : 1209600
                                      session_type : DH-SHA1
                                                   :


- Then the openid request is launched :
Request parameters:
                               openid.assoc_handle :
{HMAC-SHA1}{4874d64d}{HtI3sA==}
                                   openid.identity :
http://openid.orange.fr/sebastien
                                       openid.mode : checkid_setup
               openid.pape.preferred_auth_policies :
                                  openid.return_to :
http://openid-dev.rd.francetelecom.fr:80/consumer/finish_auth.php?janrain_nonce=2008-07-09T15%3A16%3A29ZfPm6sb
                                openid1_claimed_id :
http%3A%2F%2Fopenid.orange.fr%2Fsebastien
                              openid.sreg.optional : fullname,email
                              openid.sreg.required : nickname
                                 openid.trust_root :
http://openid-dev.rd.francetelecom.fr:80/consumer/


Response parameters:
                                     janrain_nonce : 2008-07-09T15:16:29ZfPm6sb
                                openid1_claimed_id :
http://openid.orange.fr/sebastien
                               openid.assoc_handle :
{HMAC-SHA1}{4874d64d}{HtI3sA==}
                                   openid.identity :
http://openid.orange.fr/sebastien
                                       openid.mode : id_res
                                  openid.return_to :
http://openid-dev.rd.francetelecom.fr:80/consumer/finish_auth.php?janrain_nonce=2008-07-09T15%3A16%3A29ZfPm6sb
                                openid1_claimed_id :
http%3A%2F%2Fopenid.orange.fr%2Fsebastien
                                        openid.sig :
1neypKiihccr+fmcNyyofnQNooY=
                                     openid.signed :
mode,identity,return_to,sreg.nickname,sreg.email,sreg.fullname
                                 openid.sreg.email : noe.brault at orange.fr
                              openid.sreg.fullname : S?(c)bastien Brault
                              openid.sreg.nickname : S?(c)bastien Brault



- Then the last check_authetication request :

                                     janrain_nonce : 2008-07-09T15:16:29ZfPm6sb
                               openid.assoc_handle :
{HMAC-SHA1}{4874d64d}{HtI3sA==}
                                   openid.identity :
http://openid.orange.fr/sebastien
                                       openid.mode : check_authentication
                                  openid.return_to :
http://openid-dev.rd.francetelecom.fr:80/consumer/finish_auth.php?janrain_nonce=2008-07-09T15%3A16%3A29ZfPm6sb
                                openid1_claimed_id :
http%3A%2F%2Fopenid.orange.fr%2Fsebastien
                                        openid.sig :
1neypKiihccr+fmcNyyofnQNooY=
                                     openid.signed :
mode,identity,return_to,sreg.nickname,sreg.email,sreg.fullname
                                 openid.sreg.email : noe.brault at orange.fr
                              openid.sreg.fullname : S?(c)bastien Brault
                              openid.sreg.nickname : S?(c)bastien Brault
                                openid1_claimed_id :
http://openid.orange.fr/sebastien


and the response :
                                          is_valid : false


Here the tests are done with the Orange OpenID server, but the result
is the same with myopenid.com server.

It's seems like all input and output parameters are correct. So I
think there is a bug in Janrain lib for dumb mode. Or has anybody been
successful in running in dumb mode with this library ? And can he
provide his client code ?

Best regards.
S?bastien Brault.


From luke at lukeshepard.com  Mon Jul 14 15:38:05 2008
From: luke at lukeshepard.com (Luke Shepard)
Date: Mon, 14 Jul 2008 15:38:05 -0700
Subject: Is the normal_key and dumb_key supposed to be hard-coded?
Message-ID: <c102ffd80807141538p3126a4c3pbce4174660f929d8@mail.gmail.com>

This is probably a stupid question, please let me know if I'm way off base.

I'm looking to implement an OpenID provider. The Janrain PHP library has a
hard-coded normal_key and dumb_key:

class Auth_OpenID_Signatory {

    // keys have a bogus server URL in them because the
filestore
    // really does expect that key to be a URL.  This seems a
little
    // silly for the server store, since I expect there to be only
one
    // server
URL.

    var $normal_key = 'http://localhost/|normal';
    var $dumb_key = 'http://localhost/|dumb';

Is this intended to be overridden by a Signatory object that I create? The
key should be the server URL of the Relying Party, right? Or am I
misunderstanding what this key is supposed to refer to?

Thanks,
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080714/0d3d906c/attachment.html 

From kevin at janrain.com  Mon Jul 14 15:51:45 2008
From: kevin at janrain.com (Kevin Turner)
Date: Mon, 14 Jul 2008 15:51:45 -0700
Subject: Is the normal_key and dumb_key supposed to be hard-coded?
In-Reply-To: <c102ffd80807141538p3126a4c3pbce4174660f929d8@mail.gmail.com>
References: <c102ffd80807141538p3126a4c3pbce4174660f929d8@mail.gmail.com>
Message-ID: <201e81ff0807141551x1e42eafcm296875e13c713d92@mail.gmail.com>

These just need to be distinct strings to keep the different groups of
associations from colliding with each other.  They needn't be anything in
particular; the default values are fine.  They aren't the endpoint of the
URL of the RP because during an association request, the OP does not know
anything about the RP making the request.  OPs only know associations by the
handles it gives them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080714/4d469f13/attachment.htm 

From luke at lukeshepard.com  Mon Jul 14 16:00:38 2008
From: luke at lukeshepard.com (Luke Shepard)
Date: Mon, 14 Jul 2008 16:00:38 -0700
Subject: Is the normal_key and dumb_key supposed to be hard-coded?
In-Reply-To: <201e81ff0807141551x1e42eafcm296875e13c713d92@mail.gmail.com>
References: <c102ffd80807141538p3126a4c3pbce4174660f929d8@mail.gmail.com>
	<201e81ff0807141551x1e42eafcm296875e13c713d92@mail.gmail.com>
Message-ID: <c102ffd80807141600r1dc4da1exd799d48d2fb84105@mail.gmail.com>

Ah, that makes sense. So the association is just a key that's stored out
there, and not necessarily associated with the RP until the user uses it to
authenticate against one.

Thanks for the quick response.

2008/7/14 Kevin Turner <kevin at janrain.com>:

> These just need to be distinct strings to keep the different groups of
> associations from colliding with each other.  They needn't be anything in
> particular; the default values are fine.  They aren't the endpoint of the
> URL of the RP because during an association request, the OP does not know
> anything about the RP making the request.  OPs only know associations by the
> handles it gives them.
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.openidenabled.com
> http://lists.openidenabled.com/mailman/listinfo/dev
>
>


-- 
- Luke Shepard
773-742-9163
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080714/15f20b3b/attachment.htm 

From please.no.more.spam at gmail.com  Tue Jul 15 13:06:50 2008
From: please.no.more.spam at gmail.com (=?ISO-8859-1?Q?S=E9bastien_Brault?=)
Date: Tue, 15 Jul 2008 22:06:50 +0200
Subject: Php OpenID consumer in dumb mode
In-Reply-To: <33842acb0807091531w5275dd11n617e822ee56c8436@mail.gmail.com>
References: <33842acb0807091531w5275dd11n617e822ee56c8436@mail.gmail.com>
Message-ID: <33842acb0807151306x7996f1a0w92caeb37c8974e65@mail.gmail.com>

Any idea to solve this problem  ?

Regards.
S?bastien Brault.

On Thu, Jul 10, 2008 at 12:31 AM, S?bastien Brault
<please.no.more.spam at gmail.com> wrote:
> Hi all,
>
> I have always a problem trying to run the Janrain library in dumb
> mode. I add some logs in the library to best understand what's wrong.
>
> I use the 2.1.1 version of the php library and use the sample client
> code provided with the library.
>
> In the sample code I just replaced the file store by a dumb store, the
> code of the getStore method became :
>
>   function getStore() {
>       return new
> Auth_OpenID_DumbStore('qsfdf5876q56f46sfffsf0709csff09870994dfqqs84df6iz56s4f64s4q4f');
>   }
>
> When I try to authenticate, the library starts with and association
> request (strange in dumb mode, no ?)
>
> - request parameters:
>                                 openid.assoc_type : HMAC-SHA1
>                         openid.dh_consumer_public :
> f1qFEK5UOlCPwDjs3vFaw10FM69Iz+FBNSHa11lvBHv94h4cWVZMlXZKqBdJls2/7Odevh62tTR7PJ/rIsxEUHw4vxJaICMVQgHk5mHrQd4xaeAVfACt0epP8XempjPsEjeFgwqBHghjVNk+lfBVB5Ffr0mMKBmV4Z91RCLK6oI=
>                                     openid.dh_gen : Ag==
>                                 openid.dh_modulus :
> ANz5OguIOXLsDhmYmsWizjEOHTdxfo2Vcbt2I3MYZuYe91ouJ4mLBX+YkcLiemOcPym2CBRYHNOyyjmG0mg3BVd9RcLn5S3IHHoXGHblzqdLFEi/368Ygo79JRnxTkXjgmY0rxlJ5bU1zIKaSDuKdiI+XUkKJX8Fvf8W8vsixYOr
>                                       openid.mode : associate
>                               openid.session_type : DH-SHA1
>
>
>  response parameters:
>                                      assoc_handle :
> {HMAC-SHA1}{4874d64d}{HtI3sA==}
>                                        assoc_type : HMAC-SHA1
>                                  dh_server_public :
> bNCiNRWXtFI6Ppyz9BYytkL0Clx6TcHq9jpfkJwuiBoiYXuOhS2wxzPH1cjQkmgzEuTDDmfHNFkqOsGibMIvICBINxbSP8U7fWyD3VxFdrxlWNlJhB6TUp9TIDkrJ7yu6rreRz+LRmtbcBLpbFWQK+Bf3zqAJzwn0yJ68kSlq+U=
>                                       enc_mac_key :
> nR7MsWf2g9Ifwjn8C110ZZwuMVw=
>                                        expires_in : 1209600
>                                      session_type : DH-SHA1
>                                                   :
>
>
> - Then the openid request is launched :
> Request parameters:
>                               openid.assoc_handle :
> {HMAC-SHA1}{4874d64d}{HtI3sA==}
>                                   openid.identity :
> http://openid.orange.fr/sebastien
>                                       openid.mode : checkid_setup
>               openid.pape.preferred_auth_policies :
>                                  openid.return_to :
> http://openid-dev.rd.francetelecom.fr:80/consumer/finish_auth.php?janrain_nonce=2008-07-09T15%3A16%3A29ZfPm6sb
>                                openid1_claimed_id :
> http%3A%2F%2Fopenid.orange.fr%2Fsebastien
>                              openid.sreg.optional : fullname,email
>                              openid.sreg.required : nickname
>                                 openid.trust_root :
> http://openid-dev.rd.francetelecom.fr:80/consumer/
>
>
> Response parameters:
>                                     janrain_nonce : 2008-07-09T15:16:29ZfPm6sb
>                                openid1_claimed_id :
> http://openid.orange.fr/sebastien
>                               openid.assoc_handle :
> {HMAC-SHA1}{4874d64d}{HtI3sA==}
>                                   openid.identity :
> http://openid.orange.fr/sebastien
>                                       openid.mode : id_res
>                                  openid.return_to :
> http://openid-dev.rd.francetelecom.fr:80/consumer/finish_auth.php?janrain_nonce=2008-07-09T15%3A16%3A29ZfPm6sb
>                                openid1_claimed_id :
> http%3A%2F%2Fopenid.orange.fr%2Fsebastien
>                                        openid.sig :
> 1neypKiihccr+fmcNyyofnQNooY=
>                                     openid.signed :
> mode,identity,return_to,sreg.nickname,sreg.email,sreg.fullname
>                                 openid.sreg.email : noe.brault at orange.fr
>                              openid.sreg.fullname : S?(c)bastien Brault
>                              openid.sreg.nickname : S?(c)bastien Brault
>
>
>
> - Then the last check_authetication request :
>
>                                     janrain_nonce : 2008-07-09T15:16:29ZfPm6sb
>                               openid.assoc_handle :
> {HMAC-SHA1}{4874d64d}{HtI3sA==}
>                                   openid.identity :
> http://openid.orange.fr/sebastien
>                                       openid.mode : check_authentication
>                                  openid.return_to :
> http://openid-dev.rd.francetelecom.fr:80/consumer/finish_auth.php?janrain_nonce=2008-07-09T15%3A16%3A29ZfPm6sb
>                                openid1_claimed_id :
> http%3A%2F%2Fopenid.orange.fr%2Fsebastien
>                                        openid.sig :
> 1neypKiihccr+fmcNyyofnQNooY=
>                                     openid.signed :
> mode,identity,return_to,sreg.nickname,sreg.email,sreg.fullname
>                                 openid.sreg.email : noe.brault at orange.fr
>                              openid.sreg.fullname : S?(c)bastien Brault
>                              openid.sreg.nickname : S?(c)bastien Brault
>                                openid1_claimed_id :
> http://openid.orange.fr/sebastien
>
>
> and the response :
>                                          is_valid : false
>
>
> Here the tests are done with the Orange OpenID server, but the result
> is the same with myopenid.com server.
>
> It's seems like all input and output parameters are correct. So I
> think there is a bug in Janrain lib for dumb mode. Or has anybody been
> successful in running in dumb mode with this library ? And can he
> provide his client code ?
>
> Best regards.
> S?bastien Brault.
>


From mfurdyk at takingitglobal.org  Wed Jul 23 11:30:51 2008
From: mfurdyk at takingitglobal.org (Michael Furdyk)
Date: Wed, 23 Jul 2008 14:30:51 -0400
Subject: 2.1.1 PHP issues
Message-ID: <D1C8683B7AF0BA4F9EF0D4299CEBB5B302CEC992@ms18.mse9.exchange.ms>

Hi all,

I've upgraded to 2.1.1 to try again - running the latest PHP 5
install...

See my original post:

http://lists.openidenabled.com/pipermail/dev/2008-May/001279.html

I'm still getting a major fail on PHP when I run a hard-coded begin
auth:

Successfully fetched 'http://mfurdyk.myopenid.com/': GET response code
200
*** glibc detected *** malloc(): memory corruption: 0x0000000000d28780
***
Aborted

I tried running it with an old PHP 4 binary, and got this (maybe it was
an issue with the PHP binary)

<b>Fatal error</b>:  No XML parser was found in
<b>/usr/local/lib/php/Auth/Yadis/XML.php</b> on line <b>366</b><br />

Although detect.php does detect that our server is ready to run
php-openid, maybe I'm missing something else? We'd really like to move
ahead with this so any ideas would be greatly appreciated!

Thanks!

Michael




From kevin at janrain.com  Wed Jul 23 13:00:03 2008
From: kevin at janrain.com (Kevin Turner)
Date: Wed, 23 Jul 2008 13:00:03 -0700
Subject: 2.1.1 PHP issues
In-Reply-To: <D1C8683B7AF0BA4F9EF0D4299CEBB5B302CEC992@ms18.mse9.exchange.ms>
References: <D1C8683B7AF0BA4F9EF0D4299CEBB5B302CEC992@ms18.mse9.exchange.ms>
Message-ID: <201e81ff0807231300m181099c7k93a1097d5ad2e93a@mail.gmail.com>

On Wed, Jul 23, 2008 at 11:30 AM, Michael Furdyk <mfurdyk at takingitglobal.org>
wrote:

> Successfully fetched 'http://mfurdyk.myopenid.com/': GET response code
> 200
> *** glibc detected *** malloc(): memory corruption: 0x0000000000d28780
> ***
> Aborted


I'm not sure what's going on here either.  I suggest you report it to your
PHP vendor.  You may want to build with debugging symbols and run under a
debugger or valgrind or keep a log with strace to learn more about when the
failure occurs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080723/0f7bea50/attachment.htm 

From jason.young at extension.org  Thu Jul 24 18:31:35 2008
From: jason.young at extension.org (Jason Young)
Date: Thu, 24 Jul 2008 21:31:35 -0400
Subject: Am I missing something?  ActiveRecordOpenIDStore 
Message-ID: <D312AB16-3360-4C7F-BFC3-6BA2EC958D27@extension.org>

I'm upgrading (finally) from the Ruby OpenID 1.x libraries to the  
2.1.2 library

On line 6 of lib/openid_ar_store.rb in the active_record_openid_store  
the code reads:

class ActiveRecordStore < OpenID::Store::Interface

isn't this supposed to be ?

class ActiveRecordOpenIDStore < OpenID::Store::Interface

I have to admit that was an incredibly annoying 10-15 minutes if this  
is indeed the fix for a bunch of method not found errors :-)

Jason

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason Young --  Systems Manager, eXtension
http://about.extension.org/wiki/Jason_Young
______________________________________





From andre.cruz at co.sapo.pt  Tue Jul 29 10:48:35 2008
From: andre.cruz at co.sapo.pt (=?ISO-8859-1?Q?Andr=E9_Cruz?=)
Date: Tue, 29 Jul 2008 18:48:35 +0100
Subject: Openid lib status
Message-ID: <337AA114-0108-4F9C-85A1-62FCA110A2E5@co.sapo.pt>

Hello.

I'm evaluating some openid libs to choose one for a project. I would  
like to know which specs the Ruby and Python libs support.

 From the openid4java page I got:

     * OpenID Authentication 2.0
     * OpenID Authentication 1.1 (in compatibility mode)
     * OpenID Attribute Exchange 1.0
     * OpenID Simple Registration 1.0 and 1.1, draft 1
     * OpenID Provider Authentication Policy Extension 1.0, draft 1
     * OpenID Information Cards 1.0, draft 1

I couldn't find this in the documentation.

Best regards,
Andr? Cruz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080729/7cedc2c0/attachment.htm 

From kevin at janrain.com  Tue Jul 29 11:18:47 2008
From: kevin at janrain.com (Kevin Turner)
Date: Tue, 29 Jul 2008 11:18:47 -0700
Subject: Openid lib status
In-Reply-To: <337AA114-0108-4F9C-85A1-62FCA110A2E5@co.sapo.pt>
References: <337AA114-0108-4F9C-85A1-62FCA110A2E5@co.sapo.pt>
Message-ID: <201e81ff0807291118o219772fatb633defe123d14ca@mail.gmail.com>

Libraries at openidenabled.com (including Python and Ruby) support
OpenID protocols 1.x and 2.0, and provide code to support extensions
Simple Registration, Attribute Exchange 1.0, and Provider
Authentication Policy Extension 1.0.  You can find extension docs at
http://openidenabled.com/files/python-openid/docs/2.2.1/openid.extensions-module.html

We do not currently have support for OpenID Information Cards.

Cheers,

 - Kevin


From andrewarnott at gmail.com  Tue Jul 29 12:16:55 2008
From: andrewarnott at gmail.com (Andrew Arnott)
Date: Tue, 29 Jul 2008 12:16:55 -0700
Subject: Openid lib status
In-Reply-To: <201e81ff0807291118o219772fatb633defe123d14ca@mail.gmail.com>
References: <337AA114-0108-4F9C-85A1-62FCA110A2E5@co.sapo.pt>
	<201e81ff0807291118o219772fatb633defe123d14ca@mail.gmail.com>
Message-ID: <216e54900807291216t6b04babch3fbe0700f31f3da2@mail.gmail.com>

Hmmm... No such thing as OpenID Information Cards, I think.  Information
Cards yes, a provider can take Information Cards to authenticate a user for
OpenID authentication yes, but just to reduce confusion (for myself and
others), there aren't any OpenID Information Cards, I think.

On Tue, Jul 29, 2008 at 11:18 AM, Kevin Turner <kevin at janrain.com> wrote:

> Libraries at openidenabled.com (including Python and Ruby) support
> OpenID protocols 1.x and 2.0, and provide code to support extensions
> Simple Registration, Attribute Exchange 1.0, and Provider
> Authentication Policy Extension 1.0.  You can find extension docs at
>
> http://openidenabled.com/files/python-openid/docs/2.2.1/openid.extensions-module.html
>
> We do not currently have support for OpenID Information Cards.
>
> Cheers,
>
>  - Kevin
>
> _______________________________________________
> Dev mailing list
> Dev at lists.openidenabled.com
> http://lists.openidenabled.com/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080729/671fb051/attachment.htm 

From chris at xhost.com.au  Wed Jul 30 02:45:09 2008
From: chris at xhost.com.au (Chris Fordham)
Date: Wed, 30 Jul 2008 19:45:09 +1000
Subject: Openid lib status
In-Reply-To: <216e54900807291216t6b04babch3fbe0700f31f3da2@mail.gmail.com>
References: <337AA114-0108-4F9C-85A1-62FCA110A2E5@co.sapo.pt>
	<201e81ff0807291118o219772fatb633defe123d14ca@mail.gmail.com>
	<216e54900807291216t6b04babch3fbe0700f31f3da2@mail.gmail.com>
Message-ID: <op.ue3mpjbscznhgw@lister>

On Wed, 30 Jul 2008 05:16:55 +1000, Andrew Arnott <andrewarnott at gmail.com>  
wrote:

> Hmmm... No such thing as OpenID Information Cards, I think.  Information
> Cards yes, a provider can take Information Cards to authenticate a user  
> for
> OpenID authentication yes, but just to reduce confusion (for myself and
> others), there aren't any OpenID Information Cards, I think.

There is this: https://openidcards.sxip.com/spec/openid-infocards.html

> On Tue, Jul 29, 2008 at 11:18 AM, Kevin Turner <kevin at janrain.com> wrote:
>
>> Libraries at openidenabled.com (including Python and Ruby) support
>> OpenID protocols 1.x and 2.0, and provide code to support extensions
>> Simple Registration, Attribute Exchange 1.0, and Provider
>> Authentication Policy Extension 1.0.  You can find extension docs at
>>
>> http://openidenabled.com/files/python-openid/docs/2.2.1/openid.extensions-module.html
>>
>> We do not currently have support for OpenID Information Cards.
>>
>> Cheers,
>>
>>  - Kevin
>>
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.openidenabled.com
>> http://lists.openidenabled.com/mailman/listinfo/dev
>>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


From chris at xhost.com.au  Wed Jul 30 02:47:03 2008
From: chris at xhost.com.au (Chris Fordham)
Date: Wed, 30 Jul 2008 19:47:03 +1000
Subject: Openid lib status
In-Reply-To: <op.ue3mpjbscznhgw@lister>
References: <337AA114-0108-4F9C-85A1-62FCA110A2E5@co.sapo.pt>
	<201e81ff0807291118o219772fatb633defe123d14ca@mail.gmail.com>
	<216e54900807291216t6b04babch3fbe0700f31f3da2@mail.gmail.com>
	<op.ue3mpjbscznhgw@lister>
Message-ID: <op.ue3mspd0cznhgw@lister>

On Wed, 30 Jul 2008 19:45:09 +1000, Chris Fordham <chris at xhost.com.au>  
wrote:

> On Wed, 30 Jul 2008 05:16:55 +1000, Andrew Arnott  
> <andrewarnott at gmail.com> wrote:
>
>> Hmmm... No such thing as OpenID Information Cards, I think.  Information
>> Cards yes, a provider can take Information Cards to authenticate a user  
>> for
>> OpenID authentication yes, but just to reduce confusion (for myself and
>> others), there aren't any OpenID Information Cards, I think.
>
> There is this: https://openidcards.sxip.com/spec/openid-infocards.html

And also this thread:  
http://openid.net/pipermail/general/2007-August/003160.html

>> On Tue, Jul 29, 2008 at 11:18 AM, Kevin Turner <kevin at janrain.com>  
>> wrote:
>>
>>> Libraries at openidenabled.com (including Python and Ruby) support
>>> OpenID protocols 1.x and 2.0, and provide code to support extensions
>>> Simple Registration, Attribute Exchange 1.0, and Provider
>>> Authentication Policy Extension 1.0.  You can find extension docs at
>>>
>>> http://openidenabled.com/files/python-openid/docs/2.2.1/openid.extensions-module.html
>>>
>>> We do not currently have support for OpenID Information Cards.
>>>
>>> Cheers,
>>>
>>>  - Kevin
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at lists.openidenabled.com
>>> http://lists.openidenabled.com/mailman/listinfo/dev
>>>
>
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


From lists.anders at feder.dk  Wed Jul 30 06:20:29 2008
From: lists.anders at feder.dk (Anders Feder)
Date: Wed, 30 Jul 2008 15:20:29 +0200
Subject: OpenID PHP extension
Message-ID: <1217424029.7864.3.camel@voyager>

Hello,

Is there such a thing as a native OpenID PHP extension - meaning not one
implemented in the PHP language itself, but a compiled extension module
adding OpenID functions to PHP (similarly e.g. to the MySQL extension).

-- 
Anders Feder <lists.anders at feder.dk>



From andrewarnott at gmail.com  Wed Jul 30 07:40:00 2008
From: andrewarnott at gmail.com (Andrew Arnott)
Date: Wed, 30 Jul 2008 07:40:00 -0700
Subject: Openid lib status
In-Reply-To: <op.ue3mspd0cznhgw@lister>
References: <337AA114-0108-4F9C-85A1-62FCA110A2E5@co.sapo.pt>
	<201e81ff0807291118o219772fatb633defe123d14ca@mail.gmail.com>
	<216e54900807291216t6b04babch3fbe0700f31f3da2@mail.gmail.com>
	<op.ue3mpjbscznhgw@lister> <op.ue3mspd0cznhgw@lister>
Message-ID: <216e54900807300740x31ae4d2cq3d3994c141bdb820@mail.gmail.com>

Very cool.  Thanks for pointing this out to me.

On Wed, Jul 30, 2008 at 2:47 AM, Chris Fordham <chris at xhost.com.au> wrote:

> On Wed, 30 Jul 2008 19:45:09 +1000, Chris Fordham <chris at xhost.com.au>
> wrote:
>
> > On Wed, 30 Jul 2008 05:16:55 +1000, Andrew Arnott
> > <andrewarnott at gmail.com> wrote:
> >
> >> Hmmm... No such thing as OpenID Information Cards, I think.  Information
> >> Cards yes, a provider can take Information Cards to authenticate a user
> >> for
> >> OpenID authentication yes, but just to reduce confusion (for myself and
> >> others), there aren't any OpenID Information Cards, I think.
> >
> > There is this: https://openidcards.sxip.com/spec/openid-infocards.html
>
> And also this thread:
> http://openid.net/pipermail/general/2007-August/003160.html
>
> >> On Tue, Jul 29, 2008 at 11:18 AM, Kevin Turner <kevin at janrain.com>
> >> wrote:
> >>
> >>> Libraries at openidenabled.com (including Python and Ruby) support
> >>> OpenID protocols 1.x and 2.0, and provide code to support extensions
> >>> Simple Registration, Attribute Exchange 1.0, and Provider
> >>> Authentication Policy Extension 1.0.  You can find extension docs at
> >>>
> >>>
> http://openidenabled.com/files/python-openid/docs/2.2.1/openid.extensions-module.html
> >>>
> >>> We do not currently have support for OpenID Information Cards.
> >>>
> >>> Cheers,
> >>>
> >>>  - Kevin
> >>>
> >>> _______________________________________________
> >>> Dev mailing list
> >>> Dev at lists.openidenabled.com
> >>> http://lists.openidenabled.com/mailman/listinfo/dev
> >>>
> >
> >
> >
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> _______________________________________________
> Dev mailing list
> Dev at lists.openidenabled.com
> http://lists.openidenabled.com/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080730/c54407a4/attachment-0001.htm 

From cygnus at janrain.com  Wed Jul 30 09:01:05 2008
From: cygnus at janrain.com (Jonathan Daugherty)
Date: Wed, 30 Jul 2008 09:01:05 -0700
Subject: OpenID PHP extension
In-Reply-To: <1217424029.7864.3.camel@voyager>
References: <1217424029.7864.3.camel@voyager>
Message-ID: <e56baffa0807300901w5290dceamd06479985df9adcb@mail.gmail.com>

> Is there such a thing as a native OpenID PHP extension - meaning not one
> implemented in the PHP language itself, but a compiled extension module
> adding OpenID functions to PHP (similarly e.g. to the MySQL extension).

Not that I know of.

-- 
 Jonathan Daugherty


From lists.anders at feder.dk  Wed Jul 30 11:07:41 2008
From: lists.anders at feder.dk (Anders Feder)
Date: Wed, 30 Jul 2008 20:07:41 +0200
Subject: OpenID PHP extension
In-Reply-To: <e56baffa0807300901w5290dceamd06479985df9adcb@mail.gmail.com>
References: <1217424029.7864.3.camel@voyager>
	<e56baffa0807300901w5290dceamd06479985df9adcb@mail.gmail.com>
Message-ID: <1217441261.7864.15.camel@voyager>

ons, 30 07 2008 kl. 09:01 -0700, skrev Jonathan Daugherty:
> > Is there such a thing as a native OpenID PHP extension - meaning not one
> > implemented in the PHP language itself, but a compiled extension module
> > adding OpenID functions to PHP (similarly e.g. to the MySQL extension).
> 
> Not that I know of.
> 

How come? Would this not be tremedously useful? If it was provided as
part of the standard PHP distribution (like the MySQL extension),
websites would have OpenID right at their fingertips (no downloads, no
includes, no other special module dependencies). From the perspective of
OpenID, it would let the standard profilerate much faster.

Might there be any interest in such an extension if I were to look into
developing one?

-- 
Anders Feder <lists.anders at feder.dk>



From saeven at saeven.net  Wed Jul 30 11:32:19 2008
From: saeven at saeven.net (S. Alexandre M. Lemaire)
Date: Wed, 30 Jul 2008 14:32:19 -0400
Subject: OpenID PHP extension
In-Reply-To: <1217441261.7864.15.camel@voyager>
References: <1217424029.7864.3.camel@voyager>	<e56baffa0807300901w5290dceamd06479985df9adcb@mail.gmail.com>
	<1217441261.7864.15.camel@voyager>
Message-ID: <003601c8f272$99c5cdd0$cd516970$@net>

You could always build it and package it as a PECL module.  I doubt that it
would gain immediate acceptance as an official distro arm (ie.
--with-mysql), but the PECL path is definitely the first step in doing so,
look at json_encode which was a PECL module before the AJAX-coinage frenzy
just prior to PHP 5.2.

SSIs are usually required when a mechanism is very process intensive
(creating PDFs, manipulating native mechanisms, etc).  OpenID revolves
around HTTP payloads which PHP can handle very easily with its existing
stream abstraction (and in the case of postbacks, is even moreso handled by
the webserver).  I (personally) wouldn't see the benefit in going 'native'
with something like this, if all it saves you is an include or require_once
statement -- so there would have to be a great appeal that supersedes simple
"convenience".  Loading up the JanRain classes is hardly inconvenient... and
quite a few individuals on shared servers would probably be denied any PECL
modules.

Not one to deter developments though, I really do wish you good luck!  Do
post again if you get a PECL module (a Pickle) started or something of the
sort. (http://pecl.php.net) 

Cheers!
Alex

-----Original Message-----
From: dev-bounces at lists.openidenabled.com
[mailto:dev-bounces at lists.openidenabled.com] On Behalf Of Anders Feder
Sent: Wednesday, July 30, 2008 2:08 PM
To: discuss OpenID libraries and development
Subject: Re: OpenID PHP extension

ons, 30 07 2008 kl. 09:01 -0700, skrev Jonathan Daugherty:
> > Is there such a thing as a native OpenID PHP extension - meaning not one
> > implemented in the PHP language itself, but a compiled extension module
> > adding OpenID functions to PHP (similarly e.g. to the MySQL extension).
> 
> Not that I know of.
> 

How come? Would this not be tremedously useful? If it was provided as
part of the standard PHP distribution (like the MySQL extension),
websites would have OpenID right at their fingertips (no downloads, no
includes, no other special module dependencies). From the perspective of
OpenID, it would let the standard profilerate much faster.

Might there be any interest in such an extension if I were to look into
developing one?

-- 
Anders Feder <lists.anders at feder.dk>


_______________________________________________
Dev mailing list
Dev at lists.openidenabled.com
http://lists.openidenabled.com/mailman/listinfo/dev



From wp at mcc.org  Wed Jul 30 13:02:10 2008
From: wp at mcc.org (Wesley Penner)
Date: Wed, 30 Jul 2008 16:02:10 -0400
Subject: AUTO: Wesley Penner/MCC is on vacation (returning 08/04/2008)
Message-ID: <OFA28B0E35.95A485BC-ON85257496.006E0FD1-85257496.006E0FD1@mcc.org>


I am out of the office until 08/04/2008.

I will respond to your message when I return.


Note: This is an automated response to your message  "Dev Digest, Vol 30,
Issue 2" sent on 7/30/2008 10:40:02 AM.

This is the only notification you will receive while this person is away.



From david at davidcann.com  Wed Jul 30 16:52:19 2008
From: david at davidcann.com (David Cann)
Date: Wed, 30 Jul 2008 19:52:19 -0400
Subject: OpenID PHP extension
In-Reply-To: <1217441261.7864.15.camel@voyager>
References: <1217424029.7864.3.camel@voyager>
	<e56baffa0807300901w5290dceamd06479985df9adcb@mail.gmail.com>
	<1217441261.7864.15.camel@voyager>
Message-ID: <E8065040-3A1B-4234-8253-A463C0313760@davidcann.com>

> How come? Would this not be tremedously useful? If it was provided as
> part of the standard PHP distribution (like the MySQL extension),
> websites would have OpenID right at their fingertips (no downloads, no
> includes, no other special module dependencies). From the  
> perspective of
> OpenID, it would let the standard profilerate much faster.
>
> Might there be any interest in such an extension if I were to look  
> into
> developing one?

I think there would be.  A built-in relying party module would be most  
useful.  It's difficult to convince employers to commit any  
development time to integrating OpenID, so anything that makes the  
process faster and more standardized helps.
-d



From saeven at saeven.net  Wed Jul 30 16:59:08 2008
From: saeven at saeven.net (S. Alexandre M. Lemaire)
Date: Wed, 30 Jul 2008 19:59:08 -0400
Subject: OpenID PHP extension
In-Reply-To: <E8065040-3A1B-4234-8253-A463C0313760@davidcann.com>
References: <1217424029.7864.3.camel@voyager>	<e56baffa0807300901w5290dceamd06479985df9adcb@mail.gmail.com>	<1217441261.7864.15.camel@voyager>
	<E8065040-3A1B-4234-8253-A463C0313760@davidcann.com>
Message-ID: <000601c8f2a0$41dcaed0$c5960c70$@net>

Again, I strongly doubt that Zend would fork this into PHP though - they
have already published an OpenID class kit for their Zend Framework.

http://framework.zend.com/manual/en/zend.openid.html

> It's difficult to convince employers to commit any
> development time to integrating OpenID, so anything that makes 
> the process faster and more standardized helps.

Any reasonable employer would certainly not object to usage of ZF's OpenID
if you want "commercial backing" behind component use.  ZF is actually
pretty good!




-----Original Message-----
From: dev-bounces at lists.openidenabled.com
[mailto:dev-bounces at lists.openidenabled.com] On Behalf Of David Cann
Sent: Wednesday, July 30, 2008 7:52 PM
To: discuss OpenID libraries and development
Subject: Re: OpenID PHP extension

> How come? Would this not be tremedously useful? If it was provided as
> part of the standard PHP distribution (like the MySQL extension),
> websites would have OpenID right at their fingertips (no downloads, no
> includes, no other special module dependencies). From the  
> perspective of
> OpenID, it would let the standard profilerate much faster.
>
> Might there be any interest in such an extension if I were to look  
> into
> developing one?

I think there would be.  A built-in relying party module would be most  
useful.  It's difficult to convince employers to commit any  
development time to integrating OpenID, so anything that makes the  
process faster and more standardized helps.
-d


_______________________________________________
Dev mailing list
Dev at lists.openidenabled.com
http://lists.openidenabled.com/mailman/listinfo/dev



From will at willnorris.com  Thu Jul 31 10:18:16 2008
From: will at willnorris.com (Will Norris)
Date: Thu, 31 Jul 2008 10:18:16 -0700
Subject: Why the 1MB fetcher limit
Message-ID: <2B37C2AD-DFCF-4261-B3CF-A86D5F867189@willnorris.com>

We're running into some issues in WordPress, where a plugin called  
"Bad Behavior" is not liking the "Range: bytes=0-1048576" header php- 
openid is adding to fetch requests.  Before I push too hard in either  
direction on what needs to be fixed to correct this, I was wondering  
what the rationale was for adding this request header.  Why limit  
responses to 1MB?  Was this an arbitrary size, or was there some logic  
to it?  Why was this added in the first place?  Was the absence of  
such a limit causing real problems?  I'm not necessarily saying it  
shouldn't be there, I would just like to understand what the thinking  
was.

I see from the changelog that Dag added this to the php library on May  
29th... hoping he or someone else could add some insight.

Thanks,
Will


From andrewarnott at gmail.com  Thu Jul 31 12:42:44 2008
From: andrewarnott at gmail.com (Andrew Arnott)
Date: Thu, 31 Jul 2008 12:42:44 -0700
Subject: Why the 1MB fetcher limit
In-Reply-To: <2B37C2AD-DFCF-4261-B3CF-A86D5F867189@willnorris.com>
References: <2B37C2AD-DFCF-4261-B3CF-A86D5F867189@willnorris.com>
Message-ID: <216e54900807311242xfaaefe8m68545a44dd4cf8@mail.gmail.com>

It's very likely there to prevent DoS attacks.  Since an RP has to fetch
data from arbitrary URLs, an attack where Identifiers that send hundreds of
megabytes to the requester could be automated toward an RP and very quickly
bring it down.  A limitation of 1MB helps mitigate this.

I didn't add this code to PHP though, so I can't say for sure that that is
why it is there.

On Thu, Jul 31, 2008 at 10:18 AM, Will Norris <will at willnorris.com> wrote:

> We're running into some issues in WordPress, where a plugin called
> "Bad Behavior" is not liking the "Range: bytes=0-1048576" header php-
> openid is adding to fetch requests.  Before I push too hard in either
> direction on what needs to be fixed to correct this, I was wondering
> what the rationale was for adding this request header.  Why limit
> responses to 1MB?  Was this an arbitrary size, or was there some logic
> to it?  Why was this added in the first place?  Was the absence of
> such a limit causing real problems?  I'm not necessarily saying it
> shouldn't be there, I would just like to understand what the thinking
> was.
>
> I see from the changelog that Dag added this to the php library on May
> 29th... hoping he or someone else could add some insight.
>
> Thanks,
> Will
>
> _______________________________________________
> Dev mailing list
> Dev at lists.openidenabled.com
> http://lists.openidenabled.com/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080731/a99eefb2/attachment.htm 

From cygnus at janrain.com  Thu Jul 31 13:29:33 2008
From: cygnus at janrain.com (Jonathan Daugherty)
Date: Thu, 31 Jul 2008 13:29:33 -0700
Subject: Why the 1MB fetcher limit
In-Reply-To: <2B37C2AD-DFCF-4261-B3CF-A86D5F867189@willnorris.com>
References: <2B37C2AD-DFCF-4261-B3CF-A86D5F867189@willnorris.com>
Message-ID: <e56baffa0807311329t1ca49360sd529b88a9c69c049@mail.gmail.com>

> Why limit
> responses to 1MB?  Was this an arbitrary size, or was there some logic
> to it?  Why was this added in the first place?  Was the absence of
> such a limit causing real problems?

As Andrew pointed out, we're using it to prevent accidental DoS.  We
did have a few cases come up in the wild.  So yes, it was causing
problems for some RPs.  In some cases it may also avoid problems when
attempting to parse identity URL responses with PCRE.  I can
understand why Bad Behavior might consider that a typical bot feature,
but I don't think it makes sense to remove it from the libraries.

-- 
 Jonathan Daugherty


From docwhat at gmail.com  Thu Jul 31 13:52:41 2008
From: docwhat at gmail.com (Christian Holtje)
Date: Thu, 31 Jul 2008 16:52:41 -0400
Subject: Why the 1MB fetcher limit
In-Reply-To: <e56baffa0807311329t1ca49360sd529b88a9c69c049@mail.gmail.com>
References: <2B37C2AD-DFCF-4261-B3CF-A86D5F867189@willnorris.com>
	<e56baffa0807311329t1ca49360sd529b88a9c69c049@mail.gmail.com>
Message-ID: <3370A3BF-89D0-4FE4-91FF-033ACE04A088@gmail.com>

On Jul 31, 2008, at 4:29 PM, Jonathan Daugherty wrote:
>> Why limit
>> responses to 1MB?  Was this an arbitrary size, or was there some  
>> logic
>> to it?  Why was this added in the first place?  Was the absence of
>> such a limit causing real problems?
>
> As Andrew pointed out, we're using it to prevent accidental DoS.  We
> did have a few cases come up in the wild.  So yes, it was causing
> problems for some RPs.  In some cases it may also avoid problems when
> attempting to parse identity URL responses with PCRE.  I can
> understand why Bad Behavior might consider that a typical bot feature,
> but I don't think it makes sense to remove it from the libraries.

But how does it prevent against DoS?  I can write a web server that  
sends gigs of crap and ignores RANGE headers.  What you want is the  
receiver to close the connection after 1MB.  Don't depend on the sender.

Ciao!


From lists.anders at feder.dk  Thu Jul 31 14:05:05 2008
From: lists.anders at feder.dk (Anders Feder)
Date: Thu, 31 Jul 2008 23:05:05 +0200
Subject: OpenID PHP extension
In-Reply-To: <000601c8f2a0$41dcaed0$c5960c70$@net>
References: <1217424029.7864.3.camel@voyager>
	<e56baffa0807300901w5290dceamd06479985df9adcb@mail.gmail.com>
	<1217441261.7864.15.camel@voyager>
	<E8065040-3A1B-4234-8253-A463C0313760@davidcann.com>
	<000601c8f2a0$41dcaed0$c5960c70$@net>
Message-ID: <1217538305.6746.24.camel@voyager>

ons, 30 07 2008 kl. 19:59 -0400, skrev S. Alexandre M. Lemaire:
> Again, I strongly doubt that Zend would fork this into PHP though - they
> have already published an OpenID class kit for their Zend Framework.

Is Zend in control of the main PHP distribution though? Besides, the ZF
OpenID package seems to implement OpenID 2.0 draft 11 which is more than
a year old. OpenID has moved since then and the more OpenID grows, the
more an inclusion in the main distribution is warranted.

> > It's difficult to convince employers to commit any
> > development time to integrating OpenID, so anything that makes 
> > the process faster and more standardized helps.
> 
> Any reasonable employer would certainly not object to usage of ZF's OpenID
> if you want "commercial backing" behind component use.  ZF is actually
> pretty good!

It's not so much a matter of "backing" as a matter of "it just works"
and having it as "standard curriculum" for PHP developers.

Seeing that PHP includes a few quite arguably more obscure extensions
(GeoIP? RPM Reader?) I don't think its entirely impossible to imagine
OpenID support being included. User (identity) management is a near
universal problem for web developers in these web 2.0 days and a native
OpenID extension would solve much of just that problem.

-- 
Anders Feder <lists.anders at feder.dk>



From kevin at janrain.com  Thu Jul 31 14:23:43 2008
From: kevin at janrain.com (Kevin Turner)
Date: Thu, 31 Jul 2008 14:23:43 -0700
Subject: Why the 1MB fetcher limit
In-Reply-To: <3370A3BF-89D0-4FE4-91FF-033ACE04A088@gmail.com>
References: <2B37C2AD-DFCF-4261-B3CF-A86D5F867189@willnorris.com>
	<e56baffa0807311329t1ca49360sd529b88a9c69c049@mail.gmail.com>
	<3370A3BF-89D0-4FE4-91FF-033ACE04A088@gmail.com>
Message-ID: <201e81ff0807311423v5ad3368xb24b6875192ce807@mail.gmail.com>

On Thu, Jul 31, 2008 at 1:52 PM, Christian Holtje <docwhat at gmail.com> wrote:
> I can write a web server that
> sends gigs of crap and ignores RANGE headers.  What you want is the
> receiver to close the connection after 1MB.  Don't depend on the sender.

And that's what we've done for the http library implementations that
provide a hook that lets us do it.  (i.e. libcurl)  For the
installations without curl, we're using the Range header to provide
limits in at least some cases.  If it turns out that's doing more harm
than good, we may have to reverse that change.