starred/1Remote

Fork 0

mirror of https://github.com/1Remote/1Remote.git synced 2026-04-25 13:36:03 +03:00

[GH-ISSUE #61] Configuration options for external programs (protocols and tools) #2927

New issue

Closed

opened 2026-03-13 00:16:18 +03:00 by kerem · 5 comments

kerem commented

2026-03-13 00:16:18 +03:00

Owner

Originally created by @VShawn on GitHub (Jan 15, 2021).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/61

In order to achieve new requirements #59, we need a system that that can config external programs. like mRemoteNG did:

The difference between this system and mRemoteNG is that we need to implement two sets of external program manager.

Protocol Program Manager: It can only specify external programs for specific protocol settings. For example, ssh can only set the KiTTY path, and FTP can only set the WinSCP path.
Third-party external program manager: It has basically the same as mRemoteNG did, you can set all exe as external programs, configure their paths, transfer parameters, etc.

In fact, in my opinion, the above scheme does not look very flexible, and I am still considering other implementations.

Originally created by @VShawn on GitHub (Jan 15, 2021). Original GitHub issue: https://github.com/1Remote/1Remote/issues/61 In order to achieve new requirements #59, we need a system that that can config external programs. like mRemoteNG did: ![image](https://user-images.githubusercontent.com/10143738/104707419-54b74400-5757-11eb-8d8f-34e57d38cddb.png) The difference between this system and mRemoteNG is that we need to implement two sets of external program manager. 1. **Protocol Program Manager**: It can only specify external programs for specific protocol settings. For example, ssh can only set the KiTTY path, and FTP can only set the WinSCP path. 2. **Third-party external program manager**: It has basically the same as mRemoteNG did, you can set all exe as external programs, configure their paths, transfer parameters, etc. In fact, in my opinion, the above scheme does not look very flexible, and I am still considering other implementations.

kerem closed this issue

2026-03-13 00:16:25 +03:00

kerem commented

2026-03-13 00:16:32 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 15, 2021):

Let me brainstorm about this a little:

Tool configuration

Specify arbitrary path to arbitrary executable. Full path should be optional, $Env:PATH is used. Env vars in path should be supported.
Map config settings to local environment variables, such as %HOSTNAME%, %USERNAME% etc. that can be used when specifying command line arguments to a tool.
ComboBox to specify type of supported provider (RDP, FTP...).

Some CLI tools might even need specifying stdin.

Notes

Cli tools

CLI tools use different Windows subsystem but could probably be treated equally as GUI tools by invoking them via cmd.exe internally.

Custom providers

Not sure if adding arbitrary providers should be allowed (tool abc.exe handles abc connection type). Multiple tools could theoretically handle the same provider (eg. WinScp or FileZIlla).

So RDP currently has several extra options (mapping of remote resources and display options) and SSH has Advantage and key options. In essence, if tool supports setting those via command line parameters then this is about mapping New remote config on tool CLI parameter . This then calls to defining properties on tools configuration that will be exposed in New remote UI.

Lets see on KITTY example and what we currently have in PRM:

Name, Group, Address, user, password, port - PRM should have those on ALL providers as absolute minimum.
Private key, SSH version, Auto command: those are specific to protocol and could come from tool configuration and mapping to CLI options must be provided:
- -cmd maps to Auto command
- -i maps to Private key
- -1 and -2 map to SSH version

So lets imagine we have Protocol Definition UI that could used to define mapping:

| Protocol Definition               |
|===============================
| Protocol Name: [> SSH ]    [+]
|-------------------------------
| Auto command
|   Type: string
|---
| Private key
|   Type: file
|---
| SSH Version
|   Type: radio
|   Mandatory: true
|   Values: V1, *V2
|---
| External Configuration
|    Type: file
|---
| Run agent
|    Type: boolean

NOTE:

Configuration env var is automatically named by joining title using underscore, no need to specify it
Types could be string, number, file, radio, combo, boolean
- Its there just for GUI rendering, however, it could basically be simplified to string always
- It defaults to string
* above specifies that value is default.

Having this separated from tools configuration, we can then map tools to protocols in tool configuration which will allow you to map multiple tool options to single interface.

So lets now define kitty tool options once we defined SSH protocol (ofc, this one would come predefined):

| Tool configuration: kitty
|================================================================
| Protocol: [> SSH]
| ...
| ...
| Protocol options
| ----
|   Auto command: [ -cmd '%AUTO_COMMAND%' ]
|   Private key: [ -i '%PRIVATE_KEY%' ]
|   SSH Version: 
|       V1:  [ -1 ]
|       V2:  [ -2 ]
|   External Configuration: [ -kload '%EXTERNAL_CONFIGURATION%' ]

Now, I'll just leave this here to incubate, I am not sure if this is ultra flexible or complicates things without great benefit. On the other hand, it looks like implementation is pretty easy (probably day's work).

Not sure at this moment how this could work on RDP as those options are probably library options (didn't look into source code yet, just assuming), but I guess PRM could actually crate tiny exe wrappers (If I remember correctly this is what you do now) and along with that expose everything desired as CLA.

@majkinetor commented on GitHub (Jan 15, 2021): Let me **brainstorm** about this a little: ### Tool configuration 1. Specify arbitrary path to arbitrary executable. Full path should be optional, $Env:PATH is used. Env vars in path should be supported. 2. Map config settings to local environment variables, such as %HOSTNAME%, %USERNAME% etc. that can be used when specifying command line arguments to a tool. 3. ComboBox to specify type of supported provider (RDP, FTP...). Some CLI tools might even need specifying stdin. ### Notes #### Cli tools CLI tools use different Windows subsystem but could probably be treated equally as GUI tools by invoking them via `cmd.exe` internally. #### Custom providers Not sure if adding arbitrary providers should be allowed (tool abc.exe handles abc connection type). Multiple tools could theoretically handle the same provider (eg. WinScp or FileZIlla). So RDP currently has several extra options (mapping of remote resources and display options) and SSH has _Advantage_ and key options. In essence, if tool supports setting those via command line parameters then this is about mapping _New remote_ config on tool CLI parameter . This then calls to defining properties on tools configuration that will be exposed in _New remote_ UI. Lets see on KITTY example and what we currently have in PRM: - Name, Group, Address, user, password, port - PRM should have those on ALL providers as absolute minimum. - Private key, SSH version, Auto command: those are specific to protocol and could come from tool configuration and mapping to CLI options must be provided: - `-cmd` maps to `Auto command` - `-i` maps to `Private key` - `-1` and `-2` map to `SSH version` So lets imagine we have _Protocol Definition UI_ that could used to define mapping: ``` | Protocol Definition | |=============================== | Protocol Name: [> SSH ] [+] |------------------------------- | Auto command | Type: string |--- | Private key | Type: file |--- | SSH Version | Type: radio | Mandatory: true | Values: V1, *V2 |--- | External Configuration | Type: file |--- | Run agent | Type: boolean ``` NOTE: - Configuration env var is automatically named by joining title using underscore, no need to specify it - Types could be string, number, file, radio, combo, boolean - Its there just for GUI rendering, however, it could basically be simplified to `string` always - It defaults to string - `*` above specifies that value is default. Having this separated from tools configuration, we can then map tools to protocols in tool configuration which will allow you to map multiple tool options to single interface. So lets now define kitty tool options once we defined SSH protocol (ofc, this one would come predefined): ``` | Tool configuration: kitty |================================================================ | Protocol: [> SSH] | ... | ... | Protocol options | ---- | Auto command: [ -cmd '%AUTO_COMMAND%' ] | Private key: [ -i '%PRIVATE_KEY%' ] | SSH Version: | V1: [ -1 ] | V2: [ -2 ] | External Configuration: [ -kload '%EXTERNAL_CONFIGURATION%' ] ``` Now, I'll just leave this here to incubate, I am not sure if this is ultra flexible or complicates things without great benefit. On the other hand, it looks like implementation is pretty easy (probably day's work). Not sure at this moment how this could work on RDP as those options are probably library options (didn't look into source code yet, just assuming), but I guess PRM could actually crate tiny exe wrappers (If I remember correctly this is what you do now) and along with that expose everything desired as CLA.

kerem commented

2026-03-13 00:16:37 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 1, 2021):

I though of this
I think it would be quite troublesome to allow users to define their own protocols. Few people want to learn this complex definitions. And it does not match the positioning of the product (a simple tiny personal). Why not we pre-define what protocols we can provide, user can select tool they like to connect a protocol, or use a preset tool we offered for a quick use.

E.g. SSH

We offering PuTTY as default terminal. Some users may want to use something named XuTTY.

For normal user they can open new issue to ask us add XuTTY into official SSH support list.
For those with strong ability, they can config new tools PATH / CMD-LINE-PARAMS.

This is less flexible, but simpler.

@VShawn commented on GitHub (Feb 1, 2021): I though of this I think it would be quite troublesome to allow users to define their own protocols. Few people want to learn this complex definitions. And it does not match the positioning of the product (a simple tiny personal). Why not we pre-define what protocols we can provide, user can select tool they like to connect a protocol, or use a preset tool we offered for a quick use. E.g. SSH We offering PuTTY as default terminal. Some users may want to use something named XuTTY. - For normal user they can open new issue to ask us add XuTTY into official SSH support list. - For those with strong ability, they can config new tools PATH / CMD-LINE-PARAMS. This is less flexible, but simpler.

kerem commented

2026-03-13 00:16:42 +03:00

Author

Owner

@majkinetor commented on GitHub (Feb 1, 2021):

I think it would be quite troublesome to allow users to define their own protocols

That depends on UX. It could be there as advanced option that can be used internally mostly or by advanced users that know what to do.

For normal user they can open new issue to ask us add XuTTY into official SSH support list.

You understand that this is basically unlimited feature request potential (there are so many tools) ? With the feature offered, you can always say to users please try to configure it on your own and just provide us config that you are happy with so we can copy/paste it into the project to be supported officially. You don't block such users if they are willing enough, and you can immediately use all their successful work.

For those with strong ability, they can config new tools PATH / CMD-LINE-PARAMS.

Yeah, they can if they have this protocol to cmd line map feature. How would they do it without it ? How do you know what of number options such tools have to expose in PRM config ? Just take putty as an example. You exposed few options only.

@majkinetor commented on GitHub (Feb 1, 2021): > I think it would be quite troublesome to allow users to define their own protocols That depends on UX. It could be there as advanced option that can be used internally mostly or by advanced users that know what to do. > For normal user they can open new issue to ask us add XuTTY into official SSH support list. You understand that this is basically **unlimited feature request potential** (there are so many tools) ? With the feature offered, you can always say to users please try to configure it on your own and just provide us config that you are happy with so we can copy/paste it into the project to be supported officially. You don't block such users if they are willing enough, and you can immediately use all their successful work. > For those with strong ability, they can config new tools PATH / CMD-LINE-PARAMS. Yeah, they can if they have this _protocol to cmd line map_ feature. How would they do it without it ? How do you know what of number options such tools have to expose in PRM config ? Just take putty as an example. You exposed few options only.

kerem commented

2026-03-13 00:16:47 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 15, 2022):

I will close this since most of it is released in v0.6.

@majkinetor commented on GitHub (Jan 15, 2022): I will close this since most of it is released in v0.6.

kerem commented

2026-03-13 00:16:52 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 15, 2022):

Third-party external program isn't part of 0.6 release, but it could be handled via another ticket if needed. The benefit is IMO very small compared to random launcher in Windows (you could pass details of 'current connection' as parameters of external tools).

@majkinetor commented on GitHub (Jan 15, 2022): _Third-party external program_ isn't part of 0.6 release, but it could be handled via another ticket if needed. The benefit is IMO very small compared to random launcher in Windows (you could pass details of 'current connection' as parameters of external tools).

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/1Remote#2927

No description provided.

Rows
Columns