Where STIL is given an HTTP/HTTPS URL to read,
typically for table input,
in most cases it reads the resource via methods of the
rather than with a direct
URL.openStream() or similar.
This has the effect of managing authentication in cases where
authentication requirements are specified in VO-compliant
ways by the remote service.
The default behaviour in this case is simply to deny access to
resources for which authentication is required, but if a non-trivial
UserInterface object is
installed on the
the user will be queried for credentials when a recognised
authentication challenge is encountered, and subsequent
access will be granted if authentication and authorization
This user interaction and negotiation of authentication is invisible to STIL client code and requires no action other than an initial setup of the preferred user interface. This is typically done as follows:
AuthManager.getInstance().setUserInterface( UserInterface.CLI );This invocation would install a command-line user interface, so that the user would be queried on the console for username and password when required. Other
can be used instead.
If no such setup is done
(or equivalently following
STIL should behave just as if URLs are dereferenced in the usual way.
However, the access is still being handled by the
in this case, so unforseen differences in behaviour are not impossible.
These authentication arrangements in STIL are new at version 4.2,
and rely on VO standards that are still under discussion.
The API and behaviour may change in future releases,
and at time of writing not all data services that provide authentication
advertise it in a way that STIL can work with.
It is hoped that authentication interoperability
will improve in future versions of STIL and of server-side software.
The authentication management is currently handled by the
uk.ac.starlink.auth package bundled with STIL,
but the AUTH package may be split off into a standalone product at some
point in the future.