starred/1Remote

Fork 0

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

[GH-ISSUE #804] Resolve environment variables present in connection options #1612

New issue

Closed

opened 2026-02-28 12:05:35 +03:00 by kerem · 5 comments

kerem commented

2026-02-28 12:05:35 +03:00

Owner

Originally created by @argonym on GitHub (Dec 9, 2024).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/804

Originally assigned to: @VShawn on GitHub.

Use case:
As a team, we intend to share the list of (RDP) connections by using the same database.
But when connecting to a server, everyone needs to connect with a different username.
The username can be obtained from a (user-specific) Windows environment variable.

Feature request:
When connecting, resolve environment variables in the "User" connection option.
Probably also in other options where it might make sense.
And for each option where this is possible, provide a hint that this is possible. E.g. in the tooltip for the input field.

Originally created by @argonym on GitHub (Dec 9, 2024). Original GitHub issue: https://github.com/1Remote/1Remote/issues/804 Originally assigned to: @VShawn on GitHub. **Use case:** As a team, we intend to share the list of (RDP) connections by using the same database. But when connecting to a server, everyone needs to connect with a different username. The username can be obtained from a (user-specific) Windows environment variable. **Feature request:** When connecting, resolve environment variables in the "User" connection option. Probably also in other options where it might make sense. And for each option where this is possible, provide a hint that this is possible. E.g. in the tooltip for the input field.

kerem

2026-02-28 12:05:35 +03:00

closed this issue
added the
meta-feature

stale
labels

kerem commented

2026-02-28 12:05:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Dec 9, 2024):

You can leave the username and password option empty so user will have to specify it each time.
You can add alternative accounts for each user

All that is suboptimal. Ideally, 1RM should allow for having local settings of remote database.

I discussed that here: https://github.com/1Remote/1Remote/discussions/414 and the very thing you asked is noted there:

Based on discussion https://github.com/1Remote/1Remote/discussions/392 there should be need for local alternation of remote connections. Original idea was for allowing custom username - team members will either have their own domain names or local OS names.

@majkinetor commented on GitHub (Dec 9, 2024): 1. You can leave the username and password option empty so user will have to specify it each time. 2. You can add alternative accounts for each user All that is suboptimal. Ideally, 1RM should allow for having local settings of remote database. I discussed that here: https://github.com/1Remote/1Remote/discussions/414 and the very thing you asked is noted there: > Based on discussion https://github.com/1Remote/1Remote/discussions/392 there should be need for local alternation of remote connections. Original idea was for allowing custom username - team members will either have their own domain names or local OS names.

kerem commented

2026-02-28 12:05:36 +03:00

Author

Owner

@majkinetor commented on GitHub (Dec 9, 2024):

Note that we didn't mention environment vars there, as IMO this is very unsecure. Such method is typically used on CI/CD platforms and that use case seems valid (although also highly controversial), but keeping multiple passwords as env var is both non secure, no portable etc.

Maybe .env file would be an option, with 1RM moving it into its own space, that way at least they won't be visible by typing 1 command in shell. However, I would prefer complete solution (modying any connection setting locally, not just username/pass).

@majkinetor commented on GitHub (Dec 9, 2024): Note that we didn't mention environment vars there, as IMO this is very unsecure. Such method is typically used on CI/CD platforms and that use case seems valid (although also highly controversial), but keeping multiple passwords as env var is both non secure, no portable etc. Maybe `.env` file would be an option, with 1RM moving it into its own space, that way at least they won't be visible by typing 1 command in shell. However, I would prefer complete solution (modying any connection setting locally, not just username/pass).

kerem commented

2026-02-28 12:05:36 +03:00

Author

Owner

@VShawn commented on GitHub (Dec 10, 2024):

environment variables to store personal accounts is an immature solution, #414 is clearly better(Of course the workload is also greater). My previous plan was to create a customized information table in sqlite database (allowing customized data except server name, icon, hostname and port). due to time constraints, I was unable to start this work.

Using environment variable-based accounts can be attempted as workaround in the development branch for those who need the feature right now, but I do not recommend merging it into the main branch.

@VShawn commented on GitHub (Dec 10, 2024): environment variables to store personal accounts is an immature solution, #414 is clearly better(Of course the workload is also greater). My previous plan was to create a `customized information table` in sqlite database (allowing customized data except server name, icon, hostname and port). due to time constraints, I was unable to start this work. Using environment variable-based accounts can be attempted as workaround in the development branch for those who need the feature right now, but I do not recommend merging it into the main branch.

kerem commented

2026-02-28 12:05:36 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jan 9, 2025):

This issue is stale because it has been open for 30 days with no activity.

@github-actions[bot] commented on GitHub (Jan 9, 2025): This issue is stale because it has been open for 30 days with no activity.

kerem commented

2026-02-28 12:05:36 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jan 24, 2025):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Jan 24, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.

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#1612

No description provided.

Rows
Columns