Allow site administrators to select which token types are available

I just came across this interesting module, and havent had time to check it out yet, but the first thought that came to mind was about potential security implications.

If all/global tokens are available to be presented inside node bodies, is there any risk of making any kind of information available to roles that normally cannot access it, either for the final viewer, or even to roles that have access to use this filter, through simply previewing nodes and testing various tokens? Will all information available through tokens be narrowed down to the current user/role/node/context, or can other information be pulled in here too?

(As I said, havent wrapped my mind around this related to this module's functionality, so I thought I'd just ask here about it first...)

Taxoman,
Thats a very good point, I have the similar question as well.

To @Taxoman's point: this module doesn't alter the behaviour of tokens beyond making them available in filtered text fields. Anything a user can do with tokens in a body field they could already do in a title field (for instance), so this module isn't responsible for that security - that's in the Token module.

As for narrowing the scope of tokens available in particular text filters, yes that is something that *might* be useful. What would that look like? How would an admin select usable tokens? Is it a blacklisting or whitelisting system? What problems would it solve?

I think if this idea was something desired by users this issue would have a lot more comments by now, so I'm closing it. Feel free to resurrect it if you think it's a good idea and can articulate a use-case.

I think in combination with Custom Tokens (https://www.drupal.org/project/token_custom) the option to restrict token types to show in the ckeditor browser would be useful, to insert things like sitewide contact details etc., without polluting the browser dialog with a long list that non-technical editors might have difficulty sifting through. It also saves time loading unrequired token types.

In any case I needed this functionality so wrote a patch to achieve it - attached. It takes a whitelist approach, but with none selected defaulting to 'all'.

This is for 8.x-1.x, so I'm updating the issue version.

This is a bit different to the original issue. I believe the intent was to restrict the tokens which would be translated, not just which ones would be displayed in the browser.

I think the latter is less useful without the former.

Thoughts?

I just had another read and I'm contradicting myself in #4 and #7, I'll have a look at this patch, seems like a reasonable approach.

Great patch, thanks!
I updated the settingsForm function to use dependency injection instead of side-loading \Drupal::token(), other than that it's great.