Yoav Shapira wrote:
Hi,
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.
Introspection will allow direct access to the field (even if it's
private/protected), which is the main issue. In that case, there's a
permission check. So this would need some thought, and is a bit more
complicated than simply "change the package" (overall, I still think
it's not legitimate, though).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
