December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4460) Jboss Password Encryption Security Flaw

by Scott Kesecki (JIRA)

Jboss Password Encryption Security Flaw --------------------------------------- Key: JBAS-4460 URL: http://jira.jboss.com/jira/browse/JBAS-4460 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.3 SP1 Reporter: Scott Kesecki Assigned To: Scott M Stark The Jboss salt to encrypt and decrypt passwords are stored in clear text in the jboss source that can be downloaded by everyone. Anyone that has a basic understanding of how java works can take the source tree get the class definition that has the password encryption and turn it into a a password decryption class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)

by Rico Apfelbeck (JIRA)

merge issue when removing from OneToMany in detached state (layered architecture) --------------------------------------------------------------------------------- Key: EJBTHREE-941 URL: http://jira.jboss.com/jira/browse/EJBTHREE-941 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 CR1 Environment: 13:37:59,625 INFO [ServerInfo] Java version: 1.5.0_09,Sun Microsystems Inc. 13:37:59,625 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_09-b01,Sun Microsystems Inc. 13:37:59,625 INFO [ServerInfo] OS-System: Windows XP 5.1,x86 Reporter: Rico Apfelbeck We work on a client-server environment with a webstart-client with an own JVM. Only the server has access to the JPA. POJOs are transfered from client to server and back. Our Issue occurs in the following workflow: - We get an Object A on the server from the Entitymanager and transfer it to the client. - This Object has a OneToMany-relation to some Objects B (fetchtype: EAGER, cascade: ALL). In B we have a reference to A. - On the client we remove in A some B from the Set, for example with clean() and transfer A back to the server. - We merge A on the server. - There is no exception thrown. The returned A from the merge-call does not contain any B, reloading A by Id results in a restored list containing the removed Bs. While added new Bs to A are stored correctly, removing them doesn't result in the deletion of the removed Bs from the database. Updating B in the List in A results in updated Bs when merging A. Only the removal causes problems. We assume that the problem comes from checking the now empty list against the database. Reloading A before merging in the server and manually compare the List of Bs, using EntityManager.remove() when neccesary. helps our case, but that's not the way it shoud be. :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

4
4
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-122) Use the ScopedClassPool from javassist

by Adrian Brock (JIRA)

Use the ScopedClassPool from javassist -------------------------------------- Key: JBMICROCONT-122 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-122 Project: JBoss MicroContainer Issue Type: Task Components: BeanInfo Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock The javassist reflection utilities use the original shared classpool. This does not understand classloaders. This should be updated to use the newer ScopedClassPool from javassist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

5
8
0 / 0

[JBoss JIRA] Created: (JBXB-100) Add support for unmarshal(Source)

by Thomas Diesler (JIRA)

Add support for unmarshal(Source) --------------------------------- Key: JBXB-100 URL: http://jira.jboss.com/jira/browse/JBXB-100 Project: JBoss XML Binding (JBossXB) Issue Type: Feature Request Affects Versions: JBossXB-1.0.0.CR9 Reporter: Thomas Diesler JBossWS fragments the incomming SOAP message into Source elements. Currently its using DOMSource. The interface to JBossXB is inefficient since the DOMSource needs to be serialized into a String and then into an InputStream. It would be much better if JBossXB could unmarshall the Source directly. Later we could transparently switch from DOMSource to some more efficient implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

4
7
0 / 0

[JBoss JIRA] Created: (JBCOMMON-38) Use URI instead of URL in FileProtocolArchiveBrowserFactory

by Davide Baroncelli (JIRA)

Use URI instead of URL in FileProtocolArchiveBrowserFactory ----------------------------------------------------------- Key: JBCOMMON-38 URL: http://jira.jboss.com/jira/browse/JBCOMMON-38 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Davide Baroncelli Assigned To: Dimitris Andreadis Priority: Critical Fix For: 2.2.2.GA Current code in FileProtocolArchiveBrowserFactory has problems when the URL coming from above contains escaped characters. E.g.: In an app. I'm writing, the class receives an URL coming from a ClassLoader.getResources method: resources in directories containing square brackets arrive to the class in escaped URLs such as the following: file:/C:/Stratosfera/pos_back/%5BCARCON%5Dstratosfera-verifica-cartoline-concorso/war/WEB-INF/classes/ this form fails in the current implementation because of line 40: File f = new File(url.getPath()); this results in a non existing file. Replacing the line with the following solves the problem: File f; try { f = new File(url.toURI()); } catch ( URISyntaxException e ) { throw new RuntimeException( e ); } this problems creates various compatibility problems in depending libraries (hibernate entitymanager for one). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-3773) Empty baseCtxDN and rolesCtxDN adds a comma to the userDn and user roles

by Eric van Lydegraf (JIRA)

Empty baseCtxDN and rolesCtxDN adds a comma to the userDn and user roles ------------------------------------------------------------------------ Key: JBAS-3773 URL: http://jira.jboss.com/jira/browse/JBAS-3773 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.5.CR1 Reporter: Eric van Lydegraf Assigned To: Scott M Stark The LDAP server (Lotus Domino) has users organized along different CtxDN contexts, so for JNDI empty contexts are used and the filter sorts out the users and groups. When Using LoginExtLoginModule, a sucessful retrieval of a User, has a full userDN but the code will append a comma expecting BaseCtxDN used in the search. The same is true for group membership. The solution I came up with is if the context is empty, no Ctx is appended and only the search result is preserved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4504) Container does not report invalid named query exception

by Radim Marek (JIRA)

Container does not report invalid named query exception -------------------------------------------------------- Key: JBAS-4504 URL: http://jira.jboss.com/jira/browse/JBAS-4504 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.0.5.GA Environment: java 5 update 11; jboss 4.0.5 GA Reporter: Radim Marek Assigned To: Carlo de Wolf Priority: Minor When entity manager is called to create non-existing named query (for example because of mistyping), container doesn't throw a persistence exception. Code Query query = entityManager.createNamedQuery("MarketingBatch.getBatches"); had been called from remote client and exception had appeared only on client as ClassNotFound: org.hibernate.MappingException. Other problems with named query are reported as expected. I thought all exception not handled by session bean should be reported. It would be at least convenient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-131) Complete the WeakTypeCache/Generics implementation

by Adrian Brock (JIRA)

Complete the WeakTypeCache/Generics implementation -------------------------------------------------- Key: JBMICROCONT-131 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-131 Project: JBoss MicroContainer Issue Type: Task Components: BeanInfo Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock There are still a few things to do to complete the generics support. 1) The WeakTypeCache is caching generics types against the type.toString() which is probably not portable across all JDKs? 2) The support for TypeVariable and GenericArrayType needs implementating -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-4005) Error reading web.xml with external entities when taglib is used

by Angela Roberts (JIRA)

Error reading web.xml with external entities when taglib is used ---------------------------------------------------------------- Key: JBAS-4005 URL: http://jira.jboss.com/jira/browse/JBAS-4005 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.0.5.GA Environment: MacOsX, JBossAS-4.0.5 Reporter: Angela Roberts Assigned To: Remy Maucherat See the sample application attached. It contains a web.xml that uses an external entity: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app [ <!ENTITY inc SYSTEM "web-include.xml">]> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"> &inc; </web-app> When the first JSP of this application is called, if this JSP declares a taglib, JBoss can't find the included xml file. This is the stack trace: 18:36:57,289 ERROR [MyEntityResolver] Invalid PUBLIC ID: null 18:36:57,351 ERROR [MyEntityResolver] Invalid PUBLIC ID: null 18:36:57,358 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception java.io.FileNotFoundException: /Applications/jboss-4.0.5.GA/bin/web-include.xml at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:94) at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:103) at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:95) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:132) at org.jboss.web.tomcat.tc5.jasper.TagLibCache.processWebDotXml(TagLibCache.java:162) at org.jboss.web.tomcat.tc5.jasper.TagLibCache.init(TagLibCache.java:99) at org.jboss.web.tomcat.tc5.jasper.TagLibCache.getLocation(TagLibCache.java:83) at org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:526) at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:422) at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1556) at org.apache.jasper.compiler.Parser.parse(Parser.java:126) at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:211) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:100) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:155) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:295) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:276) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:264) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:305) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:613) The same application works ok on Tomcat 5.5. I believe this is related to Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=34034 . This bug is already fixed on Tomcat, but the way class org.jboss.web.tomcat.tc5.jasper.TagLibCache deals with entities may be the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3841) Occasional NPE in org.apache.commons.modeler.Registry during startup

by Rolf Arne Corneliussen (JIRA)

Occasional NPE in org.apache.commons.modeler.Registry during startup -------------------------------------------------------------------- Key: JBAS-3841 URL: http://jira.jboss.com/jira/browse/JBAS-3841 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.0.3 SP1 Reporter: Rolf Arne Corneliussen Assigned To: Remy Maucherat Sometimes (but less than half the times), I get the following in the log when JBoss is started: 2006-11-09 17:38:14,453 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080 2006-11-09 17:38:14,468 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8443 2006-11-09 17:38:14,468 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-9443 2006-11-09 17:38:14,484 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)] Started in 19s:531ms 2006-11-09 17:38:14,500 WARN [org.apache.commons.modeler.Registry] No metadata found for org.apache.coyote.RequestInfo 2006-11-09 17:38:14,500 ERROR [org.apache.commons.modeler.Registry] Error registering jboss.web:type=RequestProcessor,worker=http-0.0.0.0-8443,name=HttpRequest2 java.lang.NullPointerException at org.apache.commons.modeler.Registry.registerComponent(Registry.java:862) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.init(Http11Protocol.java:709) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.getInitData(LeaderFollowerWorkerThread.java:48) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:673) at java.lang.Thread.run(Thread.java:595) 2006-11-09 17:38:14,500 WARN [org.apache.coyote.http11.Http11Protocol] Error registering request -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007