February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-796) LdapExtended login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-796?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-796: --------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1065486, https://bugzilla.redhat.com/show_bug.cgi?id=1067599 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1065486) > LdapExtended login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-796 > URL: https://issues.jboss.org/browse/SECURITY-796 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-796.patch > > > LdapExtended login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2913) Generic http management operation upload handler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2913?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2913: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1066476|https://bugzilla.redhat.com/show_bug.cgi?id=1066476] from ASSIGNED to POST > Generic http management operation upload handler > ------------------------------------------------ > > Key: WFLY-2913 > URL: https://issues.jboss.org/browse/WFLY-2913 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.1.Final > > > The current /management http API handler, does not support generic content uploads, where the add-content handler only allows addition to the content repository. Since operations might attach multiple streams to the operation we need a http handler which can deal with those requests. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2970) CLI doesn't return actual runtime configuration

by Debbie Steigner (JIRA)

[ https://issues.jboss.org/browse/WFLY-2970?page=com.atlassian.jira.plugin.... ] Debbie Steigner commented on WFLY-2970: --------------------------------------- Ok, the customer was using EAP 6.0.0 (AS 7.1.2) so if it's been fixed in 7.2, you can go ahead and close this. Thank you. > CLI doesn't return actual runtime configuration > ----------------------------------------------- > > Key: WFLY-2970 > URL: https://issues.jboss.org/browse/WFLY-2970 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Debbie Steigner > Assignee: Alexey Loubyansky > > If you start your server with -u commandline argument to bind your jgroups-udp to another IP (i.e. 230.0.0.13), the boot.log shows jboss.default.multicast.address = 230.0.0.13 > but if you read the resource via jboss-cli it shows just the default that is set in the standalone-ha.xml. Is there a way to get the actual value via jboss-cli? or is this a bug? > [standalone@127.0.0.1:9999 /] /socket-binding-group=standard-sockets/socket-binding=jgroups-udp:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => expression "${jboss.default.multicast.address:230.0.0.4}", > "multicast-port" => 45688, > "name" => "jgroups-udp", > "port" => 55200 > } > } -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-796) LdapExtended login module does not handle a user that has a slash character in the uid

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/SECURITY-796?page=com.atlassian.jira.plug... ] Derek Horton commented on SECURITY-796: --------------------------------------- Patch committed to trunk: https://svn.jboss.org/repos/picketbox/trunk > LdapExtended login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-796 > URL: https://issues.jboss.org/browse/SECURITY-796 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-796.patch > > > LdapExtended login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-796) LdapExtended login module does not handle a user that has a slash character in the uid

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/SECURITY-796?page=com.atlassian.jira.plug... ] Derek Horton resolved SECURITY-796. ----------------------------------- Resolution: Done > LdapExtended login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-796 > URL: https://issues.jboss.org/browse/SECURITY-796 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-796.patch > > > LdapExtended login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-762) Bug in JBossJSSESecurityDomain.java - attempting to use wrong provider

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-762?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-762: --------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1023084, https://bugzilla.redhat.com/show_bug.cgi?id=1067574 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1023084) > Bug in JBossJSSESecurityDomain.java - attempting to use wrong provider > ---------------------------------------------------------------------- > > Key: SECURITY-762 > URL: https://issues.jboss.org/browse/SECURITY-762 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Anil Saldhana > > There is a bug in JBossJSSESecurityDomain.java where it attempts to use the keystore/truststore provider to get instances of the trust manager. > The code reads: > if (trustManagerFactoryProvider != null) > trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustStoreProvider); > else > trustManagerFactory = TrustManagerFactory.getInstance(algorithm); > I think it should read: > if (trustManagerFactoryProvider != null) > trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustManagerFactoryProvider); > else > trustManagerFactory = TrustManagerFactory.getInstance(algorithm); -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-795) AdvancedLdap login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-795: -------------------------------------------------- Derek Horton <dehort(a)redhat.com> changed the Status of [bug 1065515|https://bugzilla.redhat.com/show_bug.cgi?id=1065515] from NEW to POST > AdvancedLdap login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-795 > URL: https://issues.jboss.org/browse/SECURITY-795 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Derek Horton > Fix For: Negotiation_2_2_7 > > Attachments: SECURITY-795.patch > > > AdvancedLdap login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2969) WildFly 8/Undertow 1 handles URL fragments differently than JBoss EAP 6.2/Apache-Coyote/1.1

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2969?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-2969: ------------------------------ Affects Version/s: 8.0.0.Final (was: 8.0.1.Final) > WildFly 8/Undertow 1 handles URL fragments differently than JBoss EAP 6.2/Apache-Coyote/1.1 > ------------------------------------------------------------------------------------------- > > Key: WFLY-2969 > URL: https://issues.jboss.org/browse/WFLY-2969 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Michal Babacek > Assignee: Stuart Douglas > Priority: Minor > > I have a bunch of URL tests, executed against EAP 6.2.0 directly and then proxied through mod_cluster 1.2.6. These all pass. > I tried to run the same with {{Wildfly-8.0.1.Final-SNAPSHOT, HEAD:be3a13e6}} with a surprising result of seeing some differences in how are various Request attributes reported from within the servlet: > Here we go,{{8080}} is where either EAP or WFLY listens: > || ||{{curl 'http://10.16.88.19:8080/clusterbench/requestinfo//?;?=44&test=OK;devil=3&...'}}|| > |EAP|Parameters map: {test=OK;devil=3, 777=666, ;?=44}| > |WFY|Parameters map: {=, 777=666, test=OK;devil=3, ;?=44}| > *Note:* {{Parameters map: \{key=value, key=value, ..., ...\}}}, so there is like an empty key and and empty value for WFLY.... > This is the [CommonRequestInfoServlet.java|https://github.com/Karm/clusterbench/blob/s...] that produced the output. > {code} > Map params = request.getParameterMap(); > Iterator i = params.keySet().iterator(); > while (i.hasNext()) { > String key = (String) i.next(); > String value = ((String[]) params.get(key))[0]; > responseText.append(key); > responseText.append("="); > responseText.append(value); > if (i.hasNext()) responseText.append(", "); > } > {code} > It is, indeed, possible that these mangled URLs are slipping through the cracks of [RFC|http://tools.ietf.org/html/rfc3986] and should be either "fixed" or URL encoded, yet I find the different interpretations disturbing. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2970) CLI doesn't return actual runtime configuration

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2970?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-2970: ----------------------------------- Can you verify this still happens in any newer version? AFAIR this was fixed around 7.2 times. > CLI doesn't return actual runtime configuration > ----------------------------------------------- > > Key: WFLY-2970 > URL: https://issues.jboss.org/browse/WFLY-2970 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Debbie Steigner > Assignee: Alexey Loubyansky > > If you start your server with -u commandline argument to bind your jgroups-udp to another IP (i.e. 230.0.0.13), the boot.log shows jboss.default.multicast.address = 230.0.0.13 > but if you read the resource via jboss-cli it shows just the default that is set in the standalone-ha.xml. Is there a way to get the actual value via jboss-cli? or is this a bug? > [standalone@127.0.0.1:9999 /] /socket-binding-group=standard-sockets/socket-binding=jgroups-udp:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => expression "${jboss.default.multicast.address:230.0.0.4}", > "multicast-port" => 45688, > "name" => "jgroups-udp", > "port" => 55200 > } > } -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-141) Deployment fails with empty classpath manifest

by Peter Hinds (JIRA)

[ https://issues.jboss.org/browse/AS7-141?page=com.atlassian.jira.plugin.sy... ] Peter Hinds commented on AS7-141: --------------------------------- Hi John, A quick query, I have found that auto-deploying (copy to \jboss-eap-6.2\standalone\deployments) an ear which contains a war with an empty class path in the war MANIFEST.MF still fails, whereas deploying through the Admin GUI (localhost:9990) deploys OK. My EAP version is 6.2.0 GA, which is built on AS 7.3 so this fix should be included. Being a newcomer to JBoss, is the autodeploy a completely separate component? If so, should I raise a new issue? For reference, when I auto-deploy the ear with the war containing an empty classpath, the server.log gives a fairly indescript error: [14:55:22] Peter Hinds (AMT-SYBEX): Deployment content C:\jboss-eap-6.2\standalone\deployments\meterflow-web-ear-JBOSS_PORT.1.1.ear appears to be incomplete and is not progressing toward completion. This content cannot be auto-deployed. It was only by chance I found that by removing the MANIFEST.MF empty classpath in the war, that I was able to auto-deploy the ear. > Deployment fails with empty classpath manifest > ---------------------------------------------- > > Key: AS7-141 > URL: https://issues.jboss.org/browse/AS7-141 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.0.0.Alpha1 > Reporter: Max Rydahl Andersen > Assignee: Stuart Douglas > Fix For: 7.0.0.Beta1 > > Attachments: jbossas7-deploy-example.war > > > If you war has a MANIFEST.MF with empty classpath you get an error even though empty Class-Path: is present (and afaik valid). > This is btw. how Eclipse defaults to create a war with no jar dependencies thus it would fail for a lot of folks ;) > 11:53:53,682 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "jbossas7-deploy-example.war" > 11:53:53,706 WARN [org.jboss.vfs] (MSC service thread 1-1) VFS was unable to set the URLStreamHandlerFactory. This will have unpredictable results > 11:53:53,731 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001:Failed to start service jboss.deployment.unit."jbossas7-deploy-example.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jbossas7-deploy-example.war".PARSE: Failed to process phase PARSE of deployment "jbossas7-deploy-example.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:109) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1367) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22] > at java.lang.Thread.run(Thread.java:680) [:1.6.0_22] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Class Path entry in "/content/jbossas7-deploy-example.war" not found. > at org.jboss.as.server.deployment.module.ManifestClassPathProcessor.deploy(ManifestClassPathProcessor.java:123) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:103) > ... 4 more > I'm attaching a simple war showing this. -- 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

12 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014