wt., 24 maj 2022 o 15:52 Gerald Kallas <[email protected]> napisał(a):
> I did update to 8.0.4. The concurrent servlets are working fine with the > authentication/authorization. > > The only issue still is when I'm going to delete the file sample1.xml from > the deploy folder and the file org.ops4j.pax.web.context-admin.sample1.cfg > from the etc folder, an request like > > curl --insecure --request GET 'https://localhost:8443/test1/hello' -u > testuser:passw0rd_ > > still returns a HTTP 401. > > After the karaf restart the return is a HTTP 404 as I'd expect. > Thanks for checking would you mind adding this comment to https://github.com/ops4j/org.ops4j.pax.web/issues/1720 ? And btw - you're using pax-web-http-jetty, right? I'm pretty sure that uninstalling a bundle cleans up the context... But I'll check once again regards Grzegorz Grzybek > > Best > Gerald > > P.S. The installation with all the dependencies is a bit time consuming, > so is there a way to create an OSGi feature for pax-web-jetty after the > maven build locally? > > Grzegorz Grzybek <[email protected]> hat am 24.05.2022 07:17 > geschrieben: > > > > > pon., 23 maj 2022 o 21:35 Gerald Kallas <[email protected]> > napisał(a): > > Unfortunately there seems to be another requirement for the update .. > > update org.ops4j.pax.web.pax-web-jetty > file:///home/casisp/install/pax-web-jetty-8.0.4-SNAPSHOT.jar > Error executing command: Unable to resolve org.ops4j.pax.web.pax-web-jetty > [239](R 239.1): missing requirement [org.ops4j.pax.web.pax-web-jetty > [239](R 239.1)] osgi.wiring.package; > (&(osgi.wiring.package=org.ops4j.pax.web.service)(version>=8.0.4.SNAPSHOT)) > Unresolved requirements: [[org.ops4j.pax.web.pax-web-jetty [239](R 239.1)] > osgi.wiring.package; > (&(osgi.wiring.package=org.ops4j.pax.web.service)(version>=8.0.4.SNAPSHOT))] > > > Ah yes... Wouldn't be a problem for you if you simply clone the project > and build it using `mvn clean install -DskipTests`? It should be a moment > ;) > > regards > Grzegorz Grzybek > > > > Grzegorz Grzybek <[email protected]> hat am 23.05.2022 12:44 > geschrieben: > > > > > pon., 23 maj 2022 o 12:30 Gerald Kallas <[email protected]> > napisał(a): > > Hi Grzegorz, > > from what I see you got the problem right. Is there a way that you can > provide a module pre-version (pax-web-jetty?) with the fix that I can test > also on my side with both blueprints? > > > Assuming you're using Jetty, here's pax-web-jetty-8.0.4-SNAPSHOT.jar I've > just built: > https://drive.google.com/file/d/1GLgJFZ6GTo5Cw_AMUYrh08LNz0PU_wra/view?usp=sharing > - you can use it if you feel safe enough ;) > If not, you can simply `mvn clean install -DskipTests` main branch of > https://github.com/ops4j/org.ops4j.pax.web > > Then, in Karaf, you can invoke: > > > karaf@root> update org.ops4j.pax.web.pax-web-jetty > file:///path/to/pax-web-jetty-8.0.4-SNAPSHOT.jar > > > to update your version of pax-web-jetty with the new one. > > regards > Grzegorz Grzybek > > > > Best > Gerald > > Grzegorz Grzybek <[email protected]> hat am 23.05.2022 11:11 > geschrieben: > > > Hello again > > @Gerald Kallas <[email protected]> I hope I've fixed your problem. > > Please check this integration test > <https://github.com/ops4j/org.ops4j.pax.web/blob/67f9166465d16bb093d91535151b4a650202a7b8/pax-web-itest/pax-web-itest-container/pax-web-itest-container-common/src/main/java/org/ops4j/pax/web/itest/container/httpservice/AbstractDoubleHttpServiceProcessingIntegrationTest.java#L66>[1] > if I got the problem right. Roughly it registers two servlets (/test1/* and > /test2/*) and then checks different scenarios after creating/removing > org.ops4j.pax.web.context factory PIDs for both bundles and finally > uninstalls one of the bundles. > The result should be a proper combination of HTTP 200, HTTP 404 and HTTP > 401. > > kind regards > Grzegorz Grzybek > === > [1]: > https://github.com/ops4j/org.ops4j.pax.web/blob/67f9166465d16bb093d91535151b4a650202a7b8/pax-web-itest/pax-web-itest-container/pax-web-itest-container-common/src/main/java/org/ops4j/pax/web/itest/container/httpservice/AbstractDoubleHttpServiceProcessingIntegrationTest.java#L66 > > > pon., 23 maj 2022 o 09:46 Grzegorz Grzybek <[email protected]> > napisał(a): > > Hello > > I've created https://github.com/ops4j/org.ops4j.pax.web/issues/1720 to > track this problem > > This "context processing" features was added to Pax Web 7 and it was > roughly collecting security information from the factory PIDs and > adding/removing them to/from target _physical_ context. > > When I ported this feature to completely refactored Pax Web 8, I took into > account the separation between _physical_ context and _OSGi_ context due to > Whiteboard specification compliance. > > The effect you've found (and I missed the integration tests for) is that > with two bundles registering servlets to "/" context, you have one > _physical_ context ("/") but two separate _OSGi contexts and the context > from bundle1 has "higher rank". > > I didn't think about this important separation too much wrt "context > processing". > > But now I see I took the road of "bigger surprise". I'm going to fix #1720 > by simply taking all security information (regardless of the originating > OSGi context) and add/remove them to/from the target _physical context_. > > Please expect a fix soon (I hope today) and a release in near future (most > probably this week). > > kind regards > Grzegorz Grzybek > > On 2022/05/19 22:59:04 Gerald Kallas wrote: > > Hi folks. > > > > I do have a vanilla Karaf 4.4.0 installation with Camel 3.14.3 with the > modules > > > > pax-web-jetty > > hawtio > > activemq-broker-noweb > > camel > > camel-jms > > jms > > camel-http > > camel-servlet > > camel-swagger-java > > camel-ftp > > camel-jackson > > camel-jsonpath > > camel-json-validator > > camel-zipfile > > camel-velocity > > camel-groovy > > camel-salesforce > > camel-kafka > > > > > > Further I do have a Blueprint route sample1.xml like > > > > <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; > > xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"; > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation=" > > http://www.osgi.org/xmlns/blueprint/v1.0.0 > https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";> > > <reference id="httpService" > interface="org.osgi.service.http.HttpService" /> > > <bean id="camelServlet1" > class="org.apache.camel.component.servlet.CamelHttpTransportServlet"/> > > <bean > class="org.apache.camel.component.servlet.osgi.OsgiServletRegisterer" > > init-method="register" > > destroy-method="unregister"> > > <property name="servletName" value="servlet1" /> > > <property name="alias" value="/test1" /> > > <property name="httpService" ref="httpService" /> > > <property name="servlet" ref="camelServlet1" /> > > </bean> > > <camelContext id="sample1" xmlns=" > http://camel.apache.org/schema/blueprint";> > > <route> > > <from uri="servlet://hello?servletName=servlet1" /> > > <log message="Hello Camel 1!" /> > > </route> > > </camelContext> > > </blueprint> > > > > and a security configuration org.ops4j.pax.web.context-admin.sample1.cfg > like > > > > bundle.symbolicName=sample1.xml > > login.config.authMethod=BASIC > > login.config.realmName=karaf > > context.id=default > > security.constraint.1.url = /test1/hello/* > > security.constraint.1.roles = testrole > > > > Authentication/authorization works fine with > > > > curl --insecure --request GET 'https://localhost:8443/test1/hello' -u > testuser:passw0rd > > > > returns HTTP 200 > > > > curl --insecure --request GET 'https://localhost:8443/test1/hello' > > > > returns HTTP 401 > > > > > > When I'm going to add a 2nd Blueprint route sample2.xml like > > > > <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; > > xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"; > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation=" > > http://www.osgi.org/xmlns/blueprint/v1.0.0 > https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";> > > <reference id="httpService" > interface="org.osgi.service.http.HttpService" /> > > <bean id="camelServlet2" > class="org.apache.camel.component.servlet.CamelHttpTransportServlet"/> > > <bean > class="org.apache.camel.component.servlet.osgi.OsgiServletRegisterer" > > init-method="register" > > destroy-method="unregister"> > > <property name="servletName" value="servlet2" /> > > <property name="alias" value="/test2" /> > > <property name="httpService" ref="httpService" /> > > <property name="servlet" ref="camelServlet2" /> > > </bean> > > <camelContext id="sample2" xmlns=" > http://camel.apache.org/schema/blueprint";> > > <route> > > <from uri="servlet://hello?servletName=servlet2" /> > > <log message="Hello Camel 2!" /> > > </route> > > </camelContext> > > </blueprint> > > > > with the security configuration > org.ops4j.pax.web.context-admin.sample2.cfg like > > > > bundle.symbolicName=sample2.xml > > login.config.authMethod=BASIC > > login.config.realmName=karaf > > context.id=default > > security.constraint.1.url = /test2/hello/* > > security.constraint.1.roles = testrole > > > > the authentication/authorization for the 2nd route doesn't work as > expected. The endpoint > > > > curl --insecure --request GET 'https://localhost:8443/test2/hello' > > > > returns a HTTP 200 (I'm expecting a HTTP 401 w/o user:password). > > > > > > When I'm going to remove sample1.xml, the call to the sample2.xml > endpoint > > > > curl --insecure --request GET 'https://localhost:8443/test2/hello' -u > testuser:passw0rd > > > > returns a HTTP 404. When I'm going to re-deploy the sample2.xml, the > sample2.xml endpoint works fine, even with authentication/authorization. > > > > Any ideas about this behaviour are highly appreciated. > > > > Best > > Gerald > >
