ovedpo15 has asked for the wisdom of the Perl Monks concerning the following question:

Hi guys, I need a suggestion from someone experience. I wrote a Perl script that one of the actions does a GET request but you need to provide username and password for that.
The trivial option is to just ask the user for that in runtime, but in that way, the script will not be automatic.
The other idea I had was to use our faceless user to do the GET request but by doing that way you'll need to keep the username and the password hardcoded, also bad idea.
The third idea I had was to use a config file which will contain the username and the password, but that will require additional step and then users will be frightened to keep their password in a file, so it is not so good idea.
I'm looking for a way of somehow performing that GET request. I also the owner of the server-side of the site (written in JS), so I could do changes there too, but not sure which (we want to keep the username-password check).
Thank you.

Replies are listed 'Best First'.
Re: how to hide information in code
by soonix (Chancellor) on Aug 11, 2019 at 13:43 UTC
Re: how to hide information in code
by holli (Abbot) on Aug 11, 2019 at 14:29 UTC
    If you don't want direct user input, the next easiest thing is to take the password from the the command line and or environment variables. That way the password is volatile and you can defer the responsibility to the user and let them decide wether they want to further automate, for example by using a shell script, or not.



    holli

    You can lead your users to water, but alas, you cannot drown them.
Re: how to hide information in code
by jcb (Parson) on Aug 12, 2019 at 03:09 UTC

    Another option is to provide restricted API keys that are associated with accounts in the server's database and are otherwise random numbers. An ordinary UUID can be used for this purpose quite well. The only requirements are that the API key / bearer token / whatever you want to call it be unpredictable and impossible to derive from the account.

    You then simply put the bearer token in the script, and the server authorizes the request based on the token matching an account and also looks up which account based on the token. The token is not valid anywhere else, certainly not for logging in, and is usable only for this particular API GET endpoint.

    In practice, this is how most Web-based logins work. Log in with username/password, receive a "session ID" cookie that is more-or-less what I just described except that it grants full access to the account instead of only one scriptable API endpoint.