[Security & JAAS/JBoss] - Re: LDAP and JBoss
by rukh
thanks for the reply :)
my login-config.xml looks like this (excluding the standard policies that were there when I set up the server)
anonymous wrote :
| <application-policy name="authPolicy">
|
| <login-module code="com.caern.authentication.SecurityLoginModule" flag="required">
| <module-option name="userRolesDbSql">
| SELECT name FROM caern_role, caern_user WHERE caern_user.id=?
| </module-option>
| <module-option name="userRolesDataSource">java:/CaernDS</module-option>
| </login-module>
|
| </application-policy>
|
I dont use the sufficient flag anywhere so I guess it is not the point :(
com.caern.authentication.SecurityLoginModule is a decompiled version of LdapLoginModule with some enhanements that were nescessary.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134749#4134749
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134749
18 years, 1 month
[EJB 3.0] - Re: Storing user info on server
by ALRubinger
"jwcone" wrote : Is there a client-agnostic equivalent to the HttpSession at the container-level?
Well, no. For that you'd have to roll your own.
This has actually got me thinking quite a bit. :)
My decision to use a webapp as an example takes for granted encapsulation of a request, and tying this request to a session. And my little mashup also presupposes your web container is in the same JVM as the JEE app. These are some bad assumptions to make.
So this makes for a pretty neat exercise: how do we model an application request without respect to the type of client?
I've already addressed the handling of an "Application Session" via a SFSB proxy that's placed in Thread scope for the duration of the request. What we're now missing is a layer capable of storing that proxy to model a "Client Session", and tying it with an "Invocation Request".
So the responsibilities of this layer would be:
* Maintain a map of Client Sessions
* Translate an Invocation Request into the proper executions
* Register the Application Session with the Thread based on the SFSB stored in the Client Session looked up from something in the payload of the Invocation Request
You could probably build a whole client-centric invocation framework upon this model, to which many implementations could support. Servlet, Flex, RMI...all become users of this layer which abstracts the client type from the Application itself.
I'm not really giving you answers here, clearly, but you're spinning my gears.
Let's take your GUI. You could easily store a SFSB proxy to model your session on the client, and invoke *through* it to access other Services. Problem is, you don't really want to be using a delegate pattern here - any time you add/edit/change a service you'd have to update the SFSB to support that change. But if the SFSB had a more dynamic "invokeService()" method, you could use that to get to your other services. And if the SFSB on your client also had within it a reference to another SFSB (your Application Session), then after you call "invokeService" the container could automatically register your Application Session.
Food for thought, if nothing else.
*How do we best implement client-agnostic session handling*?
Thanks for the fodder for next week's blog, anyway. I'll be thinking more on this.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134748#4134748
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134748
18 years, 1 month
[JBoss jBPM] - jBPM exception handling
by syedtaj
Hello,
I am a bit confused as how to implement exception handling in jBPM. Exceptions can occur in the delegation classes and I need to stop the default flow of the transition. I mean, once an exception is caught I might want to do something - send a mail etc. and stop executing the transition. But according to the documents -
anonymous wrote : Note that the exception handling mechanism of jBPM is not completely similar to the java exception handling. In java, a caught exception can have an influence on the control flow. In the case of jBPM, control flow cannot be changed by the jBPM exception handling mechanism. The exception is either caught or uncaught. Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. For caught exceptions, the graph execution continues as if no exception has occurred.
|
Is there something else that can be done? A work around that I can think of is to set some context variable if an exception occurs, and have a decision box after the node where I am expecting the error to occur and check the variable and decide the course of the action. However it does not solve the entire problem, since there may be other cases as exceptions can occur anywhere.
Are there any other means of exception handling that I am missing?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134747#4134747
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134747
18 years, 1 month