The idea behind security is simple, trust no one and trust nothing... only
when who ever tries to access and authenticates them self and
is authorized to access what ever it is the are attempting to access allow
this action.
So try and hide anything that a user should not have access to. This will
Agreed! Don't show the button if the user doesn't have permissions. But also
check perms on the server to protect against hackers.
/dmc
On Fri, Jul 8, 2011 at 2:54 PM, Alberto Sarubbi wrote:
> we actually protect EVERY call to our server validating the user
> rights before proceeding to the ser
we actually protect EVERY call to our server validating the user
rights before proceeding to the service execution.
it just doesn't seem right to show a user a button that he can't click
because he don't have the permission to do.
it sounds more logical not showing the button at all.
of course, va
In protecting the data as David rightly suggests, you can protect the UI by
returning SC_UNAUTHORIZED if an unauthenticated user attempts to access any
remote service. I've overridden the RequestFactory onResponseReceived
function which redirects to a login page if the response is SC_UNAUTHORIZE
Agreed. What the client sends to the server can be the wild west. Never
trust it.
My recipe, YMMV, but my apps hide display of access limited objects on the
client side(all are there in the js) but more to avoid confusion to users
than as a security measure. The real security is on the serve
In order to write a secure rich Web app, you need to think in terms of
protecting the data, not the UI itself. This is true for any JS
application, not just GWT.
/dmc
On Fri, Jul 8, 2011 at 9:44 AM, Alberto Sarubbi wrote:
> looks to me like a dead end for developing security sensitive UI with
>
looks to me like a dead end for developing security sensitive UI with
GWT.
thank you Robert.
--
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 thi
> 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 a
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 (apac