Make SmartProxyAuth concern more useful to plugins
Instead of being only handling the Puppet case, change the concern to authenticate arbitrary Smart Proxies / Features
#1 Updated by Marek Hulán over 5 years ago
I was thinking about this few days ago. I think Feature model should define whether we should trust that SmartProxy for authentication. Other plugins adds their own features to SmartProxy so they could just create it with (e.g.) authentication flag set to true.
#3 Updated by Stephen Benjamin over 5 years ago
@Marek - That could work also. The end goal for me was just to get rid of all the alias_method_chains and hacking I have on this Concern in foreman_salt.
The way I have it in the PR, each controller specifies which features are allowed to access it. This does have the advantage that a Salt-only Smart Proxy won't have access to say for example, an endpoint for the ABRT or OpenScap plugins.
FactImporters (and hopefully soon ReportImporters) are special in that the plugin's implementation would supply authorized features.