To top this off, all fields and methods are accessible via reflection, unless 
you are using the tools available in java.security.*.  If there is any code 
running in your JVM that you do not explicitly trust, you may want to look into 
details about this.  The simplest way to bypass encapsulation and set a field 
to whatever you want is set(Object, Object) on java.lang.reflect.Field:
  
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Field.html#set(java.lang.Object,%20java.lang.Object)

There are many valid uses for this.  My favorite is OJB 
(http://db.apache.org/ojb), which runs lightning fast if you'll allow it to 
directly access your fields through reflection.

Just for discussion's sake, I'll take a shot at how to secure the example you 
give below.  

First, you would build a set of authentication tools and have it hand out 
immutable security tokens.  Then, any references to business objects (such as 
BankAccount, below) would be wrapped in a "Proxy" object (See "Design Patterns" 
by Gamma, Helm, Johnson, Vlissides).  When requesting a business object, the 
user would need to pass in his or her security token to a class that was 
responsible for accessing the real business objects.  This class, in return, 
would pass back a Proxy object that contains a reference to the real object.

The proxy object would be responsible for enforcing which security tokens are 
allowed to do what.  For example, neither Joe nor Sally (in the example below) 
would have access to any methods on the other's account.  A bank administrator, 
however, might be granted access to some of the methods.  It would all be up to 
the proxy to decide this.

Lastly, you would want to use the tools in java.security.* to tighten down the 
application.  There are vast volumes of material on using the tools in this 
package.  I think, though, that you would start out by looking at Policy and 
SecureClassLoader.  If you look at the bottom of the package listing for 
java.security.*, Sun has included links to a number of relevant articles on the 
subject:
  http://java.sun.com/j2se/1.4.2/docs/api/java/security/package-summary.html

Hopefully, very few of us will have to deal with running untrusted code within 
the same JVM as code for which security is of great importance.  If you ever 
do, though, there are many tools and design patterns to help you address this.  
Unfortunately (or fortunately, in the case of things like OJB), simply setting 
fields and methods to "private" or "protected" won't do it.  Those modifiers 
are there to aid in writing clean code, rather than being there to secure your 
code.

As always, cheers and happy coding!  These are the kind of puzzles that make 
application design fun :)

Sincerely,
Justis Peters

Richard O. Hammer [EMAIL PROTECTED] wrote:
> In the code which Dogan Atay found (in the earlier thread "computational 
> cost of String comparison"), I was surprised to see that one instance of 
> String could access the private fields of another instance of String. 
> I've always assumed that access modifiers applied to instances, but they 
> apply to classes, as my experiment shows.
> 
> public class BankAccount {
>   private int balance;
>   String owner;
>   BankAccount(String owner, int initialDeposit){
>     this.owner = owner;
>     balance = initialDeposit;
>   }
>   public void helpSomebody(BankAccount other){
>     if (this == other){
>       throw new RuntimeException(
>           "No! You can only change someone else's balance.");
>     }
>     other.balance *= 5;
>   }
>   public String toString(){
>     return owner + " has " + balance;
>   }
> }
> 
> public class Main {
> 
>   public static void main(String[] args){
>     BankAccount sally = new BankAccount("Sally",4);
>     BankAccount joseph = new BankAccount("Joe",17);
>     System.out.println(joseph);
>     sally.helpSomebody(joseph);
>     System.out.println(joseph);
>   }
> }
> 
> Joe has 17
> Joe has 85
> 
> 
> Dogan Atay wrote:
> >    public boolean equals(Object anObject) {
> >        if (this == anObject) {
> >            return true;
> >        }
> >        if (anObject instanceof String) {
> >            String anotherString = (String)anObject;
> >            int n = count;
> >            if (n == anotherString.count) {
> >                char v1[] = value;
> >                char v2[] = anotherString.value;
> >                int i = offset;
> >                int j = anotherString.offset;
> >                while (n-- != 0) {
> >                    if (v1[i++] != v2[j++])
> >                        return false;
> >                }
> >                return true;
> >            }
> >        }
> >        return false;
> >    }
> 
> _______________________________________________
> Juglist mailing list
> [EMAIL PROTECTED]
> http://trijug.org/mailman/listinfo/juglist_trijug.org

_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://trijug.org/mailman/listinfo/juglist_trijug.org

Reply via email to