May 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-278) Revisit error message for an authentication failure.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-278?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-278: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > 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: 2.0.0.Alpha4 > > > 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.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-263: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > Fix For: 2.0.0.Alpha4 > > Attachments: unundeployable.zip > > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-383) Update the DC's IgnoredTransformationRegistry when changes are made to a slave's <ignored-resources>

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-383?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-383: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > Update the DC's IgnoredTransformationRegistry when changes are made to a slave's <ignored-resources> > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-383 > URL: https://issues.jboss.org/browse/WFCORE-383 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 2.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-372) Cache role mapping results for the span of the overall operation

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-372?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-372: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > Cache role mapping results for the span of the overall operation > ---------------------------------------------------------------- > > Key: WFCORE-372 > URL: https://issues.jboss.org/browse/WFCORE-372 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > Labels: access_control, management_security, > Fix For: 2.0.0.Alpha4 > > > Look into caching role mapping results for the duration of an overall operation. This would be an impl detail of the RoleMapper. With our standard mappers, the mapping results should not be changing in the middle of an operation, so I believe they should be cacheable. > Likely place to cache them is as an attachment in a context object that will be passed in to the Authorizer. It would have to be passed in to the RoleMapper as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-364) Hangs in mixed domain testsuite

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-364?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-364: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > Hangs in mixed domain testsuite > ------------------------------- > > Key: WFCORE-364 > URL: https://issues.jboss.org/browse/WFCORE-364 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.Alpha4 > > Attachments: testsuite-hang1-server.txt, testsuite-hang2-client.txt, testsuite-hang2-server.txt > > > http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-param-pull... > https://dl.dropboxusercontent.com/u/712508/mixed-hang-debug.zip contains details. > 30805.dump is the client and shows the problem is occurring in the @After cleanup of MixedDomainDeploymentTest as it removes deployments from the domain. > "main" prio=10 tid=0xf7605c00 nid=0x7856 in Object.wait() [0xf776e000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl) > at java.lang.Object.wait(Object.java:503) > at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192) > - locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl) > at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266) > - locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl) > at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:81) > at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.removeDeployment(MixedDomainDeploymentTest.java:441) > at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.cleanDeployments(MixedDomainDeploymentTest.java:343) > at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.confirmNoDeployments(MixedDomainDeploymentTest.java:163) > 31894.dump shows the master HC. management-handler-thread is blocking on the way out (after sending the commit or rollback) waiting for a final result response from the slave. > "management-handler-thread - 1" prio=10 tid=0xca0efc00 nid=0x7cdd in Object.wait() [0xc7469000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl) > at java.lang.Object.wait(Object.java:503) > at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192) > - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl) > at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266) > - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl) > at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100) > at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.finalizeOp(DomainSlaveHandler.java:215) > at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.access$000(DomainSlaveHandler.java:58) > at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler$1.handleResult(DomainSlaveHandler.java:179) > at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:805) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:763) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:738) > (Note that the "handleRollback" method name is a red-herring -- the method should be renamed to a "handleResult" as it now is called no matter what the result.) > 31986.dump is the slave HC. It shows it is blocking in stage DONE after having sent operationPrepared to the master, waiting for commit or rollback. > "domain-connection-threads - 1" prio=10 tid=0xc91a8400 nid=0x7d1a waiting on condition [0xc87fe000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xea1fd410> (a java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) > at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ProxyOperationControlProxy.operationPrepared(TransactionalProtocolOperationHandler.java:173) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:337) > at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) > at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:128) > Indication is the commit or rollback message is getting lost. There are no threads shown sending or receiving it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-304) Enable user agent and address filters.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-304?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-304: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > Enable user agent and address filters. > -------------------------------------- > > Key: WFCORE-304 > URL: https://issues.jboss.org/browse/WFCORE-304 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-301: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > Configuration of individual contexts for http management interface. > ------------------------------------------------------------------- > > Key: WFCORE-301 > URL: https://issues.jboss.org/browse/WFCORE-301 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha4 > > > At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console. > The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context. > We need to start to open up the handling of cross origin requests for a couple of reasons: - > - Enabling Keycloak SSO support. > - Alternative console distribution options > The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default. > A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-598) Make it possible to register a child at a certain position

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-598?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-598: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > Make it possible to register a child at a certain position > ---------------------------------------------------------- > > Key: WFCORE-598 > URL: https://issues.jboss.org/browse/WFCORE-598 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 2.0.0.Alpha4 > > > The BasicResource stores child resources in a LinkedHashMap so it is ordered in the order of the adds. It should be possible to insert a new child somewhere in the middle, rather than just at the end. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-597) Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-597?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-597: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations. > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-597 > URL: https://issues.jboss.org/browse/WFCORE-597 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 2.0.0.Alpha4 > > > If an ObjectTypeAttributeDefinition contains an attribute definition that has ResourceOnly set then it should be filtered from the automatically generated description for the add operation. > This may be more related to lists, I currently have: - > ObjectListAttributeDefinition, which contains ObjectTypeAttributeDefinition, which contains SimpleAttributeDefinition > It is this final SimpleAttributeDefinition that has ResourceOnly set but it is still showing up in the operation description for add. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-496) add-user.sh - if password contains § it is not possible to log into the webinterface

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-496?page=com.atlassian.jira.plugin... ] Jason Greene updated WFCORE-496: -------------------------------- Fix Version/s: 2.0.0.Alpha4 (was: 2.0.0.Alpha3) > add-user.sh - if password contains § it is not possible to log into the webinterface > ------------------------------------------------------------------------------------ > > Key: WFCORE-496 > URL: https://issues.jboss.org/browse/WFCORE-496 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Environment: wheezy, Firefox 34.0.5, Chrome 36.0.1985.125 > Reporter: do ev > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2015