"I'm talking about displaying the screens and securing the components."
The problem is that that is a meaningless statement, and to the extent that it's not meaningless, it's pointless. I suppose you could set up your code so that the JS to display a screen isn't downloaded unless the user will be able to use that screen, but why bother? What is the win by doing that? Speaking for myself, I'd MUCH rather have a screen show up, and tell me I can't use it, then not be able to find the screen. After all, if I find the "Update Data" screen, and it says "you do not have permission to use this", then I know I dont' need to look for it anymore. And, if the server has my security credentials wrong, I can call tech support, tell them that, and have them fix it. Calling tech support to tell them I can't find a screen at all is a much different, much more aggravating, call. For both me AND the tech support person. It's not security, it's just a tech support and UI nightmare. Greg On Aug 12, 2:42 am, Peter Simun <[email protected]> wrote: > I'm not talking about the data. Secured data, that user is not allowed > to minupulate with, are not sent to client! This logic is done on the > server side security implementation. > I'm talking about displaying the screens and securing the components: > - like if the user is not able to maintain users, he will not see the > menu item "user maintenance" on the application menu > - if the user is able to view users, but not modify the fields, he > will see the readonly form (just for view purposes) > > Everything just by annotate UI components with @Secured annotation > > Peter > > On 12. Aug, 09:17 h., cokol <[email protected]> wrote: > > > its a way it works, like Greg said - a dumb client should not worry, > > or better said not be too serious about security, everything what > > happens on the client is INSECURE, so the only security concern it > > should think about is to make the security "look good" to its user. > > > the real security should always reside on the backend, client shall > > NEVER get a data from the server for unauthorized user so that client > > can make decisions on its own - either to display the data or not. > > > On 11 Aug., 23:54, Peter Simun <[email protected]> wrote: > > > > 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.
