Hmmm , Well I dont think that what I have done is a hack for 1.0 , may be that I have not dont the bast thing :)
So I will really appreciate that if you could suggest the correct way of handling this .You can either send us a patch or you can give us a constructive way of doing that. Jens Schumann (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/AXIS2-580?page=comments#action_12374876 > ] > >Jens Schumann commented on AXIS2-580: >------------------------------------- > >Looks like its being fixed. But don't get me wrong - this is just an Axis2 1.0 >Release hack. Isn't it;) > > > >>Admin Console Security does not work at all >>------------------------------------------- >> >> Key: AXIS2-580 >> URL: http://issues.apache.org/jira/browse/AXIS2-580 >> Project: Apache Axis 2.0 (Axis2) >> Type: Bug >> >> > > > >> Components: Tools >> Versions: 0.95 >> Reporter: Jens Schumann >> Priority: Blocker >> >> > > > >>(copy and paste from >>http://marc.theaimsgroup.com/?l=axis-dev&m=114528552707863&w=2 ) >>The current admin console security implementation contains several security >>flaws: >>- The security checks itself seem to happen in the VIEW only. After >>the action was processed. So if I am not mistaken I can manually create the >>admin URLs and deactivate services and so on. (Getting a rendering error of >>course afterwards) >>- One could argue that in a production environment you will not enable the >>AdminServlet. However it seems that the current AxisServlet doGet >>implementation will forward processing to the ListingAgent if there is no >>Soap Request. Which in turn means that I can disable services without >>knowing the username/password. >>To test the bug just deploy axis2.war and request the following URL. >>http://localhost:8080/axis2/inActivateService?axisService=version&turnoff=on&submit=+In-activate+ >> . version will be deactivated afterwards. >> >> > > > -- Thanks, Deepal ................................................................ ~Future is Open~
