Hi Greg, why is more acceptable for you, that user will see whole application (also the screen which is not allowed to use) rather than ONLY screens that he is able to use. Your argument becomes to me little bit funny: "tech support and UI nightmare". If you have correctly setup user permissions, then no extra support is necessary and I have no idea which UI nightmare you mean.
Maybe you mean that UI nightmare, that you will have complex application with 50 screen and normal user who is allowed to use only 10 of them will consider your application as UI nightmare - because on 80% of the screen he choose he will gets the message: "You do not have permissions to use this screen, please contact tech support". Ou, and this tech support you mentioned? Yes, with your solution, you will need this kind of tech support and hopefully you will work at first line support and you will tell the users that they are not able to use the 80% of the screens because they are only normal users, not super users. And hopefully you will enjoy the question: "So, why I can see that screens I cannot use?" hmm? And - about the "correct name" - it's security! because acris-security project has much more features than "consistent UI", there is complex session handling, synchronize sessionID between client->server in a completly transparent way, ACL data level security, server side security based on spring security for securing the serivces and complex integration of this stuff into one consistent solution. Peter On 12. Aug, 17:41 h., Greg Dougherty <[email protected]> wrote: > "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.
