[JBoss JIRA] Created: (JBESB-181) Provide a more convenient/obvious means of accessing the "current" object on the Message Body???
by Tom Fennelly (JIRA)
Provide a more convenient/obvious means of accessing the "current" object on the Message Body???
------------------------------------------------------------------------------------------------
Key: JBESB-181
URL: http://jira.jboss.com/jira/browse/JBESB-181
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: ESB Core
Affects Versions: 4.0
Reporter: Tom Fennelly
Assigned To: Mark Little
Priority: Minor
Fix For: 4.0
ActionProcessors need to call "Message.getBody().get(CURRENT_OBJECT)" in order to access the "current" body Object. Is this not a little obscure? Would it not be more convenient/intuitive if the "current" object could be accessed via something like "Message.getBody().getCurrent()" - it could wrap "Message.getBody().get(CURRENT_OBJECT)" in the Body impl.
Also, should CURRENT_OBJECT be defined on the ActionProcessor or Body type? It's currently defined in ActionProcessor? Of course this would mean that the current "Message.getBody().get(CURRENT_OBJECT)" calls would all need to be modified to "Message.getBody().get(Body.CURRENT_OBJECT)", but I'd think that is clearer anyway.
Just some usability thoughts - feel free to delete the issus!
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3739) On Windows: jbossmq.test.SecurityUnitTestCase fails
by Prabhat Jha (JIRA)
On Windows: jbossmq.test.SecurityUnitTestCase fails
---------------------------------------------------
Key: JBAS-3739
URL: http://jira.jboss.com/jira/browse/JBAS-3739
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS service, Security
Environment: Windows 2003, Sun JDK 1.4
Reporter: Prabhat Jha
Assigned To: Adrian Brock
Fix For: JBossAS-4.0.5.GA
jbossmq.test.SecurityUnitTestCase#runLoginTest fails.
javax.jms.JMSSecurityException: Connection not authorized to do durable subscription on topic: securedTopic
at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:150)
at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:643)
at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:177)
at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:185)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
at java.lang.Thread.run(Thread.java:534)
This results into the assertion fail error which is:
junit.framework.AssertionFailedError: Subscriber did not get correct number of messages 0 expected:<5> but was:<0>
at org.jboss.test.jbossmq.test.SecurityUnitTestCase.runLoginTest(SecurityUnitTestCase.java:67)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3714) EjbHome.create throws ClassCastException
by warren crossing (JIRA)
EjbHome.create throws ClassCastException
----------------------------------------
Key: JBAS-3714
URL: http://jira.jboss.com/jira/browse/JBAS-3714
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: IIOP service
Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
Environment: Java 1.5.0_08
Reporter: warren crossing
Assigned To: Francisco Reverbel
Hello
Please have a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974096#3974096 as this sums up my issue.
I have a jboss.log file and am happy to patch the source code and test/debug this issue.
It looks as though the IOR stream to object is returning a org.jacorb.orb.Reference which does not implement the beans Remote interface.
I have stepped through the iiop EjbObjectServant code and IORFactory, the everything looks fine, no amount of changing jboss.xml ro standardjboss.xml makes any difference.
Why possibly could the reference returned by the DynamicIIOPStub.invoke not implement the Bean Remote interface?
Any idea, or hist of where to look/debug?
--
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
19 years, 2 months
[JBoss JIRA] Created: (JBPORTAL-1064) Admin module is vulnerable to XSS attacks.
by Roman Arkhangelskiy (JIRA)
Admin module is vulnerable to XSS attacks.
------------------------------------------
Key: JBPORTAL-1064
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1064
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.4 Final
Reporter: Roman Arkhangelskiy
Assigned To: Julien Viet
After having been run on JBoss-Portal 2.4.0 source code, Jtest's BugDetective feature reported a lot of places that make the 'admin' module vulnerable to XSS attacks.
There are quite a few such places in the code and it is not difficult to locate them. For example the variable named 'sCurrPath' seems to be widely used in many jsp-pages of the module, and it happens very often that it's value, having been obtained directly from ServletRequest, is displayed (or used for the initialization of forms' hidden fields) without any prior validation. Such approach makes it possible for the malicious user to perform an XSS attack.
I realize that this module represents an area with the restricted access, but I can also envision a situation when the UI of the administrative module itself does not allow any harmful action to be performed, but it is possible to use a kind of specific http-client to construct dangerous requests. So from technical point of view any data coming from client should be validated before their further use even in restricted areas.
The real-life example in file src/portal-core-war/WEB-INF/jsp/cms/admin/upload.jsp:
the value of 'sCurrPath' variable is used at line 18 while having been already 'tainted' at line 10. It is worth to track the use of all variables with this name across the entire module to see all the dangerous situations.
Please let me know if you think this represents a real problem or BugDetective is mistaken.
Thank you!
--
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
19 years, 2 months
[JBoss JIRA] Created: (EJBTHREE-728) Constructing relative path in PersistenceUnitDeploymen.start bogus for ../../foo.jar
by Heiko W. Rupp (JIRA)
Constructing relative path in PersistenceUnitDeploymen.start bogus for ../../foo.jar
------------------------------------------------------------------------------------
Key: EJBTHREE-728
URL: http://jira.jboss.com/jira/browse/EJBTHREE-728
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - FD
Reporter: Heiko W. Rupp
The following code in PersistenceUnitDeployment.start() tries to construct an absolute path when given a relative URL
String base = di.getUrl().toString();
jar = jar.replaceAll("\\.\\./", "+");
int idx = jar.lastIndexOf('+');
jar = jar.substring(idx + 1);
for (int i = 0; i < idx + 1; i++)
{
int slash = base.lastIndexOf('/');
base = base.substring(0, slash + 1); // (1)
}
url = new URL(base + jar.substring(idx)); // (2)
This fails in 2 places:
1) Only the last component is chopped of. After this the statement is a noop, as the slash found is always the trailing character of the String
2) The already 'corrected' jar is crippled when more than one ../ combination is in the jar path
A fix can look like this:
{
int slash = base.lastIndexOf('/');
base = base.substring(0, slash ); // (1)
}
url = new URL(base + "/" +jar); // (2)
--
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
19 years, 2 months