Developer info missing apropos "no certificates provided"

[Lars Gunther]

Hello

As I said in an earlier message to this list, I am using Persona on
http://webbteknik.nu/

I am also contracted to write a book on server side scripting to be used
in the "gymnasium" (approx sen. high) in Sweden. I intend to include a
chapter on Persona in that book.

However, I badly need a FAQ page for common problems. Right now I get
this reply back on my development machine, when verifying an assertion,
using cURL in PHP:

status = "failure",
reason = "no certificates provided"

I have not made any drastic changes to my PHP-script, and it used to
work perfectly.

My code is at
https://github.com/itpastorn/webbteknik/blob/master/website/html/api/login.php

The relevant lines are 50-66 and 125- for following up on the failure.

Except for not having written a clean OO-class, I am basically not doing
anything different from this example:

https://github.com/raymondjavaxx/php5-browserid/blob/master/libraries/browserid/Verifier.php

I think the project would benefit from having a FAQ-page, where errors
like the above are explained.


BTW, if anyone would like to help me personally, it would be appreciated.


--
Lars Gunther
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/

[Lars Gunther]

Hello

I got help through IRC from stomlinson and lloyd...

Turns out that urlencode in PHP was the culprit. It messed up the
assertion and the error message is just plain bad. A bug has been opened.

[Lloyd Hilaiel]

Time for a thursday call to action!

This is lame. Our error message here didn't do Lars any favors. When a malformed string is passed to the verifier we say "no certificates found" back to the person who is trying to adopt persona.

I filed a bug, it's trivial to make it so the next community member who goes to use persona has a better experience:

https://github.com/mozilla/jwcrypto/issues/54

Integrating the new version of jwcrypto that does a better job of telling you what went wrong will require updating verifier tests in browserid repo.

I think this is 2 person hours or so. fmarier? bwarner? got some time? I volunteer to review and merge or even update verifier tests and add new cases of malformed assertions.

can haz better?

lloyd

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

[Sean McArthur]

While we're in there, might as well make sure everything thrown is an Error
object, and not a string. <3 stack traces.

[Lars Gunther]

Hi again

A few extra considerations.

The underlying problem I had was that urlencode in PHP turns tildes into %7E

1. Up until recently, that was not a problem, suddenly it has become one.

2. I got the idea to use urlencode from libraries, that the
documentation was linking to. Though not being an official spec, it
should be noted in the code that urlencoding will break the assertion.

Better yet, accept urlencoded data...?

3. The PHP-example given in the remote verification API uses raw posted
data, read from the $_POST superglobal array. With the addition of
filters in PHP 5.2, it is recommended to use code like this:

$assertion = filter_input(
INPUT_POST,
'assertion',
FILTER_UNSAFE_RAW,
FILTER_FLAG_STRIP_LOW|FILTER_FLAG_STRIP_HIGH
);

The flags will remove all ASCII control characters (below 0-31) and
anything above 127. I will update the doc, but please verify that an
assertion never, ever will contain a character not within this range.


Thanks for all help!



1. https://developer.mozilla.org/en-US/docs/Persona/Remote_Verification_API

2012-11-08 17:58, Lloyd Hilaiel skrev:
> Time for a thursday call to action!
>
> This is lame. Our error message here didn't do Lars any favors. When a
> malformed string is passed to the verifier we say "no certificates
> found" back to the person who is trying to adopt persona.
>
> I filed a bug, it's trivial to make it so the next community member who
> goes to use persona has a better experience:
>
> https://github.com/mozilla/jwcrypto/issues/54
>
> Integrating the new version of jwcrypto that does a better job of
> telling you what went wrong will require updating verifier tests in
> browserid repo.
>
> I think this is 2 person hours or so. fmarier? bwarner? got some time?
> I volunteer to review and merge or even update verifier tests and add
> new cases of malformed assertions.
>
> can haz better?
>
> lloyd

[Francois Marier]

On 09/11/12 06:40, Lars Gunther wrote:
> 3. The PHP-example given in the remote verification API uses raw posted
> data, read from the $_POST superglobal array. With the addition of
> filters in PHP 5.2, it is recommended to use code like this:
>
> $assertion = filter_input(
> INPUT_POST,
> 'assertion',
> FILTER_UNSAFE_RAW,
> FILTER_FLAG_STRIP_LOW|FILTER_FLAG_STRIP_HIGH
> );
>
> The flags will remove all ASCII control characters (below 0-31) and
> anything above 127. I will update the doc, but please verify that an
> assertion never, ever will contain a character not within this range.

Thanks for pointing that out, we should make sure that we submit bugs or
pull requests when we notice third-party libraries that do the wrong
thing. Otherwise developers that base their code on them will have problems.

Based on what you said above, would you be able to suggest a fix for the
example we have in the cookbook?


https://github.com/mozilla/browserid-cookbook/blob/master/php/browserid.php#L61

I'm not familiar with that new input filtering stuff in PHP, but I'll be
happy to test and merge any pull requests.

Cheers,
Francois

[Lars Gunther]

2012-11-09 03:09, Francois Marier skrev:
> Based on what you said above, would you be able to suggest a fix for the
> example we have in the cookbook?
>
>
> https://github.com/mozilla/browserid-cookbook/blob/master/php/browserid.php#L61
>
> I'm not familiar with that new input filtering stuff in PHP, but I'll be
> happy to test and merge any pull requests.

I've opened https://github.com/mozilla/browserid-cookbook/issues/13

Expect pull requests.



PS. Thunderbird says my account can't send to the News-server...

[Lars Gunther]

Hi again

Having forked and tested the cookbok, I see that it uses urlencode() for
the assertion AND IT WORKS!

https://github.com/mozilla/browserid-cookbook/blob/master/php/browserid.php#L63

Further investigation is clearly necessary.

2012-11-09 13:05, Lars Gunther skrev:
> 2012-11-09 03:09, Francois Marier skrev:

>> Based on what you said above, would you be able to suggest a fix for the
>> example we have in the cookbook?
>>
>>
>> https://github.com/mozilla/browserid-cookbook/blob/master/php/browserid.php#L61
>>
>>
>> I'm not familiar with that new input filtering stuff in PHP, but I'll be
>> happy to test and merge any pull requests.
>

> I've opened https://github.com/mozilla/browserid-cookbook/issues/13
>
> Expect pull requests.
>
>
>
> PS. Thunderbird says my account can't send to the News-server...
>
>

[Lars Gunther]

2012-11-09 13:46, Lars Gunther skrev:
> Hi again
>
> Having forked and tested the cookbok, I see that it uses urlencode() for
> the assertion AND IT WORKS!
>
> https://github.com/mozilla/browserid-cookbook/blob/master/php/browserid.php#L63
>
>
> Further investigation is clearly necessary.

Here are the results of my testing.

When sending the audience and assertion using regular HTTP POST, one
MUST urlencode both values in PHP.

When sending the same data as JSON, one MUST NOT urlencode either value
in PHP.

Libraries that exist on GitHub and that are getting links from MDN, gets
this wrong.


Now, is this a stable "feature" of Persona?