June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (SECURITY-572) Support for situation when first OID is Kerberos OID instead of SPNEGO OID

by Marek Posolda (JIRA)

Support for situation when first OID is Kerberos OID instead of SPNEGO OID -------------------------------------------------------------------------- Key: SECURITY-572 URL: https://issues.jboss.org/browse/SECURITY-572 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Negotiation Affects Versions: Negotiation_2.0.3.GA Environment: JBoss EPP 5.1.GA with SPNEGO support, JBoss Negotiation 2.0.3, commons-http-client 3.1 used as HTTP client Reporter: Marek Posolda Assignee: Darran Lofthouse Fix For: Negotiation_2.0.4 Currently first byte of SPNEGO token is used to recognize if it's new token NegTokenInit and another 3 bytes are used to recognized length. From byte 5 is starting sequence for recognizing OID. Currently NegotiationAuthenticator is able to handle situations where this OID is SPNEGO OID (1.3.6.1.5.5.2) but it's not able to correctly handle situations where first OID is Kerberos OID (1.2.840.113554.1.2.2). Problem is that if Kerberos is used, then the rest of sequence format is different then for SPNEGO and IOException is thrown in method NegTokenInitDecoder.decodeNegTokenInitSequence because the sequence type is not expected value (any of 0xa0, 0xa1, 0xa2, 0xa3). I think that support for Kerberos OID is not critical and I am not sure if it's really the issue, but guys here https://issues.apache.org/jira/browse/HTTPCLIENT-523 are saying that it's working correctly with IIS but not with JBoss Negotiation. For simulating of situation can be used commons-httpclient3 with integration of NegotiateScheme: http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/trunk/src/contrib... Or you can simulate it by sending this Negotiate token in HTTP header: Authorization : Negotiate YIID7QYJKoZIhvcSAQICAQBuggPcMIID2KADAgEFoQMCAQ6iBwMFAAAAAACjggEEYYIBADCB/aADAgEFoQ8bDUxPQ0FMLk5FVFdPUkuiJzAloAMCAQChHjAcGwRIVFRQGxRzZXJ2ZXIubG9jYWwubmV0d29ya6OBuzCBuKADAgEDoQMCAQOigasEgajWrIRyQlCHtxXO//EMI/6C9zBChS00QtgZLctUa0qjb14RZFFj5pyruAB7SrqnxuD7JROJpwsVZG7FDpFu47Y3ZXyWjq8C1px+V4CULGgOt3Aufyh8DVRGeuhxYQ17APR5pC418Wo/u/VIJvLco7VZaAlGEF0xyJ8thtBM8Oz88urPpVxOl+7mUd2XirkqReL5ITdsEOjnZ4Q8duYKDPq9GdVcvf7MFyikggK5MIICtaADAgEBooICrASCAqjngVyeX24XzPtoMsnO0W2DoiX+SfpshcbZOVN0ne98Zxhnq3gxxiHiiI3voWTqtAiXe9E/Ti+wPuFI1g4jXsOjY8V4GGfDxihxGSMa9vu45JvLr+MPL40EwmFaD6fRpU+DA80ZhS+1THhTKT2w28pJS45fgSM2igmXQYk0hfv/Q7xIYBmNJXMZ2ZgyY8dek5dflg9zjuZetR6RSYJtu7Q+c/w3t/yHYLtcrz98aD+Q4EjBtf4I3EpP+c5NSkpouSvRy8u4yPNgOyvM8CdXuABveVdl+/DX100ucJc9uXAL+lPMdk+YMo8rAoEWae3km5LDfd3JncPB50OKwjNzejvi5e+5OYG17TpTx88sGMl0JLQ5mgrUBMPMG/c2sje4mhmTa8nO8SdqP6Fa1HVYPZNgDskSvTQzM0zsLRU0tyuge41hB8J6AOje1rGvpLBKMdMbXqnD08aC0N1qL1b5TmNk2jcWyJaGAi1pxzyNDwFTL5LUr7e+bIHrX2nd3g328pdDfZCBiqvrInXR+7phnKYinit22O4ktQQRuS9bybZR+ECAVrnCXspPieIvPLZYrzEDgp3NXYlUUzyWuNBN/obXAHiXhE0LMtnDvSs/MQYHTjGAahoKVjxNWDSmRylGD49dAI/N+cNnB/1NruSTLd5voahGYrnDmoouWafa4oaARZqq48lSAgaMhfPoMfYaBSWS9mWYltBEsTUAQO3sNg0Sx0d0jtQzQG/37mxKCF5F/rAeeI5NQcRrXV1RZzkY7UPyaiIwelt/ZOo2tJqgkSIKQwPBlH/GGlRvrCse3f2Eg/FoSKUMTHkjl433BiG4J9+5Isgchgl6XfolW4d7b5Ztqg0zi+k0ydTzpeK1h9mYbJ1ML2rdlHTXNEnF0fmwz+4SGk09bG/Rqw== Another thing is handling of IOException, which is not logged anywhere, but I will create another JIRA issue for it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
5
0 / 0

[JBoss JIRA] (AS7-4253) TCCL used by EJBNamingContext is wrong when callstack passes through multiple OSGi modules

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-4253: ----------------------------------- Summary: TCCL used by EJBNamingContext is wrong when callstack passes through multiple OSGi modules Key: AS7-4253 URL: https://issues.jboss.org/browse/AS7-4253 Project: Application Server 7 Issue Type: Bug Components: EJB, OSGi Reporter: Thomas Diesler Assignee: jaikiran pai Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
22
0 / 0

[JBoss JIRA] (JBRULES-3546) Planner: Late acceptance and great deluge get stuck in an endless move iterator loop because there are no acceptable moves

by Geoffrey De Smet (JIRA)

13 years, 9 months

1
4
0 / 0

[JBoss JIRA] (AS7-3491) Hornetq address settings reference non-existing DLQ

by Robert Reimann (JIRA)

Robert Reimann created AS7-3491: ----------------------------------- Summary: Hornetq address settings reference non-existing DLQ Key: AS7-3491 URL: https://issues.jboss.org/browse/AS7-3491 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.1.0.CR1b Reporter: Robert Reimann Assignee: Andy Taylor The hornetq address-settings inside standalone-full.xml and domain.xml reference a non-existing dead-letter-address "jms.queue.DLQ". See forum reference for details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

5
11
0 / 0

[JBoss JIRA] (AS7-2142) CLI: missing :remove-attribute command

by Rostislav Svoboda (Created) (JIRA)

CLI: missing :remove-attribute command -------------------------------------- Key: AS7-2142 URL: https://issues.jboss.org/browse/AS7-2142 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.1.0.Alpha1 Reporter: Rostislav Svoboda Assignee: Alexey Loubyansky Fix For: 7.1.0.CR1 We have _:read-attribute_ and _:write-attribute_ commands but we do not have *:remove-attribute* command. It would be invoked on attributes which have flag required set to false. For example when I define socket-binding-port-offset for server-group I can't remove it and I can't set it to 0 using CLI. {code} /server-group=main-server-group:read-resource-description() "socket-binding-port-offset" => { "description" => "The default offset to be added to the port values given by the socket binding group.", "type" => INT, "required" => false, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

13
19
0 / 0

[JBoss JIRA] Created: (AS7-1271) Fired object messages violate classloaders

by John Ament (JIRA)

Fired object messages violate classloaders ------------------------------------------ Key: AS7-1271 URL: https://issues.jboss.org/browse/AS7-1271 Project: Application Server 7 Issue Type: Bug Reporter: John Ament JMS allows you to fire an object message. In this case, I have a object of type in my deployment. It fires fine. I bind a message consumer to a queue in AS7. the object message coming in results in a classloader violation: 22:13:35,116 ERROR [org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2 (group:HornetQ-client-global-threads-767046602)) org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException: org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101) at java.lang.Class.forName0(Native Method) [:1.6.0_22] at java.lang.Class.forName(Class.java:247) [:1.6.0_22] at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22] at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69) [hornetq-core-2.2.6.Final.jar:] at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22] at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_22] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22] at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158) [hornetq-jms-2.2.6.Final.jar:] at org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46) at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [hornetq-jms-2.2.6.Final.jar:] at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866) [hornetq-core-2.2.6.Final.jar:] at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44) [hornetq-core-2.2.6.Final.jar:] at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983) [hornetq-core-2.2.6.Final.jar:] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.6.Final.jar:] 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:662) [:1.6.0_22] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

13
29
0 / 0

[JBoss JIRA] Created: (JBAS-8734) API change in deployment scanner's add cause failed deployments

by Rob Stryker (JIRA)

API change in deployment scanner's add cause failed deployments --------------------------------------------------------------- Key: JBAS-8734 URL: https://issues.jboss.org/browse/JBAS-8734 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers Affects Versions: 6.0.0.CR1 Reporter: Rob Stryker Assignee: Ales Justin Priority: Critical When using the deployment scanner mbean to pass in a new URL that the JBossAS should scan for deployments, a path format which worked fine in JBoss 5 and below no longer works. Specifically, passing in a URL such as the one below: file:/home/rob/apps/eclipse/workspaces/main_code/runtime%20space%20workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1292215199516/deploy/Dyn888.war/ When passing this string into the addURL mbean, the following error in the jboss console results: 14:52:54,927 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/Dyn888 14:52:54,930 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=jboss.web.deployment:war=/Dyn888 state=Create mode=Manual requiredState=Installed: java.net.URISyntaxException: Illegal character in path at index 56: file:/home/rob/apps/eclipse/workspaces/main_code/runtime space workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1292215199516/deploy/Dyn888.war/ at java.net.URI$Parser.fail(URI.java:2809) [:1.6.0_14] at java.net.URI$Parser.checkChars(URI.java:2982) [:1.6.0_14] Despite that I pass in a string with clear %20 blocking out the spaces, the deployment scanner does not seem to recognize this and errors. This format of a string has no problem working in AS 5.1 however. This is blocking JBossTools server integration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

10
31
0 / 0

[JBoss JIRA] (AS7-4720) Remove ProtocolTypeValidator

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-4720: ------------------------------------- Summary: Remove ProtocolTypeValidator Key: AS7-4720 URL: https://issues.jboss.org/browse/AS7-4720 Project: Application Server 7 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assignee: Paul Ferraro Priority: Minor Fix For: 7.2.0.Alpha1 The ProtocolTypeValidator class is unused. This seems correct since using it would imply restricting JGroups protocols to the list in the Protocol enum, and I don't believe the intent is to prevent use of custom protocols or new ones that the JGroups project itself creates. If this class is removed, the Protocol enum itself may be a candidate for removal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-686) Download statistics for the maven repository

by Geoffrey De Smet (JIRA)

Download statistics for the maven repository -------------------------------------------- Key: JBBUILD-686 URL: https://issues.jboss.org/browse/JBBUILD-686 Project: JBoss Build System Issue Type: Feature Request Components: Artifact Repositories Reporter: Geoffrey De Smet Fix For: Build Support 2011 Download statistics are an important requirement for project marketing. Last year, Sonatype announced download statistics for OSS projects on the central repository: http://www.sonatype.com/people/2010/12/now-available-central-download-sta... The JBoss repository should also have this. Even if a project (like drools or jbpm) is mirrored on central, only the originating repository (= the repository to which they were originally deployed) can host the download statistics. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
6
0 / 0

[JBoss JIRA] (LOGMGR-43) SubstituteFilter messages do not get formatted when using the PRINTF FormatStyle

by James Perkins (JIRA)

James Perkins created LOGMGR-43: ----------------------------------- Summary: SubstituteFilter messages do not get formatted when using the PRINTF FormatStyle Key: LOGMGR-43 URL: https://issues.jboss.org/browse/LOGMGR-43 Project: JBoss Log Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Fix For: 1.3.2.Final Looks like by default the FormatStyle.MESSAGE_FORMAT is being used resulting the PRINTF string not properly being formatted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
2
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 June 2012