Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While testing for writing my documentation at the weekend, I got incredibly jumbled up in how passwords and their escaping were being handled, and how it kept breaking on my test cases. This meant I wasn't happy the documentation I wrote around that was correct. I came at it again fresh at lunch time today, and went through the code to work out what was happening, and found I'd massively over complicated matters, by going around things the wrong way, and mixing myself up.
I started this PR as a plain documentation update, to simplify where I'd gone wrong, but in doing so I spotted a way to reduce the amount of escaping needed to the bare minimum. I've added a new function to backup.sh called
prepare_login_json
, that constructs the json we're sending to the server, and writing it to a file.curl
has the ability to read the data it isPOST
-ing from a file, which skips the need to manually create the json on the command line, with all the quote escaping that requires.The function to create the json file should also be safe and not need any escaping, because first it uses
printf
to create the two keyvalue pairs we care about (loginMethod: password, and password: $ACTUAL_BUDGET_PASSWORD) concatenated with theNUL
character. This is then piped tojq
, which splits the strings onNUL
s, and then encodes each pair itself into valid json, that gets redirected to a temp file. BecauseNUL
can never exist in a password, this always ends up with the full password being written, no matter what symbols are in it.This is a little overkill, as writing it to a file without it needing to pass it on the command line would probably be easy enough to escape manually, but letting
jq
handle correctly encoding the password is much safer IMO, because as a dedicated json tool, it's got way more cover for edge cases than we could ever write.The only other change was to fix a typo in
include.sh
, and remove an errant exclamation mark from the zero-length string test. That was breaking my build while testing, and doesn't appear to be present in the image on Dockerhub, so I'm not sure if something just didn't get built and pushed, but the code here works now, with all the test cases I could throw at it this evening.