You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are various cases where the server will return code 500 (Internal Server Error) to the client because something threw a generic exception or failed in some other way, when what we really want is to handle that case with a proper exception. I don't have an example of such a case right now, but @slifty can probably think of some.
Note this is not related to issue #44, or at least they're not about the same thing. It might, however, be related to issue #19.
The text was updated successfully, but these errors were encountered:
Example of this kind of 500 error: If you don't give a Java-valid date format for any date field, we'll just get a 500 error.
But not all of these cases are about validation. Basically, we should never be returning a 500 error; we should always return something better than that.
Although not documented to do so [1], GoogleIdToken.parse() will
apparently throw a "java.lang.IllegalArgumentException" [2] if the
token is invalid by inspection -- e.g., if it's not formatted
properly. This commit adds a catch for that specific exception, and
furthermore adds a generic exception catch as per issue #62.
After this, going to the "/api/v3/healthcheck/authentication" endpoint
with an "Authorization" header with an invalid value will result in
the response "You are not authenticated" being sent back to the
client, instead of a 500 error.
[1] https://google.github.io/google-api-java-client/releases/1.21.0/\
javadoc/com/google/api/client/googleapis/auth/oauth2/GoogleIdToken.html
[2] http://stackoverflow.com/questions/32489580/\
googleauthutil-returns-accestoken-tokenverifier-expects-idtoken
There are various cases where the server will return code 500 (Internal Server Error) to the client because something threw a generic exception or failed in some other way, when what we really want is to handle that case with a proper exception. I don't have an example of such a case right now, but @slifty can probably think of some.
Note this is not related to issue #44, or at least they're not about the same thing. It might, however, be related to issue #19.
The text was updated successfully, but these errors were encountered: