[foaf-protocols] openid4.me and foafssl.org on chromium

Henry Story henry.story at gmail.com
Fri Aug 13 14:21:48 CEST 2010

On 13 Aug 2010, at 13:30, Kingsley Idehen wrote:

> Henry Story wrote:
>> [snip]
>> This is how you duplicate the problem Kingsley.
>> for b a browser in ( Chromium Firefox Safari Opera ) {
>>  start $b
>>  println("Using Browser "+$b.getName()")
>>  make sure $b has a working foaf+ssl cert
>>  List urls = [ URL("https://foaf.me/simpleLogin.php")
>>                URL("https://openid4.me/")
>>                URL("https://foafss.org/srv/idp") 
>>                ...
>>              ]
>>  for u in urls {
>>     if $b.connectTo( $u )
>>        println("Success for "+ $u)
>>     else 
>>        println("Failure for "+ $u)
>>     end
>>  }
>> }
>> You will find that 
>> - for all browsers except Chromium, you can successfully access https://foaf.me/simpleLogin.php and https://openid4.me/
>> - all browsers including chromium can access
>>   https://foafssl.org/srv/idp
>> So the issue is now to understand what is it that Chromium is having
>> trouble with on the foaf.me and openid4.me sites.
> Henry,
> How are <https://id.myopenlink.net/ods>,  
> <https://foaf.me/simpleLogin.php>, and <https://openid4.me/> different?

I can connect with all browsers except Chromium to all of them.
With Chromium I cannot access the last two. I get the following

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssl-error.jpg
Type: image/jpg
Size: 39828 bytes
Desc: not available
Url : http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100813/a4aef6b6/attachment-0001.jpg 
-------------- next part --------------

> I replicate the problem successfully by simply using:
> <https://foaf.me/simpleLogin.php> or <https://openid4.me/> instead of 
> <http://id.myopenlink.net/ods> .

With what browser are you accessing those urls? You mean you get
the same "SSL Connection error" page as I get and is illustrated above?

> Thus, if two fail and one succeeds, and the two in question aren't the 
> definitive standards, how is the browser at fault?

It is not clear that the browser is at fault and I have not said that it was. The issue is that something is problematic with foaf.me and openid4.me when used on Chromium. Other browsers succeed on the same connection. 

I was asking if there was a bug report open for this on Chromium or if anyone knew what the issue is. If we are having this problem now, and it is a browser bug we should help them fix it while it is in development. If it is a foaf.me issue, we should document the problem clearly, so others can avoid it.

> I can understand if 
> all 3 fail, for instance. I want interop to produce common behavior i.e. 
> we all fail or succeed when performing the same tests.
> Here are two other URLs from the same Data Space:
> 1. https://id.myopenlink.net/php/users/users.php -- PHP
> 2. https://id.myopenlink.net/vsp/users/users.vsp -- VSP (Virtuoso Server 
> Pages basically our equivalent of PHP, JSP, and ASP) .

I am able to connect to them with Chromium. So those confirm the oddness of the issue.

(Note that they ask me for my server certificate, but none of them
then greets me by name, using the info available in the foaf)

> What I did notice re. PHP based on log output is this:
> 07:16:59 PHP Warning:  fsockopen() [<a 
> href='function.fsockopen'>function.fsockopen</a>]: unable to connect to 
> ssl://id.myopenlink.net:443 (Unable to find the socket transport 
> &quot;ssl&quot; - did you forget to enable it when you configured PHP?) 
> in /opt/virtuoso/vsp/vad/vsp/wa/users/users.php on line 73

This seems to be a completely different issue Kingsley. Or are you bringing this up because you are using the same code base as foaf.me or openid4.me ?


More information about the foaf-protocols mailing list