January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-207: ---------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1099730|https://bugzilla.redhat.com/show_bug.cgi?id=1099730] from CLOSED to NEW > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-207: ---------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1099730|https://bugzilla.redhat.com/show_bug.cgi?id=1099730] from NEW to CLOSED > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Sven V (JIRA)

[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ] Sven V commented on WFLY-4289: ------------------------------ Yes, that's exactly the behaviour I have experienced. > Authentication bug on one-way JAX-WS methods > -------------------------------------------- > > Key: WFLY-4289 > URL: https://issues.jboss.org/browse/WFLY-4289 > Project: WildFly > Issue Type: Bug > Components: Security, Web Services > Affects Versions: 8.2.0.Final > Reporter: Jakub Grabowski > Assignee: Darran Lofthouse > > 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. > 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. > 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. > 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. > It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Jakub Grabowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ] Jakub Grabowski edited comment on WFLY-4289 at 1/27/15 6:21 AM: ---------------------------------------------------------------- And the code that demonstrates issue: {code} @Stateless @WebService @DeclareRoles("user") @Local(IMessageSender.class) @WebContext(authMethod = "BASIC") public class MessageSender implements IMessageSender { @RolesAllowed("user") @Oneway public void fails(long l) { System.out.println(">>>>>: " + l); } @RolesAllowed("user") public void works(long l) { System.out.println(">>>>>: " + l); } } {code} was (Author: jakub_grabowski): And the code that demonstrates issue: @Stateless @WebService @DeclareRoles("user") @Local(IMessageSender.class) @WebContext(authMethod = "BASIC") public class MessageSender implements IMessageSender { @RolesAllowed("user") @Oneway public void fails(long l) { System.out.println(">>>>>: " + l); } @RolesAllowed("user") public void works(long l) { System.out.println(">>>>>: " + l); } } > Authentication bug on one-way JAX-WS methods > -------------------------------------------- > > Key: WFLY-4289 > URL: https://issues.jboss.org/browse/WFLY-4289 > Project: WildFly > Issue Type: Bug > Components: Security, Web Services > Affects Versions: 8.2.0.Final > Reporter: Jakub Grabowski > Assignee: Darran Lofthouse > > 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. > 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. > 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. > 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. > It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Jakub Grabowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ] Jakub Grabowski commented on WFLY-4289: --------------------------------------- And the code that demonstrates issue: @Stateless @WebService @DeclareRoles("user") @Local(IMessageSender.class) @WebContext(authMethod = "BASIC") public class MessageSender implements IMessageSender { @RolesAllowed("user") @Oneway public void fails(long l) { System.out.println(">>>>>: " + l); } @RolesAllowed("user") public void works(long l) { System.out.println(">>>>>: " + l); } } > Authentication bug on one-way JAX-WS methods > -------------------------------------------- > > Key: WFLY-4289 > URL: https://issues.jboss.org/browse/WFLY-4289 > Project: WildFly > Issue Type: Bug > Components: Security, Web Services > Affects Versions: 8.2.0.Final > Reporter: Jakub Grabowski > Assignee: Darran Lofthouse > > 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. > 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. > 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. > 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. > It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Jakub Grabowski (JIRA)

Jakub Grabowski created WFLY-4289: ------------------------------------- Summary: Authentication bug on one-way JAX-WS methods Key: WFLY-4289 URL: https://issues.jboss.org/browse/WFLY-4289 Project: WildFly Issue Type: Bug Components: Security, Web Services Affects Versions: 8.2.0.Final Reporter: Jakub Grabowski Assignee: Darran Lofthouse 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3769) Implement graceful shutdown for batch tasks

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3769?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-3769: ----------------------------------- Assignee: James Perkins (was: Jason Greene) > Implement graceful shutdown for batch tasks > ------------------------------------------- > > Key: WFLY-3769 > URL: https://issues.jboss.org/browse/WFLY-3769 > Project: WildFly > Issue Type: Sub-task > Components: Batch > Reporter: Stuart Douglas > Assignee: James Perkins > > This should make sure that all batch jobs have completed before the container shuts down, and not allow new jobs to start while the container is suspended. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-868: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1181084|https://bugzilla.redhat.com/show_bug.cgi?id=1181084] from NEW to ON_QA > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Beta3 > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1181086|https://bugzilla.redhat.com/show_bug.cgi?id=1181086] from MODIFIED to ON_QA > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1181086|https://bugzilla.redhat.com/show_bug.cgi?id=1181086] from NEW to MODIFIED > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 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 January 2015