Submitting wildly invalid assertions to /verify causes a 500 server error

[ianb]

I accidentally pointed my mock assertions at BrowserID (things like the literal string "test@example.com", which isn't base64, JSON, JWT) and I get a 500 error. It should return a proper error message.

[lloyd]

this is lame. in general the verifier needs hardening and love. it should return extremely helpful errors to end users, given this will affect our cost of supporting it significantly.

I say 4 stars.

[jbonacci]

Ran backend unit tests on local install. Did not see anything unusual.

[ianb]

Do the unit tests submit something that isn't valid JWT, or once
JWT-decoded is not valid JSON?
On Dec 5, 2011 8:07 PM, "jbonacci" <
reply@reply.github.com>
wrote:

Ran backend unit tests on local install. Did not see anything unusual.

---

Reply to this email directly or view it on GitHub:
#598 (comment)

[lloyd]

Both.

--lloyd

On Dec 5, 2011, at 8:44 PM, Ian Bickingreply@reply.github.com wrote:

Do the unit tests submit something that isn't valid JWT, or once
JWT-decoded is not valid JSON?
On Dec 5, 2011 8:07 PM, "jbonacci" <
reply@reply.github.com>
wrote:

Ran backend unit tests on local install. Did not see anything unusual.

---

Reply to this email directly or view it on GitHub:
#598 (comment)

---

Reply to this email directly or view it on GitHub:
#598 (comment)

[ianb]

This breaks on browserid but works on diresworb:

curl https://browserid.org/verify -d 'assertion=xxxx&audience=localhost'

I'm guessing that means it is fixed.

[lloyd]

Will roll into prod on thurs

--lloyd

On Dec 6, 2011, at 2:35 PM, Ian Bickingreply@reply.github.com wrote:

This breaks on browserid but works on diresworb:

curl https://browserid.org/verify -d 'assertion=xxxx&audience=localhost'

I'm guessing that means it is fixed.

---

Reply to this email directly or view it on GitHub:
#598 (comment)