Some external data services restrict access to registered users, meaning that you have to log in to use them. If STILTS encounters such a restriction and knows how to try to authenticate to the service in question, it will report on the console the URL for which the access is blocked (and possibly some additional information about the way authentication is being carried out), and ask for entry of a username and password. If authentication is successful, the resource can be retrieved, and so can any other resources from the same place, so if multiple contacts to the same service are required from the same STILTS command/session, only one login attempt should be required.
If user interaction during the command is not suitable,
it is possible to supply a username and password using the
If both of these are set, then instead of asking on the console
for login credentials, they will be taken from the property values,
stilts -Dauth.username=foo -Dauth.password=@~/passwd.txt tpipe in=https://secret.com/data.votwould access the named resource, and if challenged by the service for authentication would supply "
foo" for user name
and the contents of the file at
~/passwd.txt as the password.
Note however that this feature should be used with care,
since it passes private information indiscriminately to any
service that asks for it.
There is currently no way to log in to services that provide optional authentication (like some TAP services that grant enhanced resource limits to authenticated users). This may be added in a future release.
Note: These authentication arrangements in STILTS are new at version 3.4-9, and rely on VO standards that are still under discussion. The behaviour and user interface may change in future releases, and at time of writing not all data services that provide authentication advertise it in a way that STILTS can work with. It is hoped that authentication interoperability will improve in future versions of STILTS and of server-side software.