hi Carsten, right, I agree with Thomas there is a room for improving the security of the Webconsole (Specially in edge cases like startup).
How about opening a new JIRA issue and trying to brainstorm something (unfortunately I can’t remember anymore the details of my previous idea :() regards antonio > On Mar 23, 2018, at 12:32 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > > Hi, > > > username/password can also be set using framework properties, with that > it is possible to secure the webconsole without the configuration of a > provider being available. > > The framework property approach is maybe not the nicest way either. > > Often the web console is regarded as the last resort when things go > wrong, therefore tying it to configuration admin or a provider would > prevent access to the web console. > > I think Antonio suggested something similar (requiring the provider but > having a way to get to the web console if the provider is not available) > a while ago. @Antonio do you remember the approach? > > Regards > > Carsten > > > Thomas Baier wrote >> Hi, >> >> >> we recently ran into an issue that the webconsole in an application was >> accessible with the default user credentials because the configuration was >> not picked up for some reason. Therefore the following question: >> >> >> Security for the web console is either setup by adding a configuration or by >> using a WebConsoleSecurityProvider, if I understand it correctly both >> mechanisms are optional and loaded dynamically. Doesn't that mean that if >> those configs/services are temporarily not (yet) available, which can happen >> even during normal operation, e.g. during application startup, access to the >> webconsole is not secured anymore? If yes, wouldn't it be more appropriate >> to make the configuration mandatory instead of optional? >> >> >> Best regards, >> >> Thomas >> > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
