Hope some one can help me on this.
This is my configuration :
I am using Windows XP (Prof Ed) JBoss 2.4.4, ant 1.4. J2SDK1.4
I have tested the "try ant" example in the doc and it works. But when I try to build the Interest EJB example from my build directory, I mean from examples/build direcotry as
ant ant intro-interest-jar
I get this error
Error while setting up environment for the application. Choose 'close' to terminate the application
The message comes on Windows Popup and in the dos prompt I get :
Any poniters to solve this problem will be appreciated.
> Hey cooper can you explain how is this done on a
> simple example, from core module's permissions. Let's
let's explain the second rule.
okay, if you look at module youraccount you will see the code :
moduleMetaData.getName() + ":" + operationMetaData.getName() + ":",
// then display an icon + a link
the rule :
you have to split it :
2 : group ID
200 : acces read
module:youraccount:published : component instance
user:(edithome|edituser|chgtheme|logout):.* : test instance
that means that plain users will be able to display
link in youraccount module to the module operation :
user : edithome
user : editusr
user : chgtheme
user : logout
when api.secAuthAction is called
it will say yes for module meta data
user and operation metadata edithome, editusr, chgtheme, logout.
basically the rule
"module:youraccount:published" will match the componentinstance : "module:youraccount:published"
because string are same (but first must be thought as a regular expression)
"user:(edithome|edituser|chgtheme|logout):.*" will match all constructed string such as
"user:edithome:" for instance.
I hope it's clear enough.
The best is to check CoreModule security and the class SecurityRule.
Nukes security is quite hard to figure out but once you've understood it's clear. But it's not easy to explain it.
Remember : security rules are stupid regular expression, a-la-unix.
> This is confusing ...
Security context is propagated in JBoss-Tomcat. I use the databaseserverloginmodule to authenticate and i can use methods like reqest.isUserInRole etc.
dev2gosoft, if you use DatabaseServerLoginModule, i guess somewhere in your application the user needs to log in, am i correct.
I also have strong feeling that in your login page you use an action="j_security_check". Allright, if so, that's why the propagation of JBoss/Tomcat works.
However, there are situation that we want to point our login page to another specific action, for instante, a action="MyLogonAction".This is very common if you're working with Struts (your action could be something like action="/MyLogonAction.do").
Inside this MyLogonAction class, wich is basically an ordinary servlet you would create your LoginContext and log the user in.
That's right there where the problem begins. If you log from inside this Servlet, you're logged allright in JBoss, but Tomcat doesn't know anything about that.
Get more information right here.
Its pretty simple.
If you do not use the Tomcat Authenticators (BASIC,DIGEST,FORM,CERT) your principal and roles will not be know in request.getPrincipal() and isUserInRole() and security-constraints in web.xml will not work.
If you use Jaas from a Login Context without using the JBoss security manager neither Tomcat nor JBoss will know about your authentication, user principal or role.
This is because Tomcat Authenticator doesnt use Jaas (never has) it delegates to a Realm (in this case JBossSecurityMgrRealm) which delegates to JBossSecurityManager which then uses Jaas. only by this process (or by replicating it) is the principal/roles known to Tomcat and JBoss.
This is NOT solved in JBoss4 as it is not a bug, it is just the way J2EE security works.
You have choices:
* Roll your own security system using an object in the session and filters.
* Write a custom tomcat authenticator.
I think its very well explained in the struts mailing list post you mention
I have strong feellings that you just didn't read the article i sent.
I'm using a FORM based authentication.
If you take a look at the discussion i sent (just click on that link and you'll see) you'll understand what i'm taliking about.
And this is a JBoss/Tomcat problem. Just try what i said (or what the discussion says) in any other server and you'll see it works.
I just would like to fix a little bit of my last post.
Actually, i (myself) have never tried to do that in other j2ee servers, but this information came to me as the same way as the one of the jboss/tomcat problem. In other words, i trust the people who gave me this information.
But anyway, as i didn't test it myself, i recognize that i couldn't post it with the confidence that i did.
Doing a JAAS login is independent of the FORM auth used to access secured web content. You cannot do a JAAS login from within a servlet and affect the secured identity tomcat sees at the web container level unless you create a custom FormAuthenticator or tomcat valve which interacts with the JAAS layer. This is outside of the scope of the j2ee security model and not supported expect by low level application server specific mechanisms.
everyone always talks about mechanisms,but the problem is still there,the best way is give me a sample,who can give me a sample?
There is no coupling between a session and the security domain cache. If you want that behavior its a simple matter of adding a session listener that invalidates the cache through jmx. I'll add a session listener that does this to the dist for 3.2.6RC2/4.0.0