Review the public settings API

[deviantony]

At the moment, the api/settings/public endpoint exposes the following details for non-authenticated users:

type publicSettingsResponse struct {
	LogoURL                            string                         `json:"LogoURL"`
	AuthenticationMethod               portainer.AuthenticationMethod `json:"AuthenticationMethod"`
	AllowBindMountsForRegularUsers     bool                           `json:"AllowBindMountsForRegularUsers"`
	AllowPrivilegedModeForRegularUsers bool                           `json:"AllowPrivilegedModeForRegularUsers"`
	AllowVolumeBrowserForRegularUsers  bool                           `json:"AllowVolumeBrowserForRegularUsers"`
	EnableHostManagementFeatures       bool                           `json:"EnableHostManagementFeatures"`
	EnableEdgeComputeFeatures          bool                           `json:"EnableEdgeComputeFeatures"`
	OAuthLoginURI                      string                         `json:"OAuthLoginURI"`
}

Only the following properties should be exposed publicly:

• LogoURL (to display it in the authentication view)
• AuthenticationMethod (to display proper OAuth/LDAP controls)
• OAuthLoginURI (to redirect to OAuth provider)

The rest of the API parameters should be available behind authentication.

This will introduce an API breaking change.

[chiptus]

These views are calling publicSettings:

• createContainer - needs AllowBindMountsForRegularUsers && AllowPrivilegedModeForRegularUsers
• createService - AllowBindMountsForRegularUsers
• service - AllowBindMountsForRegularUsers
• stateManager - needs everything from settings
• account - AuthenticationMethod
• auth - AuthenticationMethod && OAuthLoginURI (&& logo, but for some reason it takes it from the state manager)
• templates - AllowBindMountsForRegularUsers
• users - AuthenticationMethod
• user - AuthenticationMethod

so in this breaking change we need to refactor createContainer, createService, service and templates to received this flag from the state manager.

stateManager should be refactored to call the authenticated settings method, and only when authenticated.

account, users, user - can probably also take their values from the state manager (reducing calls to the server)
auth - take logo from publicSettings

[chiptus]

main problem is this:

StateManager should be refactored to call the authenticated settings method, and only when authenticated.

one way to call init only when authenticated is calling it twice:

• in the root resolver if user is authenticated (calling initAuthentication first and then checking if user is already authenticated)
• in the authController after the user successfully logs in.
  another way is to introduce another route that will wrap all the routes that require authentication, and move state initialization there.

StateManager.initalize should be called anyway, because otherwise the app doesn't work. But the call to the authenticated settings should be moved to another method, so we can either call it inside initalize if the user is authenticated, or call it from authController after authentication

[chiptus]

just found another needed change. GET api/settings is admin restricted. Is there a reason for this? should we create another route for regular users?

[deviantony]

@chiptus we're gonna postpone this piece of work.