[JBoss JIRA] (WFLY-3590) Option to disable processing of authentication tokens on unsecured resources.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3590?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3590:
-------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> Option to disable processing of authentication tokens on unsecured resources.
> -----------------------------------------------------------------------------
>
> Key: WFLY-3590
> URL: https://issues.jboss.org/browse/WFLY-3590
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Oracle Java 1.8.0_05, Ubuntu 14.04
> Reporter: Harald Wellmann
> Assignee: Stuart Douglas
> Fix For: 10.0.0.Alpha3
>
>
> WildFly sends a basic authentication challenge and denies access when it shouldn't in the following simple setup:
> {code:xml}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>test</realm-name>
> </login-config>
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>all</web-resource-name>
> <url-pattern>/hello</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>USER</role-name>
> </auth-constraint>
> </security-constraint>
>
> <security-role>
> <role-name>USER</role-name>
> </security-role>
> {code}
> {{/hello}} is the only protected URL (mapped to a servlet), other URLs like {{/index.html}} are public.
> When GETting /index.html with an (unneeded) basic authentication header, access is denied:
> {noformat}
> $ curl -v -u foo:bar http://localhost:8080/auth-basic/index.html
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 8080 (#0)
> * Server auth using Basic with user 'foo'
> > GET /auth-basic/index.html HTTP/1.1
> > Authorization: Basic Zm9vOmJhcg==
> > User-Agent: curl/7.35.0
> > Host: localhost:8080
> > Accept: */*
> >
> < HTTP/1.1 401 Unauthorized
> < Connection: keep-alive
> * Authentication problem. Ignoring this.
> < WWW-Authenticate: Basic realm="test"
> < X-Powered-By: Undertow/1
> * Server WildFly/8 is not blacklisted
> < Server: WildFly/8
> < Content-Type: text/html;charset=ISO-8859-1
> < Content-Length: 71
> < Date: Mon, 07 Jul 2014 17:28:25 GMT
> <
> * Connection #0 to host localhost left intact
> <html><head><title>Error</title></head><body>Unauthorized</body></html>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-3583) Convert mod_cluster excluded context into an xs:list of host:context
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3583?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3583:
-------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> Convert mod_cluster excluded context into an xs:list of host:context
> --------------------------------------------------------------------
>
> Key: WFLY-3583
> URL: https://issues.jboss.org/browse/WFLY-3583
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 10.0.0.Alpha3
>
>
> {noformat}
> // TODO: Convert into an xs:list of host:context
> static final SimpleAttributeDefinition EXCLUDED_CONTEXTS = SimpleAttributeDefinitionBuilder.create(CommonAttributes.EXCLUDED_CONTEXTS, ModelType.STRING, true)
> .setAllowExpression(true)
> .setDefaultValue(new ModelNode("ROOT,invoker,jbossws,juddi,console"))
> .setRestartAllServices()
> .build();
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-3573) Adding incorrect JGroups protocol should provide better error description than CNFE
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3573?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3573:
-------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> Adding incorrect JGroups protocol should provide better error description than CNFE
> -----------------------------------------------------------------------------------
>
> Key: WFLY-3573
> URL: https://issues.jboss.org/browse/WFLY-3573
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: JBoss AS7 7.2.0.Final, 8.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.0.0.Alpha3
>
>
> As reported by the community user:
> {noformat}
> [standalone@localhost:9990 / #] list-batch
> #1 /subsystem=jgroups/stack=test:add()
> #2 /subsystem=jgroups/stack=test/transport=TRANSPORT:add(type="udp",socket-binding=jgroups-udp)
> #3 /subsystem=jgroups/stack=test:add-protocol(type=FD_SOCK,socket-binding=jgroups-udp-fd)
> [standalone@localhost:9990 / #] run-batch
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0158: Operation handler failed: java.lang.ClassNotFoundException: org.jgroups.protocols.udp from [Module \"org.jboss.as.clustering.jgroups:main\" from local module loader @4d9f6ce5 (finder: local module finder @1da65633 (roots: /home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules,/home/rhusar/as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]"}}
> [standalone@localhost:9990 / #]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4120) JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-4120?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-4120:
-------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-4120
> URL: https://issues.jboss.org/browse/WFLY-4120
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Environment: Windows 8.1
> Reporter: Manfred Otte
> Assignee: Alessio Soldano
> Priority: Minor
> Fix For: 10.0.0.Alpha3
>
> Attachments: testjsr109.war
>
>
> Regarding JSR 109, chapter 6.3 the "handler chain file can also be packaged and specified in the annotation such that, it is accessible as a resource from the ClassPath. At runtime, container providers must first try to access the handler chain file as per the locations specified in JSR-181 specification. Failing that, they must try to access it as a resource from the ClassPath."
> The JBoss AS Documentation states that "The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes in WEB-INF/classes. All classes packaged in the war will be loaded with the same class loader" (https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7).
> Following this statements I think it should be fine to have a HandlerChain-annnotated Webservice within a JAR inside a WAR (WEB-INF/lib) referencing a handler chain file that ist not part of the JAR but resides in WEB-INF/classes. However this situation results in
> {code}
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"testjsr109.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"testjsr109.war\".PARSE: JBAS018733: Failed to process phase PARSE of deployment \"testjsr109.war\"
> Caused by: javax.xml.ws.WebServiceException: JBAS015507: Handler chain config file handlerchain.xml not found in ResourceRoot [root=\"/D:/tools/wildfly-8.2.0.Final/bin/content/testjsr109.war/WEB-INF/lib/testjsr109.jar\"]"}},
> "rolled-back" => true
> }
> {code}
> The implementation of org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor seems to expect, that the handler chain file is always part of the ResourceRoot the annotated WebService lives in. With respect to JSR 109 I think that this expectation is wrong and that a handler chain file outside the JAR is a valid scenario.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-3860) Improve dependency handling in clustering/infinispan subsystem tests
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3860?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3860:
-------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> Improve dependency handling in clustering/infinispan subsystem tests
> --------------------------------------------------------------------
>
> Key: WFLY-3860
> URL: https://issues.jboss.org/browse/WFLY-3860
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.0.0.Alpha3
>
>
> The subsystem tests in clustering/infinispan are not configured to use a controller operating in --admin-only mode, but they are also not doing all the needed setup to have needed services and resources (core, jmx, jgroups) available for when the services they add are started.
> This is fragile, because all sorts of stuff is failing when things are getting launched, but the tests are not noticing that. That's ok right now, but it could lead to missing regressions.
> Also, the changes I'm making for WFCORE-102 mean these problems will no longer go unnoticed and the tests will fail.
> I plan to:
> 1) Shifts tests to using --admin-only in cases where the tests are clearly not testing anything related to runtime execution; i.e. they are just testing model.
> 2) For OperationSequencesTestCase and OperationsTestCase, where there is some validation of runtime behavior going on (explicit in some places; in others perhaps expected, perhaps not) I'm going to switch the tests to a more focused config file that:
> a) Only uses local caches, to avoid pulling in requirements for jgroups things that are not present. (I see no indication any of the tests are testing anything not present with local caches.)
> b) Uses start="LAZY". This means services will get registered, but not started. Not starting avoids detection of various missing dependencies, including a ModuleLoader dependency that I can't figure out how to satisfy.
> The tests can't be trying to validate any behavior when services start, because they've never been able to start. So LAZY is fine. Some tests do seem to be looking for problem related to service conflicts as resources are added/removed. These tests are still valid, because service conflicts happen as soon as services are installed, whether or not the services need to start.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-3681) General Schema Sync with EAP
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3681?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3681:
-------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> General Schema Sync with EAP
> ----------------------------
>
> Key: WFLY-3681
> URL: https://issues.jboss.org/browse/WFLY-3681
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 10.0.0.Alpha3
>
>
> This may actually be more about pushing some changes to EAP, new schemas are being tracked by individual issues but for the remaining schemas where cosmetic changes have been made or corrections to default values and min/max occurs we need to sync with EAP.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-4304:
-------------------------------
Fix Version/s: 10.0.0.Alpha3
(was: 10.0.0.Alpha2)
> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
> Key: WFLY-4304
> URL: https://issues.jboss.org/browse/WFLY-4304
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Alpha3
>
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months