July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-396: ----------------------------------------- [~luck3y] I'm pretty sure I named it that deliberately. Granted the name is questionable since "domain" can imply the entire domain not just a host, but I don't think I did ti by mistake. I basically came up with two op names, one for a single process request (resolve-expression) and this one for requests that will get rolled out to multiple domain processes. > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta1 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6785) Modify web/DeploymentScannerTestCase.java to reflect WFCORE-1579

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6785?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-6785: ---------------------------------------- This test class needs to be moved to core. > Modify web/DeploymentScannerTestCase.java to reflect WFCORE-1579 > ---------------------------------------------------------------- > > Key: WFLY-6785 > URL: https://issues.jboss.org/browse/WFLY-6785 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > DeploymentScannerTestCase should be modified to reflect changes in WFCORE-1579 - specifically a deployment scanner can be created with inaccessible deployment directory configured. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1671) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1671?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1671: ------------------------------------------ [~gaol] I think it should be ok. The one concern I have is there is some ServiceLoader stuff that looks like leftover cruft in full's security module. I don't believe it's needed, but I'm concerned that if we bring this module dependency back it may end up interfering somehow. So I've sent up a PR to remove it and will see if that breaks CI in some way: https://github.com/wildfly/wildfly/pull/9067 If it's ok then I'll merge it and that change should be part of any backport of this to EAP. > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security > ---------------------------------------------------------------------------------------- > > Key: WFCORE-1671 > URL: https://issues.jboss.org/browse/WFCORE-1671 > Project: WildFly Core > Issue Type: Bug > Components: Security, Server > Reporter: Derek Horton > Assignee: Lin Gao > > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following: > <security-realm name="ManagementRealm"> > <authentication> > <jaas name="jmx-console"/> > </authentication> > <authorization map-groups-to-roles="false"> > <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> > </authorization> > </security-realm> > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="RealmUsersRoles" flag="required"> > <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > </login-module> > </authentication> > </security-domain> > The following error is logged during the authentication attempt: > 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))] > at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794) > at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) > at javax.security.auth.login.LoginContext.login(LoginContext.java:587) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347) > at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174) > at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141) > at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161) > at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-604) SecurityProviderSaslClientFactory and ServiceLoaderSaslClientFactory lose mech order

by David Lloyd (JIRA)

David Lloyd created ELY-604: ------------------------------- Summary: SecurityProviderSaslClientFactory and ServiceLoaderSaslClientFactory lose mech order Key: ELY-604 URL: https://issues.jboss.org/browse/ELY-604 Project: WildFly Elytron Issue Type: Bug Components: SASL Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta7 Preserve order the way the JDK does: query the factories one by one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6853) Picketlink does not return SessionIndex in LogoutRequest

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6853?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6853: ----------------------------------------------- Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1353338|https://bugzilla.redhat.com/show_bug.cgi?id=1353338] from POST to MODIFIED > Picketlink does not return SessionIndex in LogoutRequest > -------------------------------------------------------- > > Key: WFLY-6853 > URL: https://issues.jboss.org/browse/WFLY-6853 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Vlado Pakan > Assignee: Vlado Pakan > > When logged out from application SAML logout message does not contain SessionIndex tag. > See referenced bugzilla for more information -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-603) AuthenticationConfiguration loosing mechanism ordering by using a HashSet instead of a LinkedHashSet

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-603?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-603: --------------------------------- If this is in reference to the authentication mechanisms - yes, it was meant as a filter, not a list of names. > AuthenticationConfiguration loosing mechanism ordering by using a HashSet instead of a LinkedHashSet > ---------------------------------------------------------------------------------------------------- > > Key: ELY-603 > URL: https://issues.jboss.org/browse/ELY-603 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta7 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-603) AuthenticationConfiguration loosing mechanism ordering by using a HashSet instead of a LinkedHashSet

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-603: ------------------------------------ Summary: AuthenticationConfiguration loosing mechanism ordering by using a HashSet instead of a LinkedHashSet Key: ELY-603 URL: https://issues.jboss.org/browse/ELY-603 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta7 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2062: --------------------------- Steps to Reproduce: {code:java} channel.send(new org.jgroups.Message(null, "\u1F601")); {code} Expected: Ironically, Jira fails on expected output. See http://apps.timwhitlock.info/emoji/tables/unicode Actual: garbage data was: {{ channel.send(new org.jgroups.Message(null, "\u1F601")); }} Expected: Ironically, Jira fails on expected output. See http://apps.timwhitlock.info/emoji/tables/unicode Actual: garbage data > TYPE_STRING does not handle unicode > ----------------------------------- > > Key: JGRP-2062 > URL: https://issues.jboss.org/browse/JGRP-2062 > Project: JGroups > Issue Type: Bug > Reporter: Cody Ebberson > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character. > For example, see objectToByteBuffer lines 561-567: > https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... > {code:java} > case TYPE_STRING: > String str=(String)obj; > int len=str.length(); > ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING); > for(int i=0; i < len; i++) > retval.put((byte)str.charAt(i)); > return retval.array(); > {code} > This code will incorrectly encode any String with non ASCII encoding. > There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2062: --------------------------- Description: In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character. For example, see objectToByteBuffer lines 561-567: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... {code:java} case TYPE_STRING: String str=(String)obj; int len=str.length(); ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING); for(int i=0; i < len; i++) retval.put((byte)str.charAt(i)); return retval.array(); {code} This code will incorrectly encode any String with non ASCII encoding. There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path. was: In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character. For example, see objectToByteBuffer lines 561-567: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... {{case TYPE_STRING: String str=(String)obj; int len=str.length(); ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING); for(int i=0; i < len; i++) retval.put((byte)str.charAt(i)); return retval.array();}} This code will incorrectly encode any String with non ASCII encoding. There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path. > TYPE_STRING does not handle unicode > ----------------------------------- > > Key: JGRP-2062 > URL: https://issues.jboss.org/browse/JGRP-2062 > Project: JGroups > Issue Type: Bug > Reporter: Cody Ebberson > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character. > For example, see objectToByteBuffer lines 561-567: > https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... > {code:java} > case TYPE_STRING: > String str=(String)obj; > int len=str.length(); > ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING); > for(int i=0; i < len; i++) > retval.put((byte)str.charAt(i)); > return retval.array(); > {code} > This code will incorrectly encode any String with non ASCII encoding. > There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-602) Add support for SASL mechanism ordering by name.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-602?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-602: --------------------------------- Description: We previously relied on ordering of the factories although this does not work well once multiple modules are in use, add SortedMechanismSasl*Factory implementations that can take a Comparator to sort the names from a delegate. (was: Ideally we would actually have policy to sort mechanisms however for the moment we can at the very least get our factories into a desired order.) > Add support for SASL mechanism ordering by name. > ------------------------------------------------ > > Key: ELY-602 > URL: https://issues.jboss.org/browse/ELY-602 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta7 > > > We previously relied on ordering of the factories although this does not work well once multiple modules are in use, add SortedMechanismSasl*Factory implementations that can take a Comparator to sort the names from a delegate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016