-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
filter_sensitive_data and secret in URL when URI is used for matching #221
Comments
cc @bretsw |
Problem: an API where the API key is passed as URL parameter. So
|
this doesn't explain why the tests pass on my machine though?! |
Example of a CI build whose artefacts contain a key (sharing now that the key has been made invalid) |
In the artefact testthat.Rout.fail
|
@sckott note that the problem does not happen when there is no environment variable set by GitHub Action https://github.com/bretsw/tidytags/actions/runs/521323642 (this is a fork) |
The first thing that looks odd to me is that they exposed key has quotes around it, Why would it be in quotes? |
yeah weird |
@bretsw To deal with the quotes issue, did you store your opencage key with quotes around it in the Github secrets settings? |
I think this was likely the issue with the OpenCage key. I cleared out my GH secrets and the build seemed to work (at least for OpenCage). Still perhaps not great that a failed build exposed a secret, but helpful to narrow in on the problem |
Sorry for delay on this, have this on the to do list for tomorrow |
No problem! Thanks for tackling |
I don't think this is a bug in vcr's request matching given that this only happened in one test - i'll keep looking of course, but I don't think it's a problem in vcr's matching |
I've been trying to replicate this problem with this dummy R package https://github.com/sckott/fizball - but have not been able to make a key be hidden in the logs but not hidden in the artifacts when there's a test failure any ideas for what to try? |
@sckott the tests/.Rout.fail contains the key https://github.com/maelle/fizball/actions/runs/554705151 🎉 I saved it with quotes see below |
The whole recipe for failure is
the failures are
|
Thanks. I guess one approach is to strip any single or double quotes around a secret before using it - BUT it's possible that a user could have quotes in a secret; seems unlikely a secret would have quotes at beginning and end of the string though. |
one thing I don't understand is why vcr can't recognize the URL i.e. why it can't match when there are quotes? something with the string manipulation doesn't work in that case? Your approach sounds good (removing when there are quotes at the beginning and at the end), but it'd be good to have a warning about the quotes being stripped, with some option to turn this warning off (to be used in the very unlikely case that such quotes are needed). I was also thinking that folks might fix their secret on their own once they try doing real requests (turn vcr off) in a workflow, because their real requests will fail. Also, I need to add screenshots to the book so oprened an issue there: ropensci-books/http-testing#82 |
It's Agree if we strip leading and trailing single/double quotes, then throw a warning about it |
yes sounds good |
It seems to have worked https://github.com/maelle/fizball/actions/runs/631706778 |
thanks for testing |
No description provided.
The text was updated successfully, but these errors were encountered: