February 2008 - jboss-dev-forums - Jboss List Archives

[Deployers on JBoss (Deployers/JBoss)] - Module Order Proprietary Option Backward Compatibility Issue

by richard.opalka＠jboss.com

Hi folks, I was asked by Dimitris to initiate this forum thread. The problem I'd like to talk about is described here: http://jira.jboss.com/jira/browse/JBAS-5115 In short: I've got correct AS 4.x DD with the following content: <?xml version='1.0' encoding='UTF-8' ?> | | <!DOCTYPE jboss-app | PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN" | "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd"> | | <jboss-app> | <module-order>strict</module-order> | </jboss-app> | Archive with such jboss-app.xml file works very well on AS 4.x but fails on AS 5.x with the exception (available in aforementioned bug). From my point of view it's backward compatibility issue. Scott Stark in this thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=127984 writes: anonymous wrote : It should at least parse and produce a warning if the behavior is not supported. What do you think about it folks? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127369#4127369 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127369

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: moving SecurityAspect to be an interceptor

by ataylor

anonymous wrote : Good point. When I think about it, I don't really see what's wrong with having the username/password on the ServerConnectionEndpoint. After all they're just attributes, as long as the security logic itself is not there but in the interceptor then that should be ok IMHO. Can you clarify! I'm not sure i follow, the interceptor has no access to the ServerConnectionEndpoint. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127346#4127346 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127346

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: moving SecurityAspect to be an interceptor

by timfox

"ataylor" wrote : | Ok, so adding and removing the users from the map on creating a connection and closing a connection is fine. If the server closes the connection via the connection manager on client fail, the interceptor wouldn't get called and the user would remain in the map. Good point. When I think about it, I don't really see what's wrong with having the username/password on the ServerConnectionEndpoint. After all they're just attributes, as long as the security logic itself is not there but in the interceptor then that should be ok IMHO. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127344#4127344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127344

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: moving SecurityAspect to be an interceptor

by ataylor

Yes. | | Creat connection request takes a user id, *and* a password. The password is hard to guess. | | If you authenticate and then allow the same user id to be used in subsequent operations without a password, then that's exploitable, since authentication is already done by that point. of course! anonymous wrote : Instead you could maintain a map of packet target id to user id in the server side filter and use th | at. Ok, so adding and removing the users from the map on creating a connection and closing a connection is fine. If the server closes the connection via the connection manager on client fail, the interceptor wouldn't get called and the user would remain in the map. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127340#4127340 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127340

18 years, 2 months

1
0
0 / 0

[QA of JBoss Portal] - Re: JBoss Portal 2.6.3 Installation Hang

by thomas.heute＠jboss.com

Still the wrong forum... There is no installation per se, the AS is running: "17:06:28,043 INFO [Server] JBoss (MX MicroKernel) [4.2.2.GA (build: SVNTag=JBos s_4_2_2_GA date=200710221139)] Started in 1m:23s:614ms" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127338#4127338 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127338

18 years, 2 months

1
0
0 / 0

[QA of JBoss Portal] - Re: JBoss Portal 2.6.3 Installation Hang

by mdelas

"Great" response Thomas. I have the same problem and still have not found an explanation/solution/workaround or clue. I have just downloaded jbossportal-2.6.3 binary, copied .sar directory to a fresh instance of JBoss 4.2.2, added oracle datasource and driver, as it says in the docs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127335#4127335 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127335

18 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Versioning Conventions

by wolfc

See http://docs.jboss.org/process-guide/en/html/release-procedure.html. Now 0.12.0 is the baseline for most components as they're coming out of the RC12 codebase. So yes, some components will start leaping forward while other (/new) components will start of at 0.1.0. We'll not create branches just because we can. We'll only create them if we need to backport (which we'll rarely (if ever) do). As long as we're at major 0, it's an unsupported component. We don't care about backwards compatibility. Starting with major 1 it's a supported component. We'll keep it at major 1 as long as we can maintain backwards compatibility (which should be a very long time). Within majors we only support the latest minor. So in actuality we only have branches for the major versions (which should be one (== trunk)). Going to a new major should result in End-Of-Life of the previous major (so preferably ~3 years after it's release). As long as we don't use any snapshots and have a clean test suite we can release at any time. So hotfixes can always go into trunk. If not, then we do actually branch. There could be a product matrix, if we define some proper component plugin points. For now the ejb3 plugin depends on core which has transitive dependencies on other ejb3 components. This should be properly handled in the assembly. Same goes for AS & Embedded, they suck in a specific version of core as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127329#4127329 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127329

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: moving SecurityAspect to be an interceptor

by timfox

"ataylor" wrote : That would be exploitable since a rogue client could just send (guess) someone else's user id. Is that different from how the createconnectionrequest works now. | Yes. Creat connection request takes a user id, *and* a password. The password is hard to guess. If you authenticate and then allow the same user id to be used in subsequent operations without a password, then that's exploitable, since authentication is already done by that point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127328#4127328 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127328

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: moving SecurityAspect to be an interceptor

by ataylor

That would be exploitable since a rogue client could just send (guess) someone else's user id. Is that different from how the createconnectionrequest works now. Instead you could maintain a map of packet target id to user id in the server side filter and use that. That was my first solution but the interceptors wouldnt get called if the connection was removed by the server and we would end up with an ever growing map. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127325#4127325 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127325

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: moving SecurityAspect to be an interceptor

by timfox

That would be exploitable since a rogue client could just send (guess) someone else's user id. Instead you could maintain a map of packet target id to user id in the server side filter and use that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127324#4127324 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127324

18 years, 2 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-dev-forums February 2008