Error handler in Filter.call assumes presence of deprecated user[:id] node

[chrisrbnelson]

A few of our Castle filter requests timed out, and then the error handler inside Castle::Api::Filter.call itself failed trying to build a fallback response because it assumes the options provided include a { user: { id: 'x' } } node.

From the API docs it shows that user node is deprecated didn't include a id node anyway. matching_user_id would be used instead, though this is also itself optional so the error handler can't assume it'll be available.

For reference the filter request we were making was for "login attempted" and the payload was as below:

{
  type: "$login",
  status: "$attempted",
  authentication_method: { type: "$password" },
  params: { email: "foo@bar.com" },
  request_token: "xxx",
  context: { 
    ip: "xxx",
    headers: { ... }
  },
}

[mdmccoy]

I recently ran into this issue as well. It's really weird to me that the error handler is referencing this user object, since one of the scenarios where someone fails to login could be that the user doesn't exist.