> wouldn't the security constraint container be available to a
> DOM inspector for analysis? some kind of a BIG HOLE in security?

Yes.  And it is also trivial to take your obfuscated code and de-obfuscate
it.  So assume that anyone that can download your JavaScript code can read
it and change it as they like.

The only real security you can have is on the server.  On the client the
best you can do is obfuscate it and hope the user isn't a coder.

So, perhaps you need to rethink your strategy.  Perhaps one solution is to
have multiple modules, and secure the JS code on the server.  This will
though increase the total size of the app.  You could potentially do the
same thing with split points (instead of multiple apps), but the file names
of split points change each time you compile, so it would be difficult to
lock the JS code down that way.

Rob


On Thu, Jul 7, 2011 at 2:40 PM, Alberto Sarubbi <asaru...@gmail.com> wrote:

> hi there, i'm developing an application that came into a common use
> case when HTML is generated from server side, which is whether to
> include or not an element in the output based on security constraints
> applicable for the current user only.
>
> some security frameworks, like the one we're using (apache shiro),
> provides special jsp / gsp tags to achieve this, like
> <g:hasPermission("somekey">.... then render component.
>
> can you point me some patterns or information to achieve the same
> thing with GWT?
>
> my first approach was to use the constructor of a composite with a
> security constraint container, so i can do the typical question:
>
> if (securityContainer.hasPermission()) {
>  add or show o enable the button.....
> } else {
> //no button to push
> }
>
> being the security constraint container a simple JSObject obtained
> from the server with an rpc service.
> and only when it is available, the widgets are creted.
>
> but this is not only a bad solution, in terms of coding standards but
> also brings a question: wouldn't the security constraint container be
> available to a DOM inspector for analysis? some kind of a BIG HOLE in
> security?
>
> i know i can create a secure version of every widget i need to
> protect, but, the security constraints problem is the same.
>
> any ideas would be appreciated.
>
> thanks in advance.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to