We are currently creating a client tool for a social networking service. However, each subcommand requires the user ID and password to be entered, making the command lengthy.
Is there any way to carry over the command line arguments entered in one subcommand and use them in another subcommand? Or any suggestions on how to avoid having to repeatedly enter the user id and password?
This project is available in the atpctrl repository, so please take a look if there is anything you would like to know.
How about storing the credentials in Keychain?
1 Like
Thanks for suggesting this method.
I am hesitant to use the macOS feature because I would like to support Linux if possible. Also, sorry I forgot to mention this.
If I can't find a better way, I'll implement the macOS process this way and make the Linux version a different process. However, I want this to be a last resort.
Fair enough. I suppose that you could store the data in a dot file in the user's home directory - however I'm not at all sure how you'd make that properly secure...
1 Like
A program doesn’t necessarily have a controlling terminal. The idea of a “session” is a platform-specific concept, so you are going to need platform-specific solutions. On Apple platforms, this is implemented with Mach namespaces. I don’t know how you might achieve this on Linux… cgroups, maybe?
1 Like
I suppose you know Linux has similar service. I think it's common to write platform-specific code to access platform-specific service.
Take ssh private key as an example. It's proteced with proper file access mode. But that's not enough, so it's usually encrypted. That leads to the question where to save the private key after it's decrypted. The solution in ssh is to save it in ssh-agent (a daemon).
There is also another approach (I think it out while writing this, so I don't know if it's typical). It solves the issue by avoiding it. It's simple and but requires you to change your command interface. Suppose you have three commands: auth, foo, bar. In this approach you'll implement them as subcommands, like the following:
$ atpctl
> auth nobody@example.com
input password:
> foo <args...>
> bar <args...>
> exit
Just my thoughts.
1 Like
Sorry for the late reply.
Certainly, it may not be good for security if it is left as it is.
We need to look for options that can guarantee security.
Sorry for the late reply.
I guess there is no common solution, I will look into cgroups.
Thanks for your reply. As I said, it would have been absurd to try to take the same approach with macOS and Linux.The SSH private key thing was very interesting to me. I'm going to look into how to implement it, but this approach seems to give me an idea of what I want to do.
The other approach is what I was thinking about, but I didn't know how to get the values entered with the auth command with the foo/bar command. That's what prompted me to ask for help here.
I'm not sure if I understand what you meant. In this approach you don't have multiple commands (or processes). You have only one command atpctl. When you invoke it, it prints ">" prompt in terminal and you input sub commands like auth, foo, bar, etc. Since they are in a single process, you certainly have access to user input (or whatever credential the auth command returns).
I don't understand this ether. On macOS you uses keychain service. On Linux desktops you have similar services like Gnome keyring (I don't know what's its equivalent on KDE, but there is a Freedesktop Spec about secrete service, so it should be possible to access them through common dbus API). In your project you can check the OS first and run OS specific code to get user's credential. I think this is a typical way to access OS specific service like this.