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
system properties
auth.username and auth.password.
If both of these are set, then instead of asking on the console
for login credentials, they will be taken from the property values,
for instance
stilts -Dauth.username=foo -Dauth.password=@~/passwd.txt
tpipe in=https://secret.com/data.vot
would 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.
Some TAP services offer optional authentication;
anonymous access is permitted, but users who log in may
benefit from restricted data or enhanced resource limits.
By default, the TAP access commands
(tapquery,
taplint,
tapskymatch and
tapresume)
will use anonymous access by default in this case.
But if you prefer to use the service in authenticated mode,
you can supply the auth=true
parameter and an attempt will be made to log in before use.
There is currently no way to log in to non-TAP VO services that provide optional authentication; however at time of writing I'm not aware of any.
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.