[REFACTOR] Unify container labels

[steveiliop56]

Right now container labels are scattered instead of being grouped in purpose-specific groups:

// OAuthLabels is a list of labels that can be used in a tinyauth protected container
type OAuthLabels struct {
	Whitelist string
	Groups    string
}

// Basic auth labels for a tinyauth protected container
type BasicLabels struct {
	User     string
	Password string
}

// Labels is a struct that contains the labels for a tinyauth protected container
type Labels struct {
	Users   string
	Allowed string
	Headers []string
	Domain  string
	Basic   BasicLabels
	OAuth   OAuthLabels
}

They should be instead refactored to more intuitive labels like:

type PathLabels struct {
	Allowed string
}

type GenericLabels struct {
	Users string
}

type OAuthLabels struct {
	Whitelist string
	Groups    string
}

type ConfigLabels struct {
	Domain string
	Headers []string
	Basic   BasicLabels
	Paths PathLabels
}

type Labels struct {
	Generic GenericLabels
	OAuth   OAuthLabels
	Config  ConfigLabels
}

This would require a breaking change but it would make labels easier to understand and use.

[steveiliop56]

Another idea is to go with an app based approach. For example:

tinyauth.apps.[app-name].domain: app.example.com
tinyauth.apps.[app-name].ip.bypass: 10.10.10.10

This will allow the labels to be placed anywhere (including in the Tinyauth container itself) and Tinyauth will still be able to identify them. This can allow for a centralized Tinyauth instance that can handle auth and access controls for apps from multiple servers.

[hhftechnology]

Another idea is to go with an app based approach. For example:

tinyauth.apps.[app-name].domain: app.example.com
tinyauth.apps.[app-name].ip.bypass: 10.10.10.10
This will allow the labels to be placed anywhere (including in the Tinyauth container itself) and Tinyauth will still be able to identify them. This can allow for a centralized Tinyauth instance that can handle auth and access controls for apps from multiple servers.

this is a better approach.

[justin8]

Another idea is to go with an app based approach. For example:

tinyauth.apps.[app-name].domain: app.example.com
tinyauth.apps.[app-name].ip.bypass: 10.10.10.10
This will allow the labels to be placed anywhere (including in the Tinyauth container itself) and Tinyauth will still be able to identify them. This can allow for a centralized Tinyauth instance that can handle auth and access controls for apps from multiple servers.

This approach will also make it much easier to configure outside of docker directly; e.g. Kubernetes or non-docker apps.

[steveiliop56]

Another idea is to go with an app based approach. For example:

tinyauth.apps.[app-name].domain: app.example.com
tinyauth.apps.[app-name].ip.bypass: 10.10.10.10

This will allow the labels to be placed anywhere (including in the Tinyauth container itself) and Tinyauth will still be able to identify them. This can allow for a centralized Tinyauth instance that can handle auth and access controls for apps from multiple servers.

That's the approach I will be taking yeah.