Attempt to validate the signature for the SIWEMessage and handle potential errors (unrelated but noticed` siwe` 2.x has much more descriptive error types: https://blob.sh/00a56f.png).
Depends on D6032
Details
Details
Haven't tested just yet but will hardcode some values to try to hit the error cases and make sure things are handled properly.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- master
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| lib/types/siwe-types.js | ||
|---|---|---|
| 110 | Based off of the following TypeScript:  Will type the parts of siwe we use properly via flow-typed later in the stack. | |
| keyserver/src/responders/user-responders.js | ||
|---|---|---|
| 345 | We usually do something more like expired_message for ServerError. It's meant to basically be an error code | |
| keyserver/src/responders/user-responders.js | ||
|---|---|---|
| 345 | Gotcha, was using the values of the ErrorTypes enum as the error messages but will use the "keys" instead (eg expired_message, malformed_session, etc) | |
| keyserver/src/responders/user-responders.js | ||
|---|---|---|
| 336 ↗ | (On Diff #20146) | These { status: 400 } objects don't do anything, do they? |
| keyserver/src/responders/user-responders.js | ||
|---|---|---|
| 336 ↗ | (On Diff #20146) | Not that I know of, I saw that Derek used that pattern so I just went with it... Can remove if they're superfluous which it seems like they are. Based on the comment:  it looks like payload field was initially included for updateEntry and deleteEntry. And looks like we also use it EG for policy acknowledgement stuff.  Doesn't seem like payload is the right place to put the HTTP code nor is it used anywhere. I'll put up a diff removing them. |