Hi,
exactly 6 years, wow... let's not make it another 6 years until we talk
about this again! ;-)
So "LABEL:READ" and "LABEL:WRITE" looks good to me (that would be e.g.
"configMgr:READ"), for now I would not like to make it more complicated
(but as you said this leaves the option to introduce arbitrary,
plugin-interpreted strings like LABEL:SPECIAL-PERMISSION" later).
-Georg
On 2019-08-14 07:37, Carsten Ziegeler wrote:
Hi,
please note that we have opened
https://issues.apache.org/jira/browse/FELIX-4194 for exactly this 6
years ago :) We can use either of the two issues but should mark one
of them as a duplicate.
We added [2] initially for exactly the purpose but never implemented it
:(
I think we might need some clever way of mapping roles. A plugin is
uniquely identifiable via its label. By default we might distinguish
between read and write permissions, so we could use "LABEL:READ" and
"LABEL:WRITE" for the roles to check for a plugin.
Plugins might however define additional roles - a user might be
allowed to modify a OSGi configuration but not remove or create new
ones. Or maybe just be allowed to modify certain configurations. I'm
not sure if we can handle all of these use cases with a first version
but it certainly helps in having this in mind.
Regards
Carsten
Am 14.08.2019 um 00:20 schrieb Georg Henzler:
Hi,
Konrad opened the ticket [1] to provide read-only access to the web
console. I also like the idea, but maybe we can make it more flexible
by introducing roles. This could be a simple OSGi mapping
configuration (list of read-only/full-access plugins by group name).
Two aspects would have to be covered:
1. Allowing/blocking requests: The web console servlet could check if
the user is in one of the configured groups using
WebConsoleSecurityProvider.authorize() [2] (this method is there but
seems not to be used at all at the moment), check if access is
configured for the request path's plugin and if yes, allow only GET
requests for read-only and all methods for full-access plugins.
2. Showing only links/buttons that are accessible
2a. The servlet can easily calculate the correct menu for a given user
2b. To hide links/buttons for 'write requests" in read-only mode,
plugins would have to check with the "web console container" if those
links should be shown or not (could be a OSGI service call or simply a
request attribute set by the web console servlet)
I think everything except 2b could be implemented solely in the web
console bundle itself and the fallback for 2b (just showing links that
don't work if clicked) is acceptable, especially since the mapping for
certain groups can only include plugins that already support the new
mechanism.
I'd be happy to work on this, but I'd like to hear opinions/concerns
about the outlined approach first...
-Georg
[1] https://issues.apache.org/jira/browse/FELIX-6169
[2]
https://github.com/apache/felix/blob/0bfe4ca7ebc6e81f0a9f4186a7ef58df4d92b4c9/webconsole/src/main/java/org/apache/felix/webconsole/WebConsoleSecurityProvider.java#L56
