Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add providers for opening files and getting server config #228

Merged
merged 10 commits into from
Dec 3, 2018

Conversation

pfitzseb
Copy link
Contributor

I'm in the process of making Juno play nicer with remote servers (see here for the relevant PR) and it would be nice if there were some small hooks into this package to facilitate integration on our side.

This PR adds

  1. A provider to allow a third-party package to open an arbitrary file on a remote server via ftp-remote-edit. This is probably relatively uncontroversial, but the implementation could probably be nicer.
  2. A provider that allows a third-party package to get the ssh configuration for the currently selected server in ftp-remote-edit. This definitely shouldn't be merged as-is since every package can get e.g. the password or private key file that way. The best way to handle this would probably be to ask the user to confirm explicitly when another package tries to get the server config, I guess. If that's not an option for you I'll just remove this part of the API.

@cschindl
Copy link
Collaborator

Hi @pfitzseb,

thank you for your support. The first part can be merged without problems. With the second part I agree with you that it is a security risk without asking the user. So if you integrate the prompt, the second part can also be merged.

@pfitzseb
Copy link
Contributor Author

pfitzseb commented Nov 23, 2018

Hi @cschindl,
thanks for the quick response! :)
I've implemented a user prompt where the first part of the message is provided by the requesting package:

image

Let me know if you think that's enough.

The last commit also fixes a random bug I noticed.

@MikeInnes
Copy link

I suggest that the confirmation could be stored somewhere so that the user need only be asked once.

Also, I think the confirmation makes sense when revealing a password, but could perhaps be disabled when only a private key file is revealed (since we have access to that anyway).

@pfitzseb
Copy link
Contributor Author

@cschindl Hi, can you take another look at this PR (and #229) and merge it if there are no objections? Thanks! :)

@cschindl
Copy link
Collaborator

Hi @pfitzseb,

Did you look at the suggestion from @MikeInnes? The one-time request for confirmation might be helpful. If you don't think so, I can merge your PR.

@pfitzseb
Copy link
Contributor Author

pfitzseb commented Dec 3, 2018

Ok, I've added a whitelist/blacklist:
image
image

This makes things much more pleasant without losing too much security (which is a bit of a moot point anyways because Atom packages have full FS access and could keylog everything).

Let me know what you think!

@cschindl
Copy link
Collaborator

cschindl commented Dec 3, 2018

Looks good and is hereby released. Thanks for your support.

@cschindl cschindl merged commit 8e5987c into h3imdall:master Dec 3, 2018
@pfitzseb
Copy link
Contributor Author

pfitzseb commented Dec 3, 2018

Thanks for the merge! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants