Ooops.
Sorry, I have not gotten the latest patch, this was fixed 9 days
ago. And as I remember it now, I may have introduced the bug myself, the
original JbossRealm did not set the password altogether and I was not
aware at the time of fixing it that it needs to be assignable to a char[],
so I just used a String.
Though, actually, it may be that there is still a bug in the current
implementation.
What happens if the password in the TomCat session is null while
SecurityAssociation still has the old password? With the current code, it
will not get reset to null, I assume. My modification resets the password.
On Tue, 6 Mar 2001, Anatoly Akkerman wrote:
>
> Hello, everybody.
>
> Here is what I ran across. JaasSecurityManager expects the Credential
> object from the SecurityAssociation to be assignable to a char[], while
> JbossRealm Tomcat interceptor sets the Credential object to be a String
> which is the password from the Tomcat session. This causes problems when
> EJB requests are coming from web-tier into a JAAS secured container.
>
> I checked my mods and they fix the problem that I was experiencing. I was
> not sure if I should go ahead and fix it myself in the CVS, so I am
> posting this. Instead of JbossRealm.java:35
>
> SecurityAssociation.setCredential(passwd);
>
> it should be something like:
>
> SecurityAssociation.setCredential((passwd == null)? null: passwd.toCharArray());
>
> Anatoly Akkerman.
>
>
