JM-70
Descripation:
The admin console should not be a plugin since it’'s core functionality of the server. However, there still needs to be an easy way to disable Jetty starting up for app-server deployments.
I think admin console should be a plugin , because web container not be fixup
to Jetty,please talking to your solve plan !
This isn’‘t a super critical issue, but there’‘s really no reason for the admin console to be a plugin, and it’'s not a real plugin at the moment anyway. Other plugins depend on the admin console being in place so it should just be a core server feature.
-Matt
thanks matt !
admin console not a real plugin , change admin console is right feature
If the admin console is integrated into the core (which I think is a bad idea), it’'s important to allow disabling the HTTP access to it.
The reason is that many sysadmins are suspicious of any application that allows reconfiguration at runtime, bypassing the version control. I can understand how for the casual user this is a feature, but for us it’'s really a drawback.
And if we go further this route, even better would be to extract the functionality which is needed by the other plugins and distribute the webapp GUI as bundled plugin, so we can delete it if needed.
Another issue with the current implementation of the admin console is that it does not allow to specify read-only administrator accounts. IMHO, the best way to do this is to provide a JMX interface to all admin functionality and to let the user use the standard JMX access-control policies, but this is another issue.
Hi,
actually the admin console can be disabled by setting port and secureport to -1.
Plugins which depend on other plugins are something very common but I understand that this is harder to implement than make some components to core components.
JMX access is something which should really be considered. But also this can be a bad choice if it is implemented without security. To monitor the application (# db-connection in use, # connected users, # connected services) JMX should be very fine.
LG
You can have very fine grained security with JMX using JAAS principal-based policies and the RMI connector. IMHO it should be kept out of the Wildfire code as this is pure administrative isue. If the MBeans provide provide propper metadata about the action impact, a read-only policy would take literally 1 line.
JSR 160 - Chapter 3.4 ()
JSR 003 - Last Chapter (JMX Agent Specification / Security / Permissions)
http://java.sun.com/j2se/1.5.0/docs/guide/jmx/tutorial/security.html