parameter containing uri string is interpreted as uri parameter

[DominikTo]

When passing an uri as a string, awscli fetches the content of the uri instead of just using the string value.

Example:

aws ec2 run-instances \
[...] \
--user-data 'https://foo/bar' \
[...] \

Expected result:

• User data should contain the string 'https://foo/bar'.

Actual result:

• User data contains the contents served at that uri (which should only happen if an uri is passed without quotes).

[jamesls]

I agree with your general comment, which is that there should be some way to escape the URI param processing if you want to specify the literal URI string as the value for the parameter.

However, in some shells (such as bash), the shell strips the quotes for an argument before the process is able to access the arguments. For example:

$ python -c "import sys; print(sys.argv)" --test foo --test 'single_qoutes' --test "double quotes"
['-c', '--test', 'foo', '--test', 'single_qoutes', '--test', 'double quotes']

This means that it's not possible to tell which values were originally quoted. If we were to implement this, you'd have to escape the quotes in the shell, which doesn't look quite as nice:

$ python -c "import sys; print(sys.argv)" --test \'escapedquotes\'
['-c', '--test', "'escapedquotes'"]

Perhaps there's some other way a user can specify that an argument not the URI contents? Maybe we could prefix the value with some character? Otherwise we could implement the quotes check provided that users are fine with escaping the quotes in the shell.

[m17kea]

Has anything been done to remedy this? It still remains an issue I believe. If anyone has a workaround other than creating a txt file with the value I would appreciate it

[AlJohri]

this is way way way too magical. please have an option to disable this.

[AlJohri]

switching to https://www.npmjs.com/package/kms-cli for now

[jasonmcaffee]

fyi, for ssm put-parameter param, i found a workaround using the --cli-input-json, that i'm guessing will work for the ec2 command as well:

aws --profile myprofile ssm put-parameter --cli-input-json '{
  "Name": "/some/url/param",
  "Value": "http://google.com",
  "Type": "String",
  "Description": "url"
}'

[toby5box]

This just blind-sided me again, even though I supposedly knew about it, having commented on a related issue before. So here I am at nearly midnight and it's blocking a production push while I try to find a reasonable workaround. I bet this is implicated in more than a couple Sev 2's.

Please fix it, the current behaviour is just too surprising and potentially dangerous.

The quotes idea is misguided though. It should just never fetch the contents of the URL. If that behaviour is desired in some (hard to imagine) situation, then add a different option to do so. Yes I realise backward compatibility is impaired. That's just how bad an idea it was in the first place.

Even more astonishing is that it's not even documented. On the upside, this should really give carte blanche to breaking scripts.

[ASayre]

Good Morning!

We're closing this issue here on GitHub, as part of our migration to UserVoice for feature requests involving the AWS CLI.

This will let us get the most important features to you, by making it easier to search for and show support for the features you care the most about, without diluting the conversation with bug reports.

As a quick UserVoice primer (if not already familiar): after an idea is posted, people can vote on the ideas, and the product team will be responding directly to the most popular suggestions.

We’ve imported existing feature requests from GitHub - Search for this issue there!

And don't worry, this issue will still exist on GitHub for posterity's sake. As it’s a text-only import of the original post into UserVoice, we’ll still be keeping in mind the comments and discussion that already exist here on the GitHub issue.

GitHub will remain the channel for reporting bugs.

Once again, this issue can now be found by searching for the title on: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-The AWS SDKs & Tools Team

This entry can specifically be found on UserVoice at: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168802-parameter-containing-uri-string-is-interpreted-as

[AlJohri]

Adding direct link: https://aws.uservoice.com/forums/598381-aws-command-line-interface

[m17kea]

@ASayre could you please provide a direct link to this feature request in UserVoice so that people finding this issue in an internet search can easily navigate there and up-vote. Thanks

[AlJohri]

@armitagemderivitec

[m17kea]

https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168802-parameter-containing-uri-string-is-interpreted-as

[jamesls]

Based on community feedback, we have decided to return feature requests to GitHub issues.

[jonatcorus]

This is one of those "features" that's such a horrible idea, it's surprising it's not fixed. The feature should have had some kind of prefix like fetch-url:http://example.com. For now there should be a way of turning it off at least by some kind of environment variable. Ideally it would be off by default and could be turned on for those who actually use it.

[jmehnle]

Per #1475 (comment) the workaround is to put your URL value in a file and pass it via fileb://$FILENAME. E.g., using Bash's process substitution:

aws ec2 run-instances [...] --user-data fileb://<(echo -n 'https://foo/bar')

[rosswilson]

This has now been fixed. A new configuration option called cli_follow_urlparam can be set to disable this auto-fetch URL behaviour across the entire AWS CLI.

In your ~/.aws/config file, add the following line:

cli_follow_urlparam = false

See the documentation for more details.

[DominikTo]

Great to hear!
Would be even better with false as the default. Unexpected behaviour.

[joguSD]

In addition to the configuration mentioned by @rosswilson, this functionality has been entirely removed in the AWS CLI v2.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.