[JBoss JIRA] (WFCORE-278) Revisit error message for an authentication failure.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-278?page=com.atlassian.jira.plugin... ]
Darran Lofthouse moved WFLY-3208 to WFCORE-278:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-278 (was: WFLY-3208)
Issue Type: Bug (was: Task)
Affects Version/s: (was: 8.0.0.Final)
Component/s: CLI
Domain Management
Remoting
Security
(was: CLI)
(was: Domain Management)
(was: Remoting)
(was: Security)
Fix Version/s: 1.0.0.Alpha14
(was: 9.0.0.Beta1)
> Revisit error message for an authentication failure.
> ----------------------------------------------------
>
> Key: WFCORE-278
> URL: https://issues.jboss.org/browse/WFCORE-278
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management, Remoting, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha14
>
>
> After authentication fails in the CLI the following error message is output: -
> {code}
> Unable to authenticate against controller at localhost:9990: Authentication failed: the server presented no authentication mechanisms
> {code}
> This text is a bit misleading, what it actually means is all mechanisms presented have either been excluded or attempted and now no further mechanisms are available to try.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFCORE-276) whoami operation failed when rbac enabled but no roles assigned
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-276?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-276:
------------------------------------
Description:
Need to double check this is either the CLI making a call in addition to the whoami op and that call is failing or something being accessed by whoami is causing the failure.
Here is the failure for a user with no roles: -
{noformat}
[standalone@localhost:9990 /] [darranl@localhost bin]$ ./jboss-cli.sh -c --no-local-auth
Authenticating against security realm: ManagementRealm
Username: UserTwo
Password:
[standalone@localhost:9990 /] :whoami
{
"outcome" => "success",
"result" => {"identity" => {
"username" => "UserTwo",
"realm" => "ManagementRealm"
}}
}
[standalone@localhost:9990 /] :whoami(verbose=true)
Failed to get the list of the operation properties: "WFLYCTL0313: Unauthorized to execute operation 'read-operation-description' for resource '[]' -- "WFLYCTL0332: Permission denied""
[standalone@localhost:9990 /]
{noformat}
was:Need to double check this is either the CLI making a call in addition to the whoami op and that call is failing or something being accessed by whoami is causing the failure.
> whoami operation failed when rbac enabled but no roles assigned
> ---------------------------------------------------------------
>
> Key: WFCORE-276
> URL: https://issues.jboss.org/browse/WFCORE-276
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha14
>
>
> Need to double check this is either the CLI making a call in addition to the whoami op and that call is failing or something being accessed by whoami is causing the failure.
> Here is the failure for a user with no roles: -
> {noformat}
> [standalone@localhost:9990 /] [darranl@localhost bin]$ ./jboss-cli.sh -c --no-local-auth
> Authenticating against security realm: ManagementRealm
> Username: UserTwo
> Password:
> [standalone@localhost:9990 /] :whoami
> {
> "outcome" => "success",
> "result" => {"identity" => {
> "username" => "UserTwo",
> "realm" => "ManagementRealm"
> }}
> }
> [standalone@localhost:9990 /] :whoami(verbose=true)
> Failed to get the list of the operation properties: "WFLYCTL0313: Unauthorized to execute operation 'read-operation-description' for resource '[]' -- "WFLYCTL0332: Permission denied""
> [standalone@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-4116) WAR deployment fails on missing security domain dependency
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4116?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-4116.
------------------------------------
Resolution: Rejected
> WAR deployment fails on missing security domain dependency
> ----------------------------------------------------------
>
> Key: WFLY-4116
> URL: https://issues.jboss.org/browse/WFLY-4116
> Project: WildFly
> Issue Type: Feature Request
> Components: Security, Web (JBoss Web), Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Standalone form-based authentication WAR
> Reporter: Lars Hellgren
> Assignee: Darran Lofthouse
> Fix For: 8.2.0.Final
>
>
> Moving WARs using form based authentication from WildFly 8.1 Final to 8.2 Final fails due to a missing security domain dependency.
> *Log*
> {noformat}
> service jboss.security.security-domain.java:/jaas/haa-portal (missing) dependents:
> [service jboss.deployment.unit."haa-security-manager.war".component.SecurityManagerRepositorySessionBean.CREATE,
> service jboss.deployment.unit."haa-security-manager.war".component.UserPrefsRepository.CREATE]
> {noformat}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>java:/jaas/haa-portal</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="haa-portal">
> <authentication>
> <login-module code="Database" flag="required">
> ...
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> {code}
> The datasource is deployed and connected.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-4116) WAR deployment fails on missing security domain dependency
by Lars Hellgren (JIRA)
[ https://issues.jboss.org/browse/WFLY-4116?page=com.atlassian.jira.plugin.... ]
Lars Hellgren commented on WFLY-4116:
-------------------------------------
Jaikiran,
Thank you.
Lars
On Fri, Nov 21, 2014 at 9:23 PM, jaikiran pai (JIRA) <issues(a)jboss.org>
> WAR deployment fails on missing security domain dependency
> ----------------------------------------------------------
>
> Key: WFLY-4116
> URL: https://issues.jboss.org/browse/WFLY-4116
> Project: WildFly
> Issue Type: Feature Request
> Components: Security, Web (JBoss Web), Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Standalone form-based authentication WAR
> Reporter: Lars Hellgren
> Assignee: Darran Lofthouse
> Fix For: 8.2.0.Final
>
>
> Moving WARs using form based authentication from WildFly 8.1 Final to 8.2 Final fails due to a missing security domain dependency.
> *Log*
> {noformat}
> service jboss.security.security-domain.java:/jaas/haa-portal (missing) dependents:
> [service jboss.deployment.unit."haa-security-manager.war".component.SecurityManagerRepositorySessionBean.CREATE,
> service jboss.deployment.unit."haa-security-manager.war".component.UserPrefsRepository.CREATE]
> {noformat}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>java:/jaas/haa-portal</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="haa-portal">
> <authentication>
> <login-module code="Database" flag="required">
> ...
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> {code}
> The datasource is deployed and connected.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (JBMETA-381) DefaultPropertyReplacer can't handle ${:} expression
by Brian Stansberry (JIRA)
Brian Stansberry created JBMETA-381:
---------------------------------------
Summary: DefaultPropertyReplacer can't handle ${:} expression
Key: JBMETA-381
URL: https://issues.jboss.org/browse/JBMETA-381
Project: JBoss Metadata
Issue Type: Bug
Components: common
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
If the string "${:}" is passed to default property replacer, it does not parse it as indicating File.pathSeparator; rather it treats it as the default delimiter.
${:} resolves to an empty string.
a${:} resolves to a
${:}a resolves to a
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-1192) jboss-deployment-structure.xml top level exclusion does not work
by sathiya seelan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1192?page=com.atlassian.jira.plugin.... ]
sathiya seelan commented on WFLY-1192:
--------------------------------------
Thanks for your response [~jaikiran]
I've followed the "HackinonWildfly" guide and set up locally.But having some issues, like "Testcases are failed".
So after fixing those issues, will drop a mail and start working on this issue.
> jboss-deployment-structure.xml top level exclusion does not work
> ----------------------------------------------------------------
>
> Key: WFLY-1192
> URL: https://issues.jboss.org/browse/WFLY-1192
> Project: WildFly
> Issue Type: Feature Request
> Components: Class Loading
> Environment: Windows, RedHat Linux
> Reporter: Markus Lindblom
> Fix For: Awaiting Volunteers
>
>
> When I try to exclude for example Log4J in the deployment structure I have to exclude it from every subdeployment in the deployment structure file, the top level exclusion should exclude it from the entire EAR and all of its subdeployments.
> Ed: The feature request is, to add a convenient way to cause exclusions to cascade to subdeployments. Right now it works per design.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1898:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from NEW to POST
> FD_HOST many false suspect with Full GC
> ---------------------------------------
>
> Key: JGRP-1898
> URL: https://issues.jboss.org/browse/JGRP-1898
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.5.1
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Fix For: 3.4.7, 3.5.2, 3.6.1
>
> Attachments: test-fdhost.zip
>
>
> Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop.
> {code}
> for (h: hosts) { ping_and_update_timestamp(host) }
> current = System.currentTimeMillis();
> for (h: hosts) { compare current and (ping_timestmp + timeout) }
> {code}
> Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects.
> For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation.
> To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-4120) JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
by Manfred Otte (JIRA)
[ https://issues.jboss.org/browse/WFLY-4120?page=com.atlassian.jira.plugin.... ]
Manfred Otte updated WFLY-4120:
-------------------------------
Attachment: testjsr109.war
Reproduction should be possible with the attached WAR. It contains a very simple Webservice de.testjsr109.ServiceWithHandlerChain and an even simpler handler both packaged within a JAR.
The Webservice is annotated with a relative file-location: @HandlerChain(file = "../../handlerchain.xml"). The handler chain file resides in WEB-INF/classes. Deployment results in above mentioned error.
Moving the handler chain file from WEB-INF/classes to the root of the JAR results in a successful deployment and the endpoint is usable.
> 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
> 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.8#6338)
11 years, 8 months
[JBoss JIRA] (WFLY-4120) JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
by Manfred Otte (JIRA)
Manfred Otte created WFLY-4120:
----------------------------------
Summary: 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
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.8#6338)
11 years, 8 months