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

[Design of JBoss Tools (dev)] - Re: xdoclet eclipse The currently displayed page contains in

by renbing

same problem - Eclipse 3.2.0, Jboss IDE 1.6.0, following tutorial View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096802#4096802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096802

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Integration on JBoss5: NullPointerException deploying jm

by scott.stark＠jboss.org

I see the problem and am fixing it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096780#4096780 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096780

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: mbean to bean conversion guide

by scott.stark＠jboss.org

its called eclipse. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096776#4096776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096776

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock in JBoss Messaging during JBoss5 shutdown

by clebert.suconic＠jboss.com

There are two problems here: I - The MDB is being stopped after the ServerPeer... I will verify how to enforce the dependency. II - Looking at trunk now (r66236), I see that ejb-links are not working, as I stated here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121286 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096767#4096767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096767

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: So what does unification mean for the ejb containers

by scott.stark＠jboss.org

18 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - SRP and SASL

by david.lloyd＠jboss.com

As I've stated before, I intend for JBoss Remoting 3 to utilize SASL for authentication, with SRP as its default mechanism. So pursuant to that, yesterday I put together a simple SRP SASL client & server provider. However, I can't work out the best way to handle password verification on the server side. One of the key security advantages of SRP is that the server does not need to store the user password, so if this database is compromised, the attacker cannot directly use this database to impersonate users. Instead, SRP stores a password verifier which is calculated from the password using a one-way algorithm. However the default SASL mechanisms generally require the server to have a copy of the cleartext password. In fact, the SASL API does not even include a Callback type to handle a password verifier of any kind. So, using just the default SASL API, there is no way to acquire the SRP password verifier value. Here's the options as I see them: Option #1: Just use PasswordCallback on the server side to get the clear password and derive the verifier from that value at authentication time. Pro: uses existing API; compatible out-of-the-box with code that uses default mechanisms such as DIGEST-MD5 or CRAM-MD5. Con: Loses key advantage of SRP (ability to avoid storing cleartext passwords). Option #2: Add a custom VerifierCallback used by the server side to get the verifier value. Pro: Stronger server-side security (no cleartext passwords stored). Con: SRP server code must be aware that SRP is the mechanism in use; will not be portable between different SRP SASL implementations (on the server side anyway). Option #3: Do not use a callback for password or verifier; instead, use a SASL configuration parameter to specify either a password file or some other means to acquire the verifier. Pro: still *mostly* compatible out-of-the-box with SASL authentication code (still would use NameCallback and AuthorizeCallback normally). Con: "mostly" != "fully"... Another possible option is to create a new GSSAPI provider and use SRP that way, with a special credential for SRP verifier. However, Sun's GSSAPI SASL mechanism cannot support any GSSAPI mechanism other than Kerberos. Also, this is a considerably more complex solution, and requires additional security APIs. For these reasons, I don't want to go this route for Remoting unless there's no other choice. I'm leaning towards doing Option #1 by default, for simplicity, but providing a SASL server property that can be enabled that causes the server to use the custom VerifierCallback, per Option #2. Any opinions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096743#4096743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096743

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: mbean to bean conversion guide

by alesj

"scott.stark(a)jboss.org" wrote : | http://wiki.jboss.org/wiki/Wiki.jsp?page=ConvertingMBeanServiceToMCBean | What about some tool to do this? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096732#4096732 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096732

18 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: splitting access= on variables into multiple attributes

by kukeltje

And yes, I know this can all be done in the generated forms, but so can "access=read, write, required" so that will not be accepted as a reason for *no* ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096727#4096727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096727

18 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - splitting access= on variables into multiple attributes

by kukeltje

I know work is being done on WS-HumanTasks as a probable solution for the task configuration in the PVM. (133 pages... wow.....) 4.0 will not be out shortly, but I do see enhancements to the current UI that would be to difficult, while maintaining backwardscompatibility. A variable is currently written as <variable access="read,write,required" name="myVar"></variable> Most web ui frameworks use something like <variable readOnly="true" required="true" name="myVar"></variable> The read is often not there, so it is not needed imo (if you cannot read it, you should not put it there) This would make it possible to do things like <variable readOnly="#{actorId=='Ronald'}" required="#{transition == 'GoLeft'}" name="myVar"></variable> Or more complex ones... Conditionally requiring variables. This would greatly enhance the capabilities of the webconsole, doing even nicer things in RAD environments. Ofcourse access= should still be supported, so I do *NOT* propose to ditch this, or write any converters. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096715#4096715 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096715

18 years, 5 months

1
0
0 / 0

[Design of JBoss Build System] - Re: AS integration project release procedure

by pgier

I added a top level pom to function as an aggregate. I did the release, and this seemed to work ok. It was able to tag the whole structure instead of just the build directory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096707#4096707 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096707

18 years, 5 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 October 2007