Hi Greg,

thanks for the answer. Who casers? Users cares!

Let's imagine that you will modify all the data you are "able" to
modify (as an user of the application) and the the server will
response you, that you are not allowed to modify them! Are you
satisfied with that solution? Is that a common approach?

Isn't that solution that you have client state consistent with your
server implementation cool? Never wanted this kind of solution?
Second thing: what about the session handling in your GWT
applications? What if acris can handle this for you transparently?
And finally: "properly secured server" ... what is that? I can say,
this common approaches are coupled in the acris-security project and
well tested in the real environment.

Do you thing this is not enought?

Peter

On 11. Aug, 23:31 h., Greg Dougherty <[email protected]>
wrote:
> Hi Peter.
>
> Not to be rude, but who cares?
>
> Who cares if the user can see a screen that says "Client Data", when
> the user can't actually download any of that client data?
>
> IOW, what's the point?  If your sever is properly secured, then users
> who aren't allowed to see the client data won't be sent it, and users
> who aren't allowed to modify the data will have their modification
> requests denied.  If it isn't properly secured, then what AcrIS does
> is pointless. no?
>
> Yes, it's nice from the UI perspective to let the user know why they
> can't see / change the data, but what in the world does that have to
> do with "security"?
>
> Greg
>
> On Aug 11, 9:33 am, Peter Simun <[email protected]> wrote:
>
> > Hi Stefan,
>
> > of course, client side code could never be secured! AcrIS security
> > fully depends also on securing the RPC services (on the server side,
> > client side security is an complementary security - some kind of nice
> > to have security)
> > The goal is: if the user does not have rights to see some parts of the
> > screens, it won't be displayed. If the user is not able to modify the
> > data, he will see the readonly components.
> > Anyway, server side security is also checking if the user is able to
> > execute methods or if he is able to modify/see data he are reguesting.
>
> > This coupled approached gives you completly secured solution for GWT
> > applications.
>
> > Peter
>
> > On 11. Aug, 16:07 h., Stefan Bachert <[email protected]> wrote:
>
> > > Hi Peter,
>
> > > I had just a glance at acris.
> > > Acris is talking about a client side part.
>
> > > No mechanism which depends on client side code could be secure!
>
> > > So I would suspect acris to be a misconsception.
> > > At  the moment I do not spend time to exactly find out what is wrong
> > > with acris.
>
> > > Stefan Bacherthttp://gwtworld.de
>
> > > On 11 Aug., 15:47, Peter Simun <[email protected]> wrote:
>
> > > > Luis, why do you think that there is no security there?
>
> > > > Please, read the article again and carefully, or go on the wiki 
> > > > pages:http://code.google.com/p/acris/wiki/Security
>
> > > > Peter
>
> > > > On 11. Aug, 14:04 h., Luis Daniel Mesa Velasquez
>
> > > > <[email protected]> wrote:
> > > > > I don't see anything about the encryption used in the RPC call to the
> > > > > userservice... so it's just a fancy 3rd party RPC call, no security
> > > > > there...
>
> > > > > On Aug 10, 3:20 am, Peter Simun <[email protected]> wrote:
>
> > > > > > Hi all,
>
> > > > > > I just wanted to share with you the article about security in GWT
> > > > > > application.http://java.dzone.com/articles/securing-gwt-client-acris
>
> > > > > > Serious security implementation is something that was missing almost
> > > > > > to each GWT developer. I saw many topics here in the forum about the
> > > > > > security, so maybe it will helps you to implement security in a
> > > > > > correct way.
>
> > > > > > Peter

-- 
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.

Reply via email to