On 11/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Yoav Shapira wrote:
> On 11/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
>> > Because these are internal implementations, if the user is whack
>> > enough to try and access the real object behind the facade, I'd say
>> > they're at their own risk.
>>
>> I disagree: if the security manager is there, then there should be no
>> way to get the internal object.
>
> You know what, on second reading I tend to agree with you. Users who
> are security-conscious enough to enable their security manager are
> going to care about this. Can we do extra checking then, to prevent
> access to the internal objects, without compromising performance?
>
> Won't the fact that the internal objects behind the facade live in
> separate packages be sufficient for the security manager to
> automatically deny access to them?
The problem is that the users are trying to introspect a concrete
implementation class, which I think isn't right since only the public
API should be visible to the application. If they were introspecting the
public interface and it was not working, then I would agree to fixing
this. Their code can be modified to be smarter about what they're
introspecting, I think.
My initial thought when reading the original proposal is that the
client code using reflection was broken. As I understand it, if they
call the methods from the javax.servlet interfaces then the reflection
will work fine despite what the actual implementation is.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
