June 2007 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Permissions on temporary destinations (JBMESSAGING-994)

by sergeypk

"timfox" wrote : And | | 1) Is a higher priority and should be implemented now | | 2) Is a lower prioriry task and can wait until remoting 2.0 | | Sergey - can you execute? Ok, I'll implement option 1 (skipping security checks altogether on temp destinations) and add a JIRA issue for option 2. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055983#4055983 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055983

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Out-of-the-Box Integration of 2.6 with JBoss AS 4.2

by thomas.heute＠jboss.com

So i spent most of my night on this for no result so far... The underlying problem is that jsf-portlet.jar includes a faces-config.xml to set up different factories. That faces-config.xml is read by myFaces in 4.0 and then breaks everything. If you remove it then it won't work in 4.2 (it's using a servlet factory instead of some portlet factory, hence the stack trace that Sohil posted). I tried to programatically set those factories in the case that it is running wih JSF Sun RI, but once set you cannot change it and the factory for servlet environment is indirectly included through the JBossJSFConfigureListener then it's too late to override that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055982#4055982 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055982

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: hiding portlet.

by thomas.heute＠jboss.com

Please use the User forum, not the "Design of Jboss Portal forum" you should have read: http://jboss.org/index.html?module=bb&op=viewtopic&t=75280 I'm moving all your questions to the other forum View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055978#4055978 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055978

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Permissions on temporary destinations (JBMESSAGING-994)

by thomasra

Agreed. Usable default with available options for tightening. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055963#4055963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055963

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Permissions on temporary destinations (JBMESSAGING-994)

by timfox

And 1) Is a higher priority and should be implemented now 2) Is a lower prioriry task and can wait until remoting 2.0 Sergey - can you execute? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055962#4055962 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055962

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Permissions on temporary destinations (JBMESSAGING-994)

by timfox

"thomasra" wrote : To sum it all up: I don't think rolebased security is appropriate for temp destinations at all (neither consuming nor producing), the only restriction needed is the one related to consumers, which isn't security code. Well, yes, that is one option, we just drop role based security altogether for temp destinations and just have the current check which verifies that consumers can only be created by the connection that created the temp dest. (Easy option). But most of this thread is about how do we configure security for users who *write* (i.e. send messages) to the destination - this is what we are really discussing. Here is the use case: User creates temp reply queue and sends a message to a topic with the JMSReplyTo header set. The message is received by many subscribers, but only some of them are allowed to reply. E.g. it might be a news feed and only "gold subcribers" can reply. We don't want all the unregulated subscribers to reply since they could implement a DOS attack. So, in this case role based security for *writing* to the destination is useful, but only useful for *writing*. This is why Sergey is allowing this to be specified on the connection factory. So, I think what we should do is the following: 1) If no security override is specified on the connection factory then the temp destination has full access to everyone. The check in the code will prevent consumers being created by anyone other than the creating connection anyway. 2) If security override is specified on the connection factory then that will take effect, this is useful for the use case explained above. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055960#4055960 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055960

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Permissions on temporary destinations (JBMESSAGING-994)

by thomasra

To sum it all up: I don't think rolebased security is appropriate for temp destinations at all (neither consuming nor producing), the only restriction needed is the one related to consumers, which isn't security code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055956#4055956 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055956

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Permissions on temporary destinations (JBMESSAGING-994)

by thomasra

Just a brief question: if, as you say, you handle the issue of protecting a temp destination from being consumed by anyone other than the original connection _outside_ any security code, then why bother using it when you _are_ within the same connection? Couldn't the temp destination include metadata describing the original connectionid/sessionid, and just check that consumers belong to the same id? No other checks need to be made, and no more configuration needs to be extended on the connectionfactory? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055954#4055954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055954

18 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction ha

by mark.little＠jboss.com

You could do it that way. I wouldn't normally call commit on an application exception either. In general, if you're unsure about how to terminate a transaction it's always safer to roll it back than commit: at least you can be (or should be) confident that the previous state was consistent. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055953#4055953 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055953

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Permissions on temporary destinations (JBMESSAGING-994)

by timfox

As I say, if you can come up with a better solution, go for it. It's just I haven't heard one yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055952#4055952 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055952

18 years, 9 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 June 2007