September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2167) resolve-path operation definition is needs RUNTIME_ONLY and READ_ONLY set

by James Perkins (JIRA)

James Perkins created WFLY-2167: ----------------------------------- Summary: resolve-path operation definition is needs RUNTIME_ONLY and READ_ONLY set Key: WFLY-2167 URL: https://issues.jboss.org/browse/WFLY-2167 Project: WildFly Issue Type: Bug Components: Domain Management Reporter: James Perkins Assignee: James Perkins Priority: Minor Fix For: 8.0.0.CR1 Domain mode requires operations be defined as {{RUNTIME_ONLY}} to for describe handler to work. This is how the {{read-operation-names}} operation finds the available operations. While the operation can still be executed, it's not listed and in CLI doesn't allow any parameters to be passed with out this flag. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-143) JACC permissions added to the unchecked policy must be constructed using qualified pattern as their name

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/JBEE-143?page=com.atlassian.jira.plugin.s... ] Stefan Guilhen deleted JBEE-143: -------------------------------- > JACC permissions added to the unchecked policy must be constructed using qualified pattern as their name > --------------------------------------------------------------------------------------------------------- > > Key: JBEE-143 > URL: https://issues.jboss.org/browse/JBEE-143 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > > As reported by [~jcacek]: > JACC 1.1 specification, chapter 3.1.3.1 Translating security-constraint Elements says: > {panel} > A WebResourcePermission and a WebUserDataPermission must be added to > the unchecked policy statements for each url-pattern in the deployment > descriptor and the default pattern, "/", that is not combined by the web- > resource-collection elements of the deployment descriptor with every > HTTP method value. The permission objects must be constructed using the > *qualified pattern* as their name and with actions represented by an HTTP method > exception list that identifies (as defined in “HTTP Method Exception List”) all the > HTTP methods that do not occur in combination with the pattern.The resulting > permissions must be added to the unchecked policy statements by calling the > addToUncheckedPolicy method on the PolicyConfiguration object. > {panel} > but the class WarJaccService doesn't use qualified patterns (around line 170 in source code): > {code} > String excludedString = "!" + getCommaSeparatedString(httpMethods); > WebResourcePermission wrp1 = new WebResourcePermission(info.pattern, excludedString); > WebUserDataPermission wudp1 = new WebUserDataPermission(info.pattern, excludedString); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-144) JACC 1.1 implementation must use exception list instead of missing method list for HTTP methods in the unchecked permissions

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/JBEE-144?page=com.atlassian.jira.plugin.s... ] Stefan Guilhen deleted JBEE-144: -------------------------------- > JACC 1.1 implementation must use exception list instead of missing method list for HTTP methods in the unchecked permissions > ---------------------------------------------------------------------------------------------------------------------------- > > Key: JBEE-144 > URL: https://issues.jboss.org/browse/JBEE-144 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > > As reported by [~jcacek]: > The method {{org.jboss.as.web.security.WarJaccService.PatternInfo.getMissingMethods()}} which subtracts current methods set from the "big 7" is used for constructing some unchecked permissions. > The method exception list (i.e. exclamation mark followed by current methods) must be used instead - as defined in section 3.1.3.1 of JACC 1.1 specification. > The specification says: > {panel} > h4.HTTP Method Exception List > An HTTP method exception list is used to represent, by set difference, a non- > enumerable subset of the set of all possible HTTP methods. An exception list > respresents the subset of the complete set of HTTP methods formed by subtracting > the methods named in the exception list from the complete set. > An exception list is distinguished by its first character, which must be the > exclaimation point (i.e., “!”) character. A comma seperated list of one or more > HTTP method names must follow the exclaimation point. > {panel} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-144) JACC 1.1 implementation must use exception list instead of missing method list for HTTP methods in the unchecked permissions

by Stefan Guilhen (JIRA)

Stefan Guilhen created JBEE-144: ----------------------------------- Summary: JACC 1.1 implementation must use exception list instead of missing method list for HTTP methods in the unchecked permissions Key: JBEE-144 URL: https://issues.jboss.org/browse/JBEE-144 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jacc-api Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: JavaEE Spec APIs 3.0.3.Final As reported by [~jcacek]: The method {{org.jboss.as.web.security.WarJaccService.PatternInfo.getMissingMethods()}} which subtracts current methods set from the "big 7" is used for constructing some unchecked permissions. The method exception list (i.e. exclamation mark followed by current methods) must be used instead - as defined in section 3.1.3.1 of JACC 1.1 specification. The specification says: {panel} h4.HTTP Method Exception List An HTTP method exception list is used to represent, by set difference, a non- enumerable subset of the set of all possible HTTP methods. An exception list respresents the subset of the complete set of HTTP methods formed by subtracting the methods named in the exception list from the complete set. An exception list is distinguished by its first character, which must be the exclaimation point (i.e., “!”) character. A comma seperated list of one or more HTTP method names must follow the exclaimation point. {panel} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-143) JACC permissions added to the unchecked policy must be constructed using qualified pattern as their name

by Stefan Guilhen (JIRA)

Stefan Guilhen created JBEE-143: ----------------------------------- Summary: JACC permissions added to the unchecked policy must be constructed using qualified pattern as their name Key: JBEE-143 URL: https://issues.jboss.org/browse/JBEE-143 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jacc-api Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: JavaEE Spec APIs 3.0.3.Final As reported by [~jcacek]: JACC 1.1 specification, chapter 3.1.3.1 Translating security-constraint Elements says: {panel} A WebResourcePermission and a WebUserDataPermission must be added to the unchecked policy statements for each url-pattern in the deployment descriptor and the default pattern, "/", that is not combined by the web- resource-collection elements of the deployment descriptor with every HTTP method value. The permission objects must be constructed using the *qualified pattern* as their name and with actions represented by an HTTP method exception list that identifies (as defined in “HTTP Method Exception List”) all the HTTP methods that do not occur in combination with the pattern.The resulting permissions must be added to the unchecked policy statements by calling the addToUncheckedPolicy method on the PolicyConfiguration object. {panel} but the class WarJaccService doesn't use qualified patterns (around line 170 in source code): {code} String excludedString = "!" + getCommaSeparatedString(httpMethods); WebResourcePermission wrp1 = new WebResourcePermission(info.pattern, excludedString); WebUserDataPermission wudp1 = new WebUserDataPermission(info.pattern, excludedString); {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-142) JACC permissions with HTTP method exception list are not correctly implemented

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/JBEE-142?page=com.atlassian.jira.plugin.s... ] Stefan Guilhen updated JBEE-142: -------------------------------- Fix Version/s: JavaEE Spec APIs 3.0.3.Final > JACC permissions with HTTP method exception list are not correctly implemented > ------------------------------------------------------------------------------- > > Key: JBEE-142 > URL: https://issues.jboss.org/browse/JBEE-142 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jacc-api > Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: JavaEE Spec APIs 3.0.3.Final > > > As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification. > There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling > {code} > Object[] methodInfo = WebResourcePermission.canonicalMethods(actions); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-142) JACC permissions with HTTP method exception list are not correctly implemented

by Stefan Guilhen (JIRA)

Stefan Guilhen created JBEE-142: ----------------------------------- Summary: JACC permissions with HTTP method exception list are not correctly implemented Key: JBEE-142 URL: https://issues.jboss.org/browse/JBEE-142 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jacc-api Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final Reporter: Stefan Guilhen Assignee: Stefan Guilhen As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification. There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling {code} Object[] methodInfo = WebResourcePermission.canonicalMethods(actions); {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1916) Deployer role within domain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1916: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012592 > Deployer role within domain > --------------------------- > > Key: WFLY-1916 > URL: https://issues.jboss.org/browse/WFLY-1916 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > Fix For: 8.0.0.Beta1 > > > There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to: > a) /server-group=* > b) /deployment=* > But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1916) Deployer role within domain

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.... ] Heiko Braun updated WFLY-1916: ------------------------------ Comment: was deleted (was: Is this still an issue?) > Deployer role within domain > --------------------------- > > Key: WFLY-1916 > URL: https://issues.jboss.org/browse/WFLY-1916 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > Fix For: 8.0.0.Beta1 > > > There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to: > a) /server-group=* > b) /deployment=* > But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1592) Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1592?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-1592: ---------------------------------------- [~rob.stryker] Is this still an issue for you? I thought this was new but looking at the history it is a few months old and your linked Jira has been closed. > Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1592 > URL: https://issues.jboss.org/browse/WFLY-1592 > Project: WildFly > Issue Type: Bug > Components: Remoting, Security > Affects Versions: 8.0.0.Alpha2 > Reporter: Rob Stryker > Assignee: Darran Lofthouse > Fix For: 8.0.0.Beta1 > > > Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with credentials. This is most easily replicated as follows: > 1) On remote machine start wildfly alpha1 or alpha2 > 2) on local machine, cd eap-6.1/bin > 3) on local machine: > [rob@rawbdor bin]$ ./jboss-cli.sh > You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. > [disconnected /] connect myhost.net > Authenticating against security realm: ManagementRealm > Username: admin > Password: > Unable to authenticate against controller at myhost.net:9999: Authentication failed: all available authentication mechanisms failed > This is an issue for tools as we need a set of jars that communicates correctly with all as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x, which is good. If this is merely a bug on the server, then we can hopefully delay having to bundle an additional set of client jars until larger breakages occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 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 September 2013