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

Use settings for trusted domains #81841

Closed
aeschli opened this issue Oct 2, 2019 · 4 comments
Closed

Use settings for trusted domains #81841

aeschli opened this issue Oct 2, 2019 · 4 comments
Assignees
Labels
feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code workbench-link Link protection in workbench
Milestone

Comments

@aeschli
Copy link
Contributor

aeschli commented Oct 2, 2019

Testing #80595

We should not invent a new story for managing the trusted domains, but use the settings.

  • That way the setting will be part of (future) settings sync.

  • defaults come from the settings defaults

  • make it a map { [ domain:string]: boolean; } | false so you can fine-tune the defaults (and e.g. remove a default entry like localhost) (consistent with other settings like watcher/searc filters)

  • make the setting available in user settings only

  • disallow that extension make changes to the settings, if that is a concern.
    (But note that extensions can cause worse things to your machine than hiding a 'Do you want to open an external website...' dialog)

@octref octref added the under-discussion Issue is under discussion for relevance, priority, approach label Oct 2, 2019
@octref
Copy link
Contributor

octref commented Oct 2, 2019

disallow that extension make changes to the settings

That isn't doable now. I did the QuickPick last month and the virtual setting file this month because if it's in settings extensions can write anything to it.

@octref octref added the *as-designed Described behavior is as designed label Oct 25, 2019
@vscodebot
Copy link

vscodebot bot commented Oct 25, 2019

The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our issue reporting guidelines.

Happy Coding!

@vscodebot vscodebot bot closed this as completed Oct 25, 2019
@octref octref reopened this Oct 28, 2019
@octref octref added bug Issue identified by VS Code Team member as probable bug workbench-link Link protection in workbench and removed *as-designed Described behavior is as designed under-discussion Issue is under discussion for relevance, priority, approach labels Oct 28, 2019
@octref octref added this to the November 2019 milestone Oct 28, 2019
@Tyriar Tyriar assigned JacksonKearl and unassigned octref Aug 26, 2020
@JacksonKearl JacksonKearl added feature-request Request for new features or functionality and removed bug Issue identified by VS Code Team member as probable bug labels Sep 8, 2020
@JacksonKearl
Copy link
Contributor

disallow that extension make changes to the settings

Doesn't seem like this is possible looking at the registry...

export interface IConfigurationNode {
	id?: string;
	order?: number;
	type?: string | string[];
	title?: string;
	description?: string;
	properties?: { [path: string]: IConfigurationPropertySchema; };
	allOf?: IConfigurationNode[];
	scope?: ConfigurationScope;
	extensionInfo?: IConfigurationExtensionInfo;
}

do you know of a way to do it?

@JacksonKearl JacksonKearl added the *out-of-scope Posted issue is not in scope of VS Code label Oct 13, 2020
@JacksonKearl
Copy link
Contributor

Spoke with Kai and decided to not go this route.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code workbench-link Link protection in workbench
Projects
None yet
Development

No branches or pull requests

3 participants