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

tctl create improvements #1266

Merged
merged 3 commits into from
Sep 6, 2017
Merged

tctl create improvements #1266

merged 3 commits into from
Sep 6, 2017

Conversation

kontsevoy
Copy link
Contributor

@kontsevoy kontsevoy commented Sep 6, 2017

This PR closes #1137 (finally). Last bits:

  • tctl create works on different resources for e vs OSS
  • tctl rm works on different resources for e vs OSS
  • tctl create now supports --force, -f flag for doing updates

Also this PR fixes the build of e which is currently broken due to failed merges in the past.

Related: teleport.e/pull/12

`tctl create` used to create or update (AKA "upsert") resources.
Now there's a difference:

`--force, -f` flag, if not set, means "create only". Otherwise it means
"update".

This means you can fail updating non-existing resources.
@kontsevoy kontsevoy merged commit aeaa64b into master Sep 6, 2017
@kontsevoy kontsevoy deleted the ev/force branch September 6, 2017 21:50
hatched pushed a commit that referenced this pull request Feb 1, 2023
* Now that clipboard.readText() requires transient user activation
(see https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/readText#security),
our system of syncing the local clipboard to remote onfocus and onmouseenter
no longer works, since those events don't necessarily imply a transient event.

With this change, we instead sendLocalClipboardToRemote onMouseDown and onKeyDown,
which should guarantee that the sync is always within a transient event.
Because the user must preform at least one of these actions in order to
initiate a paste, the clipboard should appear to always be in sync from
their perspective.

* eliminates the entire useClipboard hook and its surrounding state, which
was a big rube goldberg machine ensuring that
1. If a user had clipboard sharing enabled by RBAC
2. they were on chrome and
3. they had clipboard permissions allowed

If 1 was true, but either of 2 or 3 wasn’t, we blocked the UI and forced
them to correct it. That was also the mechanism that caused the clipboard
permissions dialog to pop up at the beginning of the session if clipboard
access wasn’t "granted".

Now the UX is much simpler: if a user has clipboard sharing allowed by RBAC,
and they’re on Chrome, clipboard sharing is enabled. If either of those is false,
clipboard sharing is disabled. If a user’s clipboard permissions are in
"prompt" state (aka neither "granted" nor "denied"), the first time they
try to copy/cut something on the remote, or have something in their clipboard
locally and click a mouse button or press a key, the browser prompt asking
for clipboard permissions will show up.
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.

tctl resources
2 participants