I am searching the www and all kinds of resources around robot. I am missing a best practice approach how to handle secrets to ensure that they are always obscured, never logged, and never stored. I wonder if I am missing something? But shouldn’t this be a basic feature?
E.G. on command line I would expect that some like following exists:
Thank you for confirming that this is the best way to do it.
But this means that I manually have to take care to remove all effected keywords. So, it is just a question of time till I miss one. This could lead to exposing secrets inside a CI system for weeks till I notice. And by removing the keyword I also remove insensitive data which might help debugging stuff. It feels like a workaround. What do you think?
It depends on the library you are using to test you app with, Some libraries have keywords like Input Password or Fill Secret, so no workaround needed
How many applications do you have in your organization? most only have half a dozen at most, so create a resource file for your app, put in a generic AppName Login keyword that handles obscuring the password, then use that keyword for the login on all your tests, you’ll probably end up with a bunch of generic application keywords, like, log out and navigation keywords, basically things you’ll use over and over again in many tests for that application. Basically you leave the Set Log Level NONE line commented out in generic AppName Login keyword while you thoroughly test it for a day or so, then when you’re happy it handles all the various login conditions um-comment that line and use the keyword in all your tests that need to login to that app.
On the CI side, does the CI have template test runners, you could add --variable MySecret:my_secret_value part as part of the template with my_secret_value being replaced with a CI variable from where ever the CI get the secret password value.
There are other ways of dealing with it, but they all seem more cumbersome, here are some of the better examples;
Robot can take various types of variable files, so you could have the CI create a variable file with all the username:passwords combinations for your tests and let robot framework get them from there, and then have the CI delete the file when the test finishes (a bit risky, but not as bad as having the passwords hard coded in the test)
Robot can read Environment variables, if the CI can set environment variables, then you could have a standardized “appname_password” variable that the CI sets, and the AppName Login keyword mentioned above expects to exist and just uses that
Really there is no “Best” way to do things, it’s about what’s best for your organization’s requirements.