Re: show/hide widget based on user's credentials
2 solutions: * 2 gwt applications user and admin (you could use a custom properties/permutation). * 1 gwt application and applicative (if(userInRole(admin)) customization. HIH On Tue, Jun 23, 2009 at 2:28 PM, ailinykh ailin...@gmail.com wrote: Hello, everybody! I have a widget (Tab in TabPanel, for example) which is dedicated to some administrative tasks. Only administrator is supposed to use it. I don't want to bother everyone by this widget, I want to show it only if user logged in as Administrator. What is the best way to implement it? Thnak you, Andrey -- “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” Sir Charles Anthony Richard Hoare --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: show/hide widget based on user's credentials
Thank you! I'm thinking about second solution. It brings up next question- how to get user role on client side? Right now I see only one way - ask the server through RPC. Does GWT provide any session management? Thank you, Andrey On Jun 23, 7:34 am, olivier nouguier olivier.nougu...@gmail.com wrote: 2 solutions: * 2 gwt applications user and admin (you could use a custom properties/permutation). * 1 gwt application and applicative (if(userInRole(admin)) customization. HIH On Tue, Jun 23, 2009 at 2:28 PM, ailinykh ailin...@gmail.com wrote: Hello, everybody! I have a widget (Tab in TabPanel, for example) which is dedicated to some administrative tasks. Only administrator is supposed to use it. I don't want to bother everyone by this widget, I want to show it only if user logged in as Administrator. What is the best way to implement it? Thnak you, Andrey -- “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” Sir Charles Anthony Richard Hoare --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: show/hide widget based on user's credentials
On Tue, Jun 23, 2009 at 5:04 PM, ailinykh ailin...@gmail.com wrote: Thank you! I'm thinking about second solution. It brings up next question- how to get user role on client side? Right now I see only one way - ask the server through RPC. Does GWT provide any session management? Nope for client side GWT. Server side provide a thread localized request accessor, which give you access to sevlet session. You should, use a standard authen/autho (basic|form), then 2 choices (again:): * a service might expose the granted authorities to GWT client. * in the hosting page you can write some js variable who contains the granted authorities. Thank you, Andrey On Jun 23, 7:34 am, olivier nouguier olivier.nougu...@gmail.com wrote: 2 solutions: * 2 gwt applications user and admin (you could use a custom properties/permutation). * 1 gwt application and applicative (if(userInRole(admin)) customization. HIH On Tue, Jun 23, 2009 at 2:28 PM, ailinykh ailin...@gmail.com wrote: Hello, everybody! I have a widget (Tab in TabPanel, for example) which is dedicated to some administrative tasks. Only administrator is supposed to use it. I don't want to bother everyone by this widget, I want to show it only if user logged in as Administrator. What is the best way to implement it? Thnak you, Andrey -- “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” Sir Charles Anthony Richard Hoare -- “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” Sir Charles Anthony Richard Hoare --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: show/hide widget based on user's credentials
I see. How do you check user permissions on server side? Andrey On Jun 23, 2:47 pm, Chad chad...@gmail.com wrote: Andrey, RPC is the way I do it. I have a User object that can be passed between the client and server. It's kept on the client after login so the entire UI can easily refer to it. My security scheme contains roles that are a collection of rights. On the server side, at the time of login, the roles and rights are retrieved from the database for the user and added to the user object. The user object is only retrieved from the server once since it is not stored anywhere (other than in memory) on the client side. When the app is first entered, the user object won't exist and therefore require a login. On the client side, the UI can use the existence (or non-existence) of rights to determine what to display: --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: show/hide widget based on user's credentials
Permissions aren't really checked on the server. I have tables in a database for users, roles, and rights. And I have tables that link them together users_roles and roles_rights. When the user logs in, and authentication is complete, the user data is retrieved along with the roles the user belongs to and the rights that belong to each role. The roles and rights are added to the user and sent back to the client. From that point on, the application can just query the user object for everything that it needs to know about the user. HTH, Chad On Jun 23, 3:28 pm, ailinykh ailin...@gmail.com wrote: I see. How do you check user permissions on server side? Andrey On Jun 23, 2:47 pm, Chad chad...@gmail.com wrote: Andrey, RPC is the way I do it. I have a User object that can be passed between the client and server. It's kept on the client after login so the entire UI can easily refer to it. My security scheme contains roles that are a collection of rights. On the server side, at the time of login, the roles and rights are retrieved from the database for the user and added to the user object. The user object is only retrieved from the server once since it is not stored anywhere (other than in memory) on the client side. When the app is first entered, the user object won't exist and therefore require a login. On the client side, the UI can use the existence (or non-existence) of rights to determine what to display: --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: show/hide widget based on user's credentials
I understand that. But you can't trust the client. If someone who has read only access tries to write, server has to reject such request. In other words how do you implement authorization? Thank you, Andrey On Jun 23, 4:42 pm, Chad chad...@gmail.com wrote: Permissions aren't really checked on the server. I have tables in a database for users, roles, and rights. And I have tables that link them together users_roles and roles_rights. When the user logs in, and authentication is complete, the user data is retrieved along with the roles the user belongs to and the rights that belong to each role. The roles and rights are added to the user and sent back to the client. From that point on, the application can just query the user object for everything that it needs to know about the user. HTH, Chad On Jun 23, 3:28 pm, ailinykh ailin...@gmail.com wrote: I see. How do you check user permissions on server side? Andrey On Jun 23, 2:47 pm, Chad chad...@gmail.com wrote: Andrey, RPC is the way I do it. I have a User object that can be passed between the client and server. It's kept on the client after login so the entire UI can easily refer to it. My security scheme contains roles that are a collection of rights. On the server side, at the time of login, the roles and rights are retrieved from the database for the user and added to the user object. The user object is only retrieved from the server once since it is not stored anywhere (other than in memory) on the client side. When the app is first entered, the user object won't exist and therefore require a login. On the client side, the UI can use the existence (or non-existence) of rights to determine what to display: --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: show/hide widget based on user's credentials
Well, my current application is an intranet application and uses NTLM authentication and that's what I was referring to. It's constantly authenticating the user I believe. On internet apps (and even some intranet apps), I generate a session id on the server side (something like a guid from the database), and store it in the user object and a session table in the database. Then, with all requests, I pass either the session id or the user object to the server with the request (depending on what data is needed for the request). The server will check the session table to make sure the session id is valid. I also sometimes store this session id in a cookie valid for a couple weeks to allow user's to stay logged in in some apps. If I'm not mistaken (which I very well may be), aren't these methods secure? I grant you, I'm by no means a security expert. Chad On Jun 23, 5:55 pm, ailinykh ailin...@gmail.com wrote: I understand that. But you can't trust the client. If someone who has read only access tries to write, server has to reject such request. In other words how do you implement authorization? Thank you, Andrey On Jun 23, 4:42 pm, Chad chad...@gmail.com wrote: Permissions aren't really checked on the server. I have tables in a database for users, roles, and rights. And I have tables that link them together users_roles and roles_rights. When the user logs in, and authentication is complete, the user data is retrieved along with the roles the user belongs to and the rights that belong to each role. The roles and rights are added to the user and sent back to the client. From that point on, the application can just query the user object for everything that it needs to know about the user. HTH, Chad On Jun 23, 3:28 pm, ailinykh ailin...@gmail.com wrote: I see. How do you check user permissions on server side? Andrey On Jun 23, 2:47 pm, Chad chad...@gmail.com wrote: Andrey, RPC is the way I do it. I have a User object that can be passed between the client and server. It's kept on the client after login so the entire UI can easily refer to it. My security scheme contains roles that are a collection of rights. On the server side, at the time of login, the roles and rights are retrieved from the database for the user and added to the user object. The user object is only retrieved from the server once since it is not stored anywhere (other than in memory) on the client side. When the app is first entered, the user object won't exist and therefore require a login. On the client side, the UI can use the existence (or non-existence) of rights to determine what to display: --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: show/hide widget based on user's credentials
You CAN'T trust the client, anyone skilled enough can hack the JS to display the widget, or subvert any in memory objects. To summarize the best I can, first you MUST check permissions of RPC on the server side. You can use the J2EE roles, but I found that hard to make very dynamic, it's a Pain, really. I store a users Access Rules in a Database, In order to not fall into the many many problems of storing too much data in the Session scope, I store them in the Application scope in a map based on userid. (There are possibly dozens, or hundreds per user, right down to individually licensed data- sets ). I populate the map when they sign in, and clear via a SessionListener when they sign out or the session expires ). There is a simple way to query the Access Rules that is very fast. Now, may try to use a Servlet Filter to check the user ID, but thats nasty to map to individual RPC calls, or to return a proper Throwable via RPC. So, to make a long story short, I overloaded RemoteServiceServlet, specifically processCall(), more specifically, I copied the code into my subclass and modified it so that, from the RPCRequest I could get the Method, and on the Methods, I placed custom Annotations that enumerated the Access Rules there, processCall() then got the Annotations from the Method, and checked it against the in memory Rules for the user. It's relatively easy to throw back a proper Exception from processCall() also. You can log the Method name here too, for usage stats. I'm sure you can use things like Spring AOP, but that got sloppy fast, too much configuration for my taste, and hard to fit in with returning Permission Denied kind of exceptions. Each Screen in the app is associated with a token ( the app is Token History Driven ), and when a Screen is created, I do an RPC call, passing the token. The token must be in the Access Rules list, each token is associated with a map of properties that is returned for that users Access Rule Set. The map is consulted when adding certain permissioned components, but I do not store that in memory, to reduce the attack surface. The extra RPC call takes a small amount of time, but it also is a good place for us to log more usage stats, which I had to do anyway... Creating 2 compile permutations, Admin and Non-Admin is helpful ONLY because it reduces the size of the app for non-admin users, not much for safety if you do not somehow protect access to the admin version of the Bootstrap JS. It's trivial if you know it's path to subvert the HTML stream to load it instead. There are many ways to get around this stuff... enough to make you paranoid. I would even create two DB connection pools, with different DB id's, and restrict table access on the Administrative Tables to only the Admin Pool, and get connections from the Admin Pool only for Admin users. Also, we use IP subnet filtering, people we give Admin access to are required to give us their IP ranges. AND, Admin changes do not go live immediately, they get queued and ANOTHER Admin has to approve them. I'm sure there are things I haven't thought of. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: show/hide widget based on user's credentials
This is correct, the RPC must also verify user permissions. The easiest way to do this is to keep the 'user validation/permission' code the same on the client and on the server. This can easily be accomplished in GWT since the client code is Java compiled to JavaScript. BTW, you should be doing the same with your input validation code. In my applications we give the client the user's roles and it uses them to decide which parts of the application the user can access. However, ALL RPCs are subject to the same checks so some clever guy cannot just reverse engineer the javascript RPCs and call methods without having any real roles. On Jun 23, 6:55 pm, ailinykh ailin...@gmail.com wrote: I understand that. But you can't trust the client. If someone who has read only access tries to write, server has to reject such request. In other words how do you implement authorization? Thank you, Andrey On Jun 23, 4:42 pm, Chad chad...@gmail.com wrote: Permissions aren't really checked on the server. I have tables in a database for users, roles, and rights. And I have tables that link them together users_roles and roles_rights. When the user logs in, and authentication is complete, the user data is retrieved along with the roles the user belongs to and the rights that belong to each role. The roles and rights are added to the user and sent back to the client. From that point on, the application can just query the user object for everything that it needs to know about the user. HTH, Chad On Jun 23, 3:28 pm, ailinykh ailin...@gmail.com wrote: I see. How do you check user permissions on server side? Andrey On Jun 23, 2:47 pm, Chad chad...@gmail.com wrote: Andrey, RPC is the way I do it. I have a User object that can be passed between the client and server. It's kept on the client after login so the entire UI can easily refer to it. My security scheme contains roles that are a collection of rights. On the server side, at the time of login, the roles and rights are retrieved from the database for the user and added to the user object. The user object is only retrieved from the server once since it is not stored anywhere (other than in memory) on the client side. When the app is first entered, the user object won't exist and therefore require a login. On the client side, the UI can use the existence (or non-existence) of rights to determine what to display: --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
