DO NOT REPLY [Bug 43214] New: - Calls to Embedded.setRealm(Realm) fails

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43214

   Summary: Calls to Embedded.setRealm(Realm) fails
   Product: Tomcat 5
   Version: 5.5.23
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P3
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


OVERVIEW

Embedded.setRealm(Realm) does not seem to set the Realm of StandardEngine.  This
causes an authenticated JAAS principal (user) to always get a 403 (access to the
requested resource has been denied) error displayed on the browser.

STEPS TO REPRODUCE
---
I set up a Realm like this:


   // create the engine and default host
   catalinaEngine = embeddedCatalina.createEngine();
   catalinaEngine.setName(REALM_PNS); //JAAS Realm name must equal engine name 

   // create realm for authentication
   JAASRealm jaasRealm = new JAASRealm();
   jaasRealm.setUserClassNames("nz.co.picksend.usermanagement.User");
   jaasRealm.setRoleClassNames("nz.co.picksend.usermanagement.Role");
   jaasRealm.setUseContextClassLoader(false);
   embeddedCatalina.setRealm(jaasRealm);


When I log in to any web application, I am authenticated but get a 403 (access
to the requested resource has been denied) error on any page.  The reason is
that the instance of StandardEngine has a different instance of JAASRealm than
was created with the code above.  The new instance is created in
StandardEngine.getRealm() if no instance of a realm already exists (line 139):


   public Realm getRealm() {
Realm configured=super.getRealm();
// If no set realm has been called - default to JAAS
// This can be overriden at engine, context and host level  
if( configured==null ) {
configured=new JAASRealm();
this.setRealm( configured );  //<-- NEW INSTANCE CREATED HERE
}
return configured;
}

This realm naturally does not contain the values for userClassNames and
roleClassNames and thefore cannot find out if a user is in a particular role,
causing a 403 error.

Stepping through the code, it appears that Embedded.setRealm(Realm) never
results in a call to StandardEngine.setRealm(Realm).

WORKAROUND
--
The workaround is to create the instance of JAASRealm before creating Embedded,
such as:

   embeddedCatalina = new Embedded(jaasRealm);

However, you must use the deprecated method JAASRealm.setAppName() to set the
JAAS name because the containers name cannot be determined at this point and
therefore defaults to "other".

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tagging 5.5.25

[Yoav Shapira]

Hey,

On 8/24/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> Release candidate can be found at
> http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.25/

Looks good to me after some cursory usage testing.

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java

[Bill Barker]

"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Bill Barker wrote:
>> "Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message 
>> news:[EMAIL PROTECTED]
>>
>>> Bill Barker wrote:
>>>
 "Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message 
 news:[EMAIL PROTECTED]


> Bill Barker wrote:
>
>
>> "Remy Maucherat" <[EMAIL PROTECTED]> wrote in message 
>> news:[EMAIL PROTECTED]
>>
>>
>>
>>> Filip Hanik - Dev Lists wrote:
>>>
>>>
>>>
 Test Case and 5.5.x patch can be found here.
 http://people.apache.org/~fhanik/tomcat/b2c/

 This is what is happening

 int cnt=conv.read( result, 0, BUFFER_SIZE );
 is called with a "while (true)" statement,

 When the IntermediateInputStream.read returns -1, the above 
 statement returns cnt==1.
 So to avoid calling conv.read, we must check to see if we have more 
 bytes to read by implementing the available() method, to avoid the 
 inputstream ever returning -1.



>>> It's possible, but I have a hard time understanding the issue.
>>>
>>>
>>>
>>>
>> The issue is that InputStreamReader reads 8192 bytes from 
>> IntermediateInputStream on the first go.  It then translates them 
>> into 2734 chars, but thinks that the last few bytes represent an 
>> incomplete char, so holds onto them.  On the next call, 
>> IntermediateInputStream returns -1, so InputStreamReader outputs the 
>> last char as best it can (resulting in returning 1).  Then the 
>> IntermediateInputStream buffer is reset, and it can continue on 
>> reading (but from the wrong position, resulting in corruption).
>>
>> Filip's patch is inelegant (better would be to use the ByteChunk 
>> sink), but other than my looking for a better way to do it, I can't 
>> come up with the required technical reason to porting the base of it 
>> to 5.5 (of course, I could care less what he does in his sandbox :).
>>
>>
>>
> I've committed the fix to 5.5, if you find a more elegant way of 
> solving the actual problem, feel free to revert it and commit another 
> fix. I don't care about the how, as long as there is a fix that will 
> be included in the tag 5.5.25 on Friday
>
>
>
 No problem.  I can see how to do this better, but I'll wait until the 
 weekend to commit (since it's not totally trivial, I don't want a 
 one-day window for regression testing :).  That way 5.5.25 can go out 
 with your patch.  It doesn't include the NIO dependancy (which was my 
 only concern), so it works well enough for me for now.


>>> according to the KISS principle, your fix would have to be less than 4 
>>> lines changed to be "more elegant" :)
>>>
>>>
>>
>> Yes, it is more than 4 lines, but most of them are deletes :).  I've done 
>> it already on my local machine here, in case anybody wants RTC on the 
>> 5.5.x branch (and Filip's test case passes with flying colors :).  I'm 
>> pretty much sure that there are no regressions for 5.5.x+, but I still 
>> need to look at 3.3.x,  and 4.1.x.
>>
>> If anyone is interested, I can post the patch files.  Otherwise, I'll 
>> assume that CTR is still in place, and you can veto it when I commit over 
>> the w/e ;).  Of course, if this message was meant as a pre-emptive veto, 
>> then I won't bother.
>>
> it's your choice if you want to commit it before or after the tag today.
> If you wanna commit it before, then we are counting on your vote :)
>

I've noticed a problem with using Reader.mark with multi-byte charsets (we 
have a hack in place that works for single-byte charsets).  I could just 
commit what I've got here (which should be no worse than before :), but I'd 
like to solve this once and for all first.

Using Filip's example servlet, if you modify it to do:
reader = request.getReader();
+reader.mark(5);   // content length + terminator
while (true) {
int c = reader.read();
if (c == -1 || c == '/')
break;
buf.append((char)c);
}
+   reader.reset(); // throws IOException here

With the current code (and what I have), the first call to reader.read 
requests 8192 chars, and produces 2734 chars.  The current code then results 
in throwing away the last 2729 chars and abandoning the mark.  The best I've 
got until now preserves the 2729 chars, but still throws away the mark, and 
hence still throws an IOE when reset is called.

Long story short, I'm not now sure that I can promise to commit a fix this 
weekend :(.

> Filip
>>
>>> Filip
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL