posting an assertion should not require URL-encoded data

[timbertson]

In /_browserid/main.js, the gotVerifiedEmail function makes a POST to _browserid with the assertion data & audience. The function uses window.encodeURIComponent on the value of each JSON key. This doesn't make any sense (it's JSON, not a form submission).

The function that uses this data in verify_id_with_crutch should be the one to urlencode this data before sending the request to browserid.org, otherwise all clients posting to _browserid will have to replicate this behaviour.

[jhs]

Interesting. I believe it does it that way because I simply started by copying and pasting the example code from browserid.org and going from there.

Is the format because it's using multipart/form-data or application/x-www-form-urlencoded to be more convenient for HTML forms? Is there any argument at all for the encoding? Is it dissimilar from other BrowserID implementations (although it's not like the Django browserid code would work on Couch anyway, with the latter's /_browserid url and probably other things.)

[timbertson]

Well I'm not sure where you copied it from, it's likely anything that used encodeURIComponent was posting application/x-www-form-urlencoded to the server (typical GET/POST). Since you're posting JSON data to couchdb, this is unnecessary (JSON.stringify does all the required escaping).

However, on the server side you'll need to use whatever erlang / couch provides in order to send the assertion and audience values as url-encoded data, since that's what browserid accepts. Currently it's working because the client happened to be sending url-encoded data inside JSON encoded data, but that's not something you want to rely on.