authenticate() could throw an AuthenticationFailedError, and the client can catch this to show a login form.
\nCurrently it doesn't work, the client receives a generic Error object. The docs confirm this: only \"Error and its well-known subclasses are passed as-is\"
","upvoteCount":1,"answerCount":2,"acceptedAnswer":{"@type":"Answer","text":"In general, we intentionally do not support custom pass-by-value types. All custom types must be pass-by-reference. This includes custom Error subclasses.
\nThe reason for this is because custom serializable types have proven to be a security disaster in Java and other languages. It's just too easy to create a custom serializable type which inadvertently allows an attacker to trick the remote party into doing unsafe things, by sending an instance of that type when it isn't expected.
\nWhat we can do, though, is:
\n- \n
- Override
error.nameto match the custom type (\"AuthenticationFailedError\") even if the class becomes justError. \n - Serialize any additional own properties placed on the error object, so you can communicate additional details via properties. \n
I had intended to do both of these things but it looks like it's still marked as a TODO in the code.
\nWith all that said, I would probably recommend having authenticate() return null on failure, or something like that. It's a style preference but I generally recommend throwing exceptions only for unexpected problems for which there's nothing you can do -- not for situations where you want the client to take a specific action, like redirecting to a login page.
-
|
Is it possible to define custom error classes and throw them over the wire? Take your authentication example: authenticate() could throw an AuthenticationFailedError, and the client can catch this to show a login form. Currently it doesn't work, the client receives a generic Error object. The docs confirm this: only "Error and its well-known subclasses are passed as-is" |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
In general, we intentionally do not support custom pass-by-value types. All custom types must be pass-by-reference. This includes custom Error subclasses. The reason for this is because custom serializable types have proven to be a security disaster in Java and other languages. It's just too easy to create a custom serializable type which inadvertently allows an attacker to trick the remote party into doing unsafe things, by sending an instance of that type when it isn't expected. What we can do, though, is:
I had intended to do both of these things but it looks like it's still marked as a TODO in the code. With all that said, I would probably recommend having |
Beta Was this translation helpful? Give feedback.
-
|
I like to use an exception in this example, we're not awaiting authenticate() so we don't get to see its result until after whoami (which would either have to throw, or also return an error object). Another example would be a resource that's temporarily unavailable. The client could decide to retry after a while. Instead of throwing, I could explicitly return an error result from each function, but in a pipelined series of operations I don't see how I could handle this without awaiting each intermediate result. I managed to work around the limitation by throwing a non-error object over the wire, and wrapping my calls in a catch/retrow to convert back to the original error class. This works, so it's not a big deal, but it's not as clean as I would like. Thanks for your reply. This is great work, I really like it and I saw it just in time for my current project! |
Beta Was this translation helpful? Give feedback.
-
|
You could have I'm not saying this is necessarily better, though! Just pointing out it is a thing you can do. |
Beta Was this translation helpful? Give feedback.
-
|
Yes I see what you mean. Thanks for replying! |
Beta Was this translation helpful? Give feedback.
In general, we intentionally do not support custom pass-by-value types. All custom types must be pass-by-reference. This includes custom Error subclasses.
The reason for this is because custom serializable types have proven to be a security disaster in Java and other languages. It's just too easy to create a custom serializable type which inadvertently allows an attacker to trick the remote party into doing unsafe things, by sending an instance of that type when it isn't expected.
What we can do, though, is:
error.nameto match the custom type ("AuthenticationFailedError") even if the class becomes justError.