Michael Jumper commented on GUACAMOLE-355:

I now have some insight.

The thing which was originally throwing me (haaaaaaaa it's an exception joke) 
was that {{FileNotFoundException}} is a checked exception, and shouldn't be 
getting all the way out through the {{authenticate()}} call (which can only 
throw {{GuacamoleException}}). The reason this is possible is that the CAS 
client code rethrows everything as a {{RuntimeException}} so they don't have to 
declare their functions as throwing anything ... which is annoying to say the 


This ultimately means that the exception behavior of these functions is 
undocumented, and the compiler will not warn us about unhandled error 
conditions. Things will just break without warning.

We'll need to search through the parts of our CAS code to find where any 
org.jasig functions are called, and explicitly catch the unchecked exceptions 
they throw, rethrowing (and logging) them in a sane way.

> CAS Module Missing Error Handling
> ---------------------------------
>                 Key: GUACAMOLE-355
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-355
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacamole-auth-cas
>    Affects Versions: 0.9.13-incubating
>            Reporter: Nick Couchman
>            Assignee: Nick Couchman
>         Attachments: castrace.txt
> As reported by Kaushnik on the dev mailing list, attempting to use the 
> guacamole-auth-cas module with an incorrect CAS authentication endpoint 
> results in very generic and not very useful 500 Internal Server errors rather 
> than meaningful messages that point the user in the right direction for 
> correcting the error.  Need to see if the CAS framework has any built-in 
> error checking facilities and try to leverage those, or at least throw some 
> more meaningful Guacamole errors when we run into problems.

This message was sent by Atlassian JIRA

Reply via email to