Save presets from browser

[andymarden]

I donlt think it does this (correct me if I am wrong) but when I create a remote in the browser, these do not persist in the server config for me to use next time or on another device.

Since the save to a local file and presets are already present, it would seem a piece of cake to add this to the dialog when creating a host (as a "Save as Preset" checkbox) and and on the known hosts once created as a button "Save as Preset" next to each host.

Is this something that you can add? You could make an ENv variable to enable that feature to be allowed/disallowed by the admin.

Moved from Guacamole to this as:

a. It's overkill for what I need b. The UI is stuck in the 1980's c. Support is only via an email mailing list?!

[nirui]

Hi,

So the Preset workflow/connectflow goes like this: the admin setup the Preset items, and the items are sent to clients as is to be displayed on the "Presets" list. If an user successfully completed the connection wizard by clicking on a Preset item, a connection record are added into the "Connected before" list, and they can reconnect to the Remote again by clicking on the record (instead of the item on the "Presets" list, since doing so creates a new record on the "Connected before" list).

On the other hand, if user wish to connect to the same Remote defined in a Preset but with different settings (username, hostname etc), then they could do so by running the same Preset connection wizard again with different settings specified, and this creates a new record on the "Connected before" list separate from the previous one.

[andymarden]

So, can a preset file have one connection in and then users use that to create other connections which get saved to presets? If I create this and then set the env to point to it, will that unlock the ability for users to save to presets? Or can they only use presets?

Is the connected before only the list that is held for that session or something more. If so, does it get cleared out when the browser closes

[nirui]

Presets can only be specified by the server admin. But once the user used a Preset, there will be an item added to the "Connected before" list.

The "Connected before" list will be stored in the user's browser. If the browser is closed, the record should still be there the next time user opens Sshwifty, provided the domain/hostname that hosts Sshwifty hasn't been changed, and the user hasn't clean up the localStorage which is there the data is stored.

So, I think maybe there is really no need to add the ability for user to create Presets for themselves, as they can just use existing ones configured by the admin, and customize the settings as needed.

[andymarden]

I disagree that this is not useful as an option.

If you want to control the hosts via a single admin that's fine.

But I want to be able to create the hosts via the gui and then have them persisted in presets so that I can use same list of hosts in different browsers and devices, and others can use them. Ability to save password or PK could be optional and switching on this capability could be optional.

If you don't think it is worth doing, but donlt mind (defaulting to current behaviour), I am happy to do a PR to add. Ok with that?

[andymarden]

Even for the admin, having to edit the file and do and get the SSH Auth Key to paste in there. So admins could even use this to create the presets and then switch it off after if they do not want anyone to. What so you think?

[nirui]

I don't really have energy left to review PRs. Can you make a separate fork to add the change?

I'll add a link here (to the README.md file) to redirect people to go to your fork should they find the features you added interesting.

[andymarden]

OK - will do and you can do the merge if you like it. I will do a PR anyway and then you can decide if you want to at some point. Will let you know when done.

[nirui]

I would still recommend that you do a separate fork. Reasons:

1. I have other plans for Presets, namely, it will be completely server-side with no data downloaded to the client. Which is probably further away from what you've wished.
2. I'm also contemplating the idea of monetizing my projects (including this one), meaning I better go with the Open Core model and not accepting (legally) third-party codes.
3. With the two points said, there will be huge changes to the code base once I figured out how to do it without enshittificating things too much. So, the PRs made for the code today maybe inapplicable for the project that I planed to write anyways.

So, yeah, the best thing we can do now is to make a separate fork.

Please understand :)

[andymarden]

Yeah - no problem I will fork and then give you a PR so you can decide if you want to pull in at any point. Maybe if it is relatively small changes then you might at some point consider. No pressure :-)