Trusted Apps Initial Request Phase: Detect and report obvious classes of user input errors.

Establishing the initial trusted app connection requires the user to enter a URL which should be the base URL of another application which would then become a trusted client. The following case uses Confluence as an example of the trusted client and JIRA as the service provider, as with the JIRA issues macro.

The problem with the input is that there are several classes of error that are not nicely handled or reported.

• The user may mistakenly supply os_username and os_password parameters which wrecks the request for the trusted application certificate. The result is that the remote application will return a "login incorrect" page which is attempted to be parsed as a certificate and the one line error suggests the certificate format is unsupported.
• URLs are required to not have any query parameters because the input url is appended with a path to the certificate request action.
• The base URL could be validated by a request to it and looking for an atlassian footer or something.
• RuntimeException is not caught by the ViewTrustedApplications action and can result in a 500 page. There is a Linux JDK 1.6 bug that can occur in cases of authorization challenge responses (401) and can happen if the Confluence instance has the NTLM plugin installed.

Seraph should also have its certificate request protocol improved to enable detection of responses that are not supposed to be certificates.

See also SER-109