enable sfdx auth:login:sfdx-url to read the url from stdin

[AllanOricil]

Is your feature request related to a problem? Please describe.

no

What are you trying to do

I don't want to store a secret in disk as a plain text.

Describe the solution you'd like

sfdx could read the auth url from stdin like docker login does echo $PASSWORD | docker login --username foo --password-stdin. Where $PASSWORD is an env variable available in a single shell session. It isn't saved anywhere in disk as a plain text, also not loaded by ~/.profile, or rc files like ~/.bashrc,~/.zshrc

It could work like this

echo $AUTH_URL | sfdx auth:login:sfdx-url --sfdx-auth-url

or

sfdx auth:login:sfdx-url --sfdx-auth-url $AUTH_URL

Then you can delete the --sfdx-auth-url-file flag.

Describe alternatives you've considered

N/a

Additional context
N/A

[github-actions]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[git2gus]

This issue has been linked to a new work item: W-13176733

[AllanOricil]

seems simple to do it
https://github.com/salesforcecli/plugin-auth/blob/2966bf9c5d1e38ac0e56aacf3b619975375e9445/src/commands/org/login/sfdx-url.ts#L72-L74

[amtrack]

I'd love to see this natively supported as well.

@AllanOricil Until this is implemented you could use the following workaround on UNIX and MacOS:

sfdx auth sfdxurl store -d -a devhub -f <(echo "$SFDX_AUTH_URL_DEVHUB")

This is using Bash Process Substitution.

$ ls <(echo "hi ls")
/dev/fd/11
$ cat <(echo "hi cat")
hi cat

[AllanOricil]

I dont think it would solve the problem because process substitution saves the information you piped in it to a file at /dev/fd/

When we use process substitution, the file location is echoed. This means its location can be retrieved from history if not deleted. I can consult the history, find the file, read its content. Even without knowing its location, I could just search for the Auth Url Pattern in all files at /dev/fd

[amtrack]

@AllanOricil As far as I know it isn't written to disk.

$ ls <(echo "hi ls")
/dev/fd/11
$ cat /dev/fd/11
cat: /dev/fd/11: Bad file descriptor

[AllanOricil]

According to this guide,

Process substitution uses /dev/fd/<n> files to send the results of the process(es) within parentheses to another process

I tried to access them and it seems possible

[AllanOricil]

Simple example to demonstrate that /dev/fd/n are readable

https://unix.stackexchange.com/questions/556490/is-it-guaranteed-freshly-opened-dev-fd-3-always-reads-from-start

[amtrack]

@AllanOricil Yes, I can reproduce your example.
But using exec 3<FILENAME isn't what I suggested :-)

Can you reproduce my example?

$ ls <(echo "hi ls")
/dev/fd/11
$ cat /dev/fd/11
cat: /dev/fd/11: Bad file descriptor

[AllanOricil]

@amtrack I can confirm that /dev/fd/11 does not have any data in it. No idea why some of these files are readable and some are not. Kind weird.

I can """read""" it using the browser, but it displays nothing

the fs also shows that it has 0 bytes

do you know why the number 11 is a constant in your example? I thought n was the number of the shell process
why it does not store data like number 3 do?

[AllanOricil]

the following sfdx|sf docs could be updated with @amtrack solution

https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_auth_sfdxurl.htm#cli_reference_auth_sfdxurl_store

https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_org_commands_unified.htm#cli_reference_org_login_sfdx-url_unified

By the way, just noticed that the new doc was not templated properly.

[ImJohnMDaniel]

FWIW, I love this idea!!!!

[amtrack]

I'd definitely prefer having it implemented using a new --sfdx-auth-url flag just like @AllanOricil described it instead of documenting a workaround that unfortunately only works on UNIX and MacOS with Bash. 😄

[AllanOricil]

the same problems could happen with the jwt flow which also reads a key from disk --jwt-key-file
just don't use this auth url in ci automations, create ur own connected app and rotate keys from time to time.

[AllanOricil]

reopened because I still think it does not make sense to read unencryted secrets from disk

[AllanOricil]

doc still broken

[cristiand391]

@AllanOricil thanks for the heads up!
We fixed the issue with templates not being rendered when generating the CLI command reference. IIRC, it take a few weeks to get those pages updated, I'll check again next week.

[AllanOricil]

Here there is an example of how this could be achieved
oclif/oclif#245

[AllanOricil]

I opened a PR for this new flag

[WillieRuemmele]

salesforcecli/plugin-auth#765

[AllanOricil]

It can be implemented with oclif/core#894 once core is updated to v3

[shetzel]

The fix is now in the sf CLI release candidate version, v2.24.4.

[AllanOricil]

[AllanOricil]

https://youtube.com/clip/Ugkxy3FFXYGwr5TnOfwiG2fZAJZEA7JZqAeg?feature=shared