Re: [DISCUSS] Role-based permissions to Web Console
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 -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Hi Thai, it's not easy to see what your problem is here, you will have to do some more debugging. I have some pointers though... I set service.ranking=1 because i'm running pax-web and it seems to execute filters in ascending ranking. "Higher rankings will be placed first in the chain, that is, filter chains are sorted in descending order." from [1] ... I also set avoid404DuringStartup=true and start level of healthcheck.core to level 3 (default is 4) because I want this filter to be up before my servlets and filters (default level 4). However, I always see "INFO o.a.f.h.c.i.f.ServiceUnavailableFilter - ServiceUnavailableFilter active (start level 4)" the log says it started at start level 4, so somehow the configuration you made for start level 3 did not work 1. In a dynamic env like osgi container, how can we be sure that a request always be processed by a filter before arriving at the servlet? Bundles do not always start in the same order thus a filter may be registered after the servlet it supposed to protect use start levels to ensure filters are started before the servlets (I think you are already trying to do this) 2. Even when i waited for a long period after starting my server and healthcheck return OK for all of my checks, why does ServiceUnavailableFilter not handle any request? If the health check returns OK the ServiceUnavailableFilter is not meant to kick in. Activate debug logging [2] to see if the filter is doing anything. Also ensure you left config property 'autoDisableFilter' to default 'false'. -Georg [1] https://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#filter-service-properties [2] https://github.com/apache/felix/blob/fd76982e887e82159288f1d0c1908402885d8e4c/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L288 https://github.com/apache/felix/blob/fd76982e887e82159288f1d0c1908402885d8e4c/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L264
[DISCUSS] Role-based permissions to Web Console
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
healthcheck: ServiceUnavailableFilter does not kick-in
Hello, I have about 30 servlet contexts (ServletContextHelper) scattered across multiple bundles. One of these context (WebviewerServletContextHelper) has "osgi.http.whiteboard.context.path=/". I also have one bundle containing all servletFilters for these servlet contexts. These filters mostly for session manipulation and security checks so If the request does not pass through these filters, it will cause exception when arriving at the servlet. Thus, i want to use ServiceUnavailableFilter from healthcheck to make sure that my filters (and other components) are ready before accepting http requests. I made the config file for ServiceUnavailableFilter as follow: osgi.http.whiteboard.filter.regex=(?!/system/).* osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name =WebviewerServletContextHelper) tags=systemalive responseTextFor503=Service Unavailable, wait.. wait... wait service.ranking=1 avoid404DuringStartup=true I set service.ranking=1 because i'm running pax-web and it seems to execute filters in ascending ranking. I also set avoid404DuringStartup=true and start level of healthcheck.core to level 3 (default is 4) because I want this filter to be up before my servlets and filters (default level 4). However, I always see "INFO o.a.f.h.c.i.f.ServiceUnavailableFilter - ServiceUnavailableFilter active (start level 4)" which indicates the component has been activated but the ServiceUnavailableFilter never process any request. So here are some questions 1. In a dynamic env like osgi container, how can we be sure that a request always be processed by a filter before arriving at the servlet? Bundles do not always start in the same order thus a filter may be registered after the servlet it supposed to protect 2. Even when i waited for a long period after starting my server and healthcheck return OK for all of my checks, why does ServiceUnavailableFilter not handle any request? About my env, I'm using org.apache.felix.healthcheck.annotation_2.0.0 org.apache.felix.healthcheck.api_2.0.0 org.apache.felix.healthcheck.core_2.0.6 org.apache.felix.healthcheck.generalchecks_2.0.4 and pax-web 7.2.4 in equinox (org.eclipse.osgi_3.12.0.v20170512-1932) Hope someone can shed a light Thai
[jira] [Resolved] (FELIX-6170) NPE in web console plugin if context path is missing for ServletContextHelper
[ https://issues.apache.org/jira/browse/FELIX-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-6170. - Resolution: Fixed Fixed in 1865046. > NPE in web console plugin if context path is missing for ServletContextHelper > - > > Key: FELIX-6170 > URL: https://issues.apache.org/jira/browse/FELIX-6170 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: http.base-4.0.6, http.jetty-4.0.10, http.bridge-4.0.8 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: http.jetty-4.0.12, http.base-4.0.8, http.bridge-4.0.10 > > > If a ServletContextHelper without a path property is registered this results > in an NPE: > 13.08.2019 17:25:44.904 *ERROR* [FelixLogListener] > org.apache.felix.http.jetty.light Exception while processing request to > /system/console/httpservice (java.lang.NullPointerException) > java.lang.NullPointerException: null > at > org.apache.felix.http.base.internal.console.HttpServicePlugin.getContextPath(HttpServicePlugin.java:396) > at > org.apache.felix.http.base.internal.console.HttpServicePlugin.printFailedContextDetails(HttpServicePlugin.java:458) > at > org.apache.felix.http.base.internal.console.HttpServicePlugin.doGet(HttpServicePlugin.java:229) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (FELIX-6170) NPE in web console plugin if context path is missing for ServletContextHelper
Carsten Ziegeler created FELIX-6170: --- Summary: NPE in web console plugin if context path is missing for ServletContextHelper Key: FELIX-6170 URL: https://issues.apache.org/jira/browse/FELIX-6170 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: http.bridge-4.0.8, http.jetty-4.0.10, http.base-4.0.6 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: http.base-4.0.8, http.bridge-4.0.10, http.jetty-4.0.12 If a ServletContextHelper without a path property is registered this results in an NPE: 13.08.2019 17:25:44.904 *ERROR* [FelixLogListener] org.apache.felix.http.jetty.light Exception while processing request to /system/console/httpservice (java.lang.NullPointerException) java.lang.NullPointerException: null at org.apache.felix.http.base.internal.console.HttpServicePlugin.getContextPath(HttpServicePlugin.java:396) at org.apache.felix.http.base.internal.console.HttpServicePlugin.printFailedContextDetails(HttpServicePlugin.java:458) at org.apache.felix.http.base.internal.console.HttpServicePlugin.doGet(HttpServicePlugin.java:229) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (FELIX-6037) Commons FileUpload 1.4 + Apache Felix Bundle WebConsole
[ https://issues.apache.org/jira/browse/FELIX-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906281#comment-16906281 ] Rakesh Kumar commented on FELIX-6037: - v1.3.3 may not have any security issues but there are plenty of "major" bug fixed in v1.4 which we cant miss. I think v.1.4.1 release makes more sense to me. > Commons FileUpload 1.4 + Apache Felix Bundle WebConsole > --- > > Key: FELIX-6037 > URL: https://issues.apache.org/jira/browse/FELIX-6037 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-4.3.8 >Reporter: Dan Klco >Priority: Major > > When using Commons Fileupload with the Apache Felix Bundle webconsole, I've > found an error when uploading SNAPSHOT bundles to the webconsole. The process > fails with the following exception: > 23.01.2019 06:56:29.098 *ERROR* [qtp24255790-48] org.apache.felix.http.jetty > Problem accessing uploaded bundle file: > org.apache.sling.cms.ui-0.11.3-SNAPSHOT.jar > (org.apache.commons.io.FileExistsException: Destination > '/var/folders/lk/m1djs7v96_b9xfy_7_xhn33hgq/T/install8148467763631161526.tmp' > already exists) > org.apache.commons.io.FileExistsException: Destination > '/var/folders/lk/m1djs7v96_b9xfy_7_xhn33hgq/T/install8148467763631161526.tmp' > already exists > at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001) > [org.apache.commons.io:2.6.0] > at > org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) > [org.apache.commons.commons-fileupload:1.4.0] > at > org.apache.felix.webconsole.internal.core.BundlesServlet.installBundles(BundlesServlet.java:1553) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:330) > [org.apache.felix.webconsole:4.3.8] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:644) > [org.apache.felix.http.servlet-api:1.1.2] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) > [org.apache.felix.http.servlet-api:1.1.2] > at > org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:563) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.webconsole.internal.servlet.OsgiManager$3.run(OsgiManager.java:465) > [org.apache.felix.webconsole:4.3.8] > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:461) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:120) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:86) > [org.apache.felix.http.jetty:4.0.6] > at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:131) > [org.apache.sling.i18n:2.5.14] > at > org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:81) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.Dispatcher$1.doFilter(Dispatcher.java:146) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1014) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.sslfilter.internal.SslFilter.doFilter(SslFilter.java:97) > [org.apache.felix.http.sslfilter:1.2.6] > at > org.apache.felix.http.base.internal.handler.PreprocessorHandler.handle(PreprocessorHandler.java:133) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1020) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager.invokePreprocessors(WhiteboardManager.java:1024) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:91) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.DispatcherServlet.service(DispatcherServlet.java:49) > [org.apache.felix.http.jetty:4.0.6] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) > [org.apache.felix.http.servlet-api:1.1.2] > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) > [org.apache.felix.http.jetty:4.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) > [org.apache.felix.http.jetty:4.0.6] > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > [org.apach
[jira] [Commented] (FELIX-6037) Commons FileUpload 1.4 + Apache Felix Bundle WebConsole
[ https://issues.apache.org/jira/browse/FELIX-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906253#comment-16906253 ] Carsten Ziegeler commented on FELIX-6037: - [~rakeshk15] the web console depends on file upload v1.2.1 as a minimum - you can deploy it with any higher version, recommended at this point in time is 1.3.3 which does not have security issues reported (afaik). We can't recommend 1.4.0 for the problems mentioned here. I dont know how we can put more pressue on commons to make a 1.4.1 release. [~joc...@apache.org] any thoughts on this one? > Commons FileUpload 1.4 + Apache Felix Bundle WebConsole > --- > > Key: FELIX-6037 > URL: https://issues.apache.org/jira/browse/FELIX-6037 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-4.3.8 >Reporter: Dan Klco >Priority: Major > > When using Commons Fileupload with the Apache Felix Bundle webconsole, I've > found an error when uploading SNAPSHOT bundles to the webconsole. The process > fails with the following exception: > 23.01.2019 06:56:29.098 *ERROR* [qtp24255790-48] org.apache.felix.http.jetty > Problem accessing uploaded bundle file: > org.apache.sling.cms.ui-0.11.3-SNAPSHOT.jar > (org.apache.commons.io.FileExistsException: Destination > '/var/folders/lk/m1djs7v96_b9xfy_7_xhn33hgq/T/install8148467763631161526.tmp' > already exists) > org.apache.commons.io.FileExistsException: Destination > '/var/folders/lk/m1djs7v96_b9xfy_7_xhn33hgq/T/install8148467763631161526.tmp' > already exists > at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001) > [org.apache.commons.io:2.6.0] > at > org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) > [org.apache.commons.commons-fileupload:1.4.0] > at > org.apache.felix.webconsole.internal.core.BundlesServlet.installBundles(BundlesServlet.java:1553) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:330) > [org.apache.felix.webconsole:4.3.8] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:644) > [org.apache.felix.http.servlet-api:1.1.2] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) > [org.apache.felix.http.servlet-api:1.1.2] > at > org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:563) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.webconsole.internal.servlet.OsgiManager$3.run(OsgiManager.java:465) > [org.apache.felix.webconsole:4.3.8] > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:461) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:120) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:86) > [org.apache.felix.http.jetty:4.0.6] > at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:131) > [org.apache.sling.i18n:2.5.14] > at > org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:81) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.Dispatcher$1.doFilter(Dispatcher.java:146) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1014) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.sslfilter.internal.SslFilter.doFilter(SslFilter.java:97) > [org.apache.felix.http.sslfilter:1.2.6] > at > org.apache.felix.http.base.internal.handler.PreprocessorHandler.handle(PreprocessorHandler.java:133) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1020) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager.invokePreprocessors(WhiteboardManager.java:1024) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:91) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.DispatcherServlet.service(DispatcherServlet.java:49) > [org.apache.felix.http.jetty:4.0.6] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) > [org.apache.felix.http.servlet-api:1.1.2] > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) > [org.apache
[jira] [Commented] (FELIX-6037) Commons FileUpload 1.4 + Apache Felix Bundle WebConsole
[ https://issues.apache.org/jira/browse/FELIX-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906243#comment-16906243 ] Rakesh Kumar commented on FELIX-6037: - [~cziegeler] the issue in file upload FILEUPLOAD-293 seems to be fixed for months now and the targeted release v1.4.1 is yet to make it to maven central. So my question is, what should we do here? Just wait indefinitely for 1.4.1 or is it something worth fixing in Felix Webconsole itself. Also, the Felix Webconsole can't just keep using very old version of file upload which is having security issues, currently it is dependent on v1.2.1. Please let me know your thoughts. Thanks, Rakesh > Commons FileUpload 1.4 + Apache Felix Bundle WebConsole > --- > > Key: FELIX-6037 > URL: https://issues.apache.org/jira/browse/FELIX-6037 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-4.3.8 >Reporter: Dan Klco >Priority: Major > > When using Commons Fileupload with the Apache Felix Bundle webconsole, I've > found an error when uploading SNAPSHOT bundles to the webconsole. The process > fails with the following exception: > 23.01.2019 06:56:29.098 *ERROR* [qtp24255790-48] org.apache.felix.http.jetty > Problem accessing uploaded bundle file: > org.apache.sling.cms.ui-0.11.3-SNAPSHOT.jar > (org.apache.commons.io.FileExistsException: Destination > '/var/folders/lk/m1djs7v96_b9xfy_7_xhn33hgq/T/install8148467763631161526.tmp' > already exists) > org.apache.commons.io.FileExistsException: Destination > '/var/folders/lk/m1djs7v96_b9xfy_7_xhn33hgq/T/install8148467763631161526.tmp' > already exists > at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001) > [org.apache.commons.io:2.6.0] > at > org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) > [org.apache.commons.commons-fileupload:1.4.0] > at > org.apache.felix.webconsole.internal.core.BundlesServlet.installBundles(BundlesServlet.java:1553) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:330) > [org.apache.felix.webconsole:4.3.8] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:644) > [org.apache.felix.http.servlet-api:1.1.2] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) > [org.apache.felix.http.servlet-api:1.1.2] > at > org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:563) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.webconsole.internal.servlet.OsgiManager$3.run(OsgiManager.java:465) > [org.apache.felix.webconsole:4.3.8] > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:461) > [org.apache.felix.webconsole:4.3.8] > at > org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:120) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:86) > [org.apache.felix.http.jetty:4.0.6] > at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:131) > [org.apache.sling.i18n:2.5.14] > at > org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:81) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.Dispatcher$1.doFilter(Dispatcher.java:146) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1014) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.sslfilter.internal.SslFilter.doFilter(SslFilter.java:97) > [org.apache.felix.http.sslfilter:1.2.6] > at > org.apache.felix.http.base.internal.handler.PreprocessorHandler.handle(PreprocessorHandler.java:133) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1020) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.whiteboard.WhiteboardManager.invokePreprocessors(WhiteboardManager.java:1024) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:91) > [org.apache.felix.http.jetty:4.0.6] > at > org.apache.felix.http.base.internal.dispatch.DispatcherServlet.service(DispatcherServlet.java:49) > [org.apache.felix.http.jetty:4.0.6] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) > [org.apache.felix.http.servlet-api:1.1.2]
[jira] [Work started] (FELIX-6168) Enable WebConsole login only after specified Security Providers are present
[ https://issues.apache.org/jira/browse/FELIX-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-6168 started by David Bosschaert. --- > Enable WebConsole login only after specified Security Providers are present > --- > > Key: FELIX-6168 > URL: https://issues.apache.org/jira/browse/FELIX-6168 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.3.12 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > It should be possible to configure the WebConsole to only accept logins after > specified Security Providers are found. > If these security providers are not yet registered in the Service Registry, > logging in should be disabled. The local plain username/password approach > should not provide the opportunity to log in, in that case. > The configuration to enable this should be provided as a framework property. > This approach is similar to what has been implemented for ConfigAdmin in > FELIX-6059 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (FELIX-6168) Enable WebConsole login only after specified Security Providers are present
[ https://issues.apache.org/jira/browse/FELIX-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906078#comment-16906078 ] David Bosschaert commented on FELIX-6168: - Thanks for the idea, [~cziegeler]. I have updated the description accordingly. > Enable WebConsole login only after specified Security Providers are present > --- > > Key: FELIX-6168 > URL: https://issues.apache.org/jira/browse/FELIX-6168 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.3.12 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > It should be possible to configure the WebConsole to only accept logins after > specified Security Providers are found. > If these security providers are not yet registered in the Service Registry, > logging in should be disabled. The local plain username/password approach > should not provide the opportunity to log in, in that case. > The configuration to enable this should be provided as a framework property. > This approach is similar to what has been implemented for ConfigAdmin in > FELIX-6059 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (FELIX-6168) Enable WebConsole login only after specified Security Providers are present
[ https://issues.apache.org/jira/browse/FELIX-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-6168: Description: It should be possible to configure the WebConsole to only accept logins after specified Security Providers are found. If these security providers are not yet registered in the Service Registry, logging in should be disabled. The local plain username/password approach should not provide the opportunity to log in, in that case. The configuration to enable this should be provided as a framework property. This approach is similar to what has been implemented for ConfigAdmin in FELIX-6059 was: It should be possible to disable plain username/password access to the WebConsole. When disabled, a simple user name and password (such as the default admin/admin) does not work any more. The WebConsole Security Provider should be the only enabled mechanism to log in. Disabling should happen through configuration or a framework property. > Enable WebConsole login only after specified Security Providers are present > --- > > Key: FELIX-6168 > URL: https://issues.apache.org/jira/browse/FELIX-6168 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.3.12 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > It should be possible to configure the WebConsole to only accept logins after > specified Security Providers are found. > If these security providers are not yet registered in the Service Registry, > logging in should be disabled. The local plain username/password approach > should not provide the opportunity to log in, in that case. > The configuration to enable this should be provided as a framework property. > This approach is similar to what has been implemented for ConfigAdmin in > FELIX-6059 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (FELIX-6168) Enable WebConsole login only after specified Security Providers are present
[ https://issues.apache.org/jira/browse/FELIX-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-6168: Summary: Enable WebConsole login only after specified Security Providers are present (was: Disable username/password access to WebConsole) > Enable WebConsole login only after specified Security Providers are present > --- > > Key: FELIX-6168 > URL: https://issues.apache.org/jira/browse/FELIX-6168 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.3.12 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > It should be possible to disable plain username/password access to the > WebConsole. > When disabled, a simple user name and password (such as the default > admin/admin) does not work any more. > The WebConsole Security Provider should be the only enabled mechanism to log > in. > Disabling should happen through configuration or a framework property. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (FELIX-6168) Disable username/password access to WebConsole
[ https://issues.apache.org/jira/browse/FELIX-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906071#comment-16906071 ] Carsten Ziegeler commented on FELIX-6168: - [~bosschaert] I think it would also make sense to require a specific authentication plugin (by referencing some service property like a name, id etc.). This way it can be ensured that the web console is only active if such an auth plugin is available > Disable username/password access to WebConsole > -- > > Key: FELIX-6168 > URL: https://issues.apache.org/jira/browse/FELIX-6168 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.3.12 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > It should be possible to disable plain username/password access to the > WebConsole. > When disabled, a simple user name and password (such as the default > admin/admin) does not work any more. > The WebConsole Security Provider should be the only enabled mechanism to log > in. > Disabling should happen through configuration or a framework property. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (FELIX-6169) Read-Only role for Web Console
[ https://issues.apache.org/jira/browse/FELIX-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906047#comment-16906047 ] Konrad Windszus commented on FELIX-6169: This probably duplicates FELIX-4194. > Read-Only role for Web Console > -- > > Key: FELIX-6169 > URL: https://issues.apache.org/jira/browse/FELIX-6169 > Project: Felix > Issue Type: Improvement > Components: Web Console >Reporter: Konrad Windszus >Priority: Major > > Currently access to the web console allows both read as well as write > operations (i.e. changing OSGi configurations, starting/stopping bundles, > ...). The role model should be enhanced to support two distinct roles: > 1. admin > 2. read-only > The second role should only be allowed to retrieve information about the > Felix Container but not to change it. > Use-Case: For debugging purposes it is often crucial to access the web > console (i.e. for developers), but only very few people (admins) should have > the privileges to change something there. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (FELIX-6169) Read-Only role for Web Console
Konrad Windszus created FELIX-6169: -- Summary: Read-Only role for Web Console Key: FELIX-6169 URL: https://issues.apache.org/jira/browse/FELIX-6169 Project: Felix Issue Type: Improvement Components: Web Console Reporter: Konrad Windszus Currently access to the web console allows both read as well as write operations (i.e. changing OSGi configurations, starting/stopping bundles, ...). The role model should be enhanced to support two distinct roles: 1. admin 2. read-only The second role should only be allowed to retrieve information about the Felix Container but not to change it. Use-Case: For debugging purposes it is often crucial to access the web console (i.e. for developers), but only very few people (admins) should have the privileges to change something there. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (FELIX-6168) Disable username/password access to WebConsole
[ https://issues.apache.org/jira/browse/FELIX-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-6168: --- Assignee: David Bosschaert > Disable username/password access to WebConsole > -- > > Key: FELIX-6168 > URL: https://issues.apache.org/jira/browse/FELIX-6168 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.3.12 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > It should be possible to disable plain username/password access to the > WebConsole. > When disabled, a simple user name and password (such as the default > admin/admin) does not work any more. > The WebConsole Security Provider should be the only enabled mechanism to log > in. > Disabling should happen through configuration or a framework property. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (FELIX-6168) Disable username/password access to WebConsole
David Bosschaert created FELIX-6168: --- Summary: Disable username/password access to WebConsole Key: FELIX-6168 URL: https://issues.apache.org/jira/browse/FELIX-6168 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-4.3.12 Reporter: David Bosschaert It should be possible to disable plain username/password access to the WebConsole. When disabled, a simple user name and password (such as the default admin/admin) does not work any more. The WebConsole Security Provider should be the only enabled mechanism to log in. Disabling should happen through configuration or a framework property. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
