> Amy Roh wrote: > > Remy Maucherat wrote: > > > >> [EMAIL PROTECTED] wrote: > >> > >>> amyroh 2003/02/10 18:27:15 > >>> > >>> Modified: webapps/admin build.xml > >>> webapps/admin/WEB-INF/classes/org/apache/webapp/admin > >>> ApplicationResources_en.properties > >>> ApplicationResources_es.properties > >>> > >>> webapps/admin/WEB-INF/classes/org/apache/webapp/admin/valve > >>> RemoteAddrValveForm.java > >>> RemoteHostValveForm.java > >>> ValveUtil.java > >>> Log: > >>> Add validation for RemoteAddrValve and RemoteHostValve to prevent > >>> installing a filter that prevents the admin's own access. > >> > >> > >> > >> I don't understand what this does over the stanadard remote host/addr > >> valves. > >> If the maintainer of server.xml wishes to deny access to the "admin", > >> then he has the right to do so IMO. I don't agree with forcing the > >> localhost to have access, essentially. I may have an idea of where > >> this new "feature" is coming from ;-) > > > > > > If the maintainer of server.xml or tomcat wishes to deny access to the > > "admin", he can surely do so by editing server.xml and is recommended to > > do so if that's what he desires. This patch doesn't prevent that > > availability. This patch only adds validation in admin to prevent the > > admin to crash because if the user, who doesn't have better idea how > > these filters work, just create these filters that deny access to its > > own admin while running admin will cause the whole admin to crash. Just > > try adding these valves with deny attribute "127.0.0.1", the whole admin > > will crash before this patch. Again, this is just a validation of > > inputs that will have admin continue to work instead of limiting these > > filters usage. Also note that you can still create these filters to > > prevent admin access from other ip addresses or host other than admin's > > own ip and host. > > Yes, but IMO, it's the admin's problem. The admin webapp shouldn't > duplicate the functionality that it present elsewhere. Also, if the > admin wishes to disable access from localhost (and access from > elsewhere), then he has the right to do so.
I see your point regarding the admin should let disabling access from localhost if it's accessing from elsewhere. How about if I remove checking for localhost and just keep the checking for admin's own ip and host? > > Sorry, but you can only go so far with the "for dummy" factor ... I know. I know. ;-) Amy > > Remy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
