Thanks for the response. I will try it out.... - Harjit
On May 19, 6:13 pm, Alyxandor <[email protected]> wrote: > It depends on how secure you want to be. > > If you aren't dealing with sensitive information, build one module > that using an internal boolean value to determine how to run depending > on authentication, and set that value using rpc or cookies, or however > you do your authentication. > > If you want the more secure method, define a property, user.auth, and > split your code with deferred binding so you can have two seperate > versions... > > <define-property name="user.auth" values="yes.no"/> > > <property-provider name="user.auth"><![CDATA[ > if (testAuthentication()) > return "yes"; > else > return "no"; > ]]></property-provider> > > <replace-with class='com.example.client.Authorized'> > <when-type-is class='com.example.client.IsAuthorized/> > <any> > <when-property-is name="user.auth" value="yes" /> > </any> > </replace-with> > > Then, make class IsAuthorized{ > private static final IsAuthorized xINST = GWT.create > (IsAuthorized.class); > public boolean xAuth(){return false;} > public static boolean authorized(){return xINST.xAuth();}} > > and class Authorized extends IsAuthorized{ > @Override > public boolean xAuth(){return true;} > > } > > Then, in the rest of you module, code can be split with: > if (IsAuthorized.authorized()){ > //All this code will only be compiled for logged in users} > > else{ > //This code is for everyone else > > } > > The only thing you need to do is implement the testAuthorized() > function in the property provider; it is called in your .nocache.js > file, so don't try using any GWT stuff there. Do a cookie check or > whatever you do normally to test authentication. > > The only issue here is download times... Users have to redownload the > same module twice before and after they login, but it WILL keep > sensitive methods away from hackers. Of course, with -style "OBF", > your code is basically impossible to understand without some kind of > method-detection urchin; but such software DOES exist, and if you're > going to deal with phone numbers or credit cards, you probably should > have seperate builds for login-state. > > If you don't have authentication methods yet, try google appengine. > > Note, this WILL double your compile time, unless you do build- > targetting with <set-property name="user.auth" value="yes"/> to test > authenticated builds, and value="no" to test non-auth builds. On that > note, in case you don't already know, use <set-property > name="user.agent" value="gecko1_8"/> to target one browser at a time; > it'll also cut your build time significantly {my production build has > 33 permutations, but my test builds only get 2-4 at a time...} --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
