Re: How to handle application state ?
what about security implication of storing the info on the client ? I think, if you are dealing with Role-Based Security/Access Control List (ACL)/ Authorization, everytime user goes to a new place, you need a server call to check on the server whether the user is authorized to view a given screen. I think somewhere in the ActivityMapper, when mapping a place to activity, the authorization check (a call to the server) should be performed. username.isAuthorizedtoEdit(object) a check to see whether a user has a permission to do certain operation on a certain object, through a server call, before presenting user with a new screen. GWT generates Javascript, and all the code you write in Java, end up as Javascript in client. malicious users can use the client-side javascript to attack. You need a server call, EVERYTIME user needs to see a new screen/ goes to a new place, to check for permissions. you can use a Cache on the server to store this information. like Ehcache/MemCache. you populate this cache once the user logs in, and use it for subsequent calls, to avoid database roundtrip. I would like to know what the community thinks of this approach, and what is the preferred way for dealing with Role-Based-Security, in GWT MVP framework. I understand it is essential to be checked on the server, but would like to know the best practice to integrate the serverside security with gwt-mvp. -- 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-tool...@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: How to handle application state ?
The same security implications that exist on the server also exist on the client so sound judgment should always be exercised such as using client side encryption for high security concerns and only passing sensitive data that is encrypted over the wire, etc. A hacker committed to getting access to your data will succeed no matter what you do so you can only provide multiple levels of security in the hope that they will move on to easier prey but you can never really guarantee that your application is 100% secure. Take Google, for instance, who just recently fell victim to the Chinese who hacked into their systems stealing the personal information of those whom they deemed as threats to their continued enslavement of their own people. Do you think Google didn't have multiple levels of deterrence in place and was that enough to prevent the scoundrels from stealing the data? Of course they did and as we have seen, it wasn't enough to deter the criminals from hacking into their system. Regarding the use of ACL and it forcing a call back to the server to validate a user's authorization and privileges, I don't believe that is true. I think, however, that if I were designing an application that used ACL I would architect it in a way that allowed me not to have to do that. If there is something about ACL that didn't allow me to get around that then I would either not use it or I would chose another platform to implement it on. Remember, there's no substitute for sound judgment and proper design. Even encrypted data can be broken by a dedicated and committed hacker. Even giants in the industry have had their data stolen. Concluding that you application is 100% secure just because you use sound practices is not enough in this day and age. Jeff On Tue, Dec 7, 2010 at 3:09 AM, metalhammer29a metalhammer...@gmail.comwrote: what about security implication of storing the info on the client ? I think, if you are dealing with Role-Based Security/Access Control List (ACL)/ Authorization, everytime user goes to a new place, you need a server call to check on the server whether the user is authorized to view a given screen. I think somewhere in the ActivityMapper, when mapping a place to activity, the authorization check (a call to the server) should be performed. username.isAuthorizedtoEdit(object) a check to see whether a user has a permission to do certain operation on a certain object, through a server call, before presenting user with a new screen. GWT generates Javascript, and all the code you write in Java, end up as Javascript in client. malicious users can use the client-side javascript to attack. You need a server call, EVERYTIME user needs to see a new screen/ goes to a new place, to check for permissions. you can use a Cache on the server to store this information. like Ehcache/MemCache. you populate this cache once the user logs in, and use it for subsequent calls, to avoid database roundtrip. I would like to know what the community thinks of this approach, and what is the preferred way for dealing with Role-Based-Security, in GWT MVP framework. I understand it is essential to be checked on the server, but would like to know the best practice to integrate the serverside security with gwt-mvp. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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-tool...@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.
How to handle application state ?
Here's the use case we are dealing with, SSO token shall be received by GWT application. SSO token shall have user profile and role information. Once I have read SSO token, I would like to use User Profile information to be available in header page and Role information in navigation page to control who see's what in terms of functionality (tabs). How do I store or hold token information as an application state ? - Mittal -- 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-tool...@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: How to handle application state ?
In your case the state you want to preserve seems to be associated with a particular user, not the application, so you can use either cookies or servlet session state to persist the information when the user logs in and you can then query the information when displaying tabs or reacting to other user interface events. Jeff On Mon, Dec 6, 2010 at 9:39 AM, Mittal mitt...@gmail.com wrote: Here's the use case we are dealing with, SSO token shall be received by GWT application. SSO token shall have user profile and role information. Once I have read SSO token, I would like to use User Profile information to be available in header page and Role information in navigation page to control who see's what in terms of functionality (tabs). How do I store or hold token information as an application state ? - Mittal -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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-tool...@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: How to handle application state ?
Yes, its application state for a User. Why do I need to query server information every time for a user, I think I should able to create client side object such as UserProfile, populate it from server side once user logs in and then pass client side UserProfile object where its required such as Header or Navigation pages. - Mittal On Dec 6, 9:47 am, Jeff Schwartz jefftschwa...@gmail.com wrote: In your case the state you want to preserve seems to be associated with a particular user, not the application, so you can use either cookies or servlet session state to persist the information when the user logs in and you can then query the information when displaying tabs or reacting to other user interface events. Jeff On Mon, Dec 6, 2010 at 9:39 AM, Mittal mitt...@gmail.com wrote: Here's the use case we are dealing with, SSO token shall be received by GWT application. SSO token shall have user profile and role information. Once I have read SSO token, I would like to use User Profile information to be available in header page and Role information in navigation page to control who see's what in terms of functionality (tabs). How do I store or hold token information as an application state ? - Mittal -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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-tool...@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: How to handle application state ?
You shouldn't have to query for the information more than once but you do need to store it some place and like I said, you have several options. If you want to store it on the client and have the information persist even after the user closes the browser (across sessions) then you can use cookies. But first you need to get the data to the client. If I were coding this I'd define a serializable class in a shared gwt folder that matches the data model for the information that I want to bring down and use on the client. I'd then create a remote service (such as a GWT RemoteService) that on the server queries for the data and outputs the data to the data structure I defined in the shared folder as per the above and which then returns an instance of that class to the client. The client, upon receiving the result back from the server, would store the result in a HashMap for in some other data structure I designed to store data on the client or in cookies if I wanted to use the information across sessions. You have lots of options but they all follow a similar pattern to the above. Jeff On Mon, Dec 6, 2010 at 10:52 AM, Mittal mitt...@gmail.com wrote: Yes, its application state for a User. Why do I need to query server information every time for a user, I think I should able to create client side object such as UserProfile, populate it from server side once user logs in and then pass client side UserProfile object where its required such as Header or Navigation pages. - Mittal On Dec 6, 9:47 am, Jeff Schwartz jefftschwa...@gmail.com wrote: In your case the state you want to preserve seems to be associated with a particular user, not the application, so you can use either cookies or servlet session state to persist the information when the user logs in and you can then query the information when displaying tabs or reacting to other user interface events. Jeff On Mon, Dec 6, 2010 at 9:39 AM, Mittal mitt...@gmail.com wrote: Here's the use case we are dealing with, SSO token shall be received by GWT application. SSO token shall have user profile and role information. Once I have read SSO token, I would like to use User Profile information to be available in header page and Role information in navigation page to control who see's what in terms of functionality (tabs). How do I store or hold token information as an application state ? - Mittal -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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-tool...@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: How to handle application state ?
Mittal, by query, I believe Jeff means retrieve the user information from wherever you stored after the initial server retrieval: the cookie or the Session/Servlet state. On Mon, Dec 6, 2010 at 7:52 AM, Mittal mitt...@gmail.com wrote: Yes, its application state for a User. Why do I need to query server information every time for a user, I think I should able to create client side object such as UserProfile, populate it from server side once user logs in and then pass client side UserProfile object where its required such as Header or Navigation pages. - Mittal On Dec 6, 9:47 am, Jeff Schwartz jefftschwa...@gmail.com wrote: In your case the state you want to preserve seems to be associated with a particular user, not the application, so you can use either cookies or servlet session state to persist the information when the user logs in and you can then query the information when displaying tabs or reacting to other user interface events. Jeff On Mon, Dec 6, 2010 at 9:39 AM, Mittal mitt...@gmail.com wrote: Here's the use case we are dealing with, SSO token shall be received by GWT application. SSO token shall have user profile and role information. Once I have read SSO token, I would like to use User Profile information to be available in header page and Role information in navigation page to control who see's what in terms of functionality (tabs). How do I store or hold token information as an application state ? - Mittal -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- 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-tool...@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: How to handle application state ?
Jeff, I agree on creating a share object and storing into HashMap on client side. But how do I share this HashMap on client side among different screens such as Header, Navigation etc. (Other than passing HashMap to these screens via some setter methods) Mittal On Dec 6, 11:23 am, Jeff Schwartz jefftschwa...@gmail.com wrote: You shouldn't have to query for the information more than once but you do need to store it some place and like I said, you have several options. If you want to store it on the client and have the information persist even after the user closes the browser (across sessions) then you can use cookies. But first you need to get the data to the client. If I were coding this I'd define a serializable class in a shared gwt folder that matches the data model for the information that I want to bring down and use on the client. I'd then create a remote service (such as a GWT RemoteService) that on the server queries for the data and outputs the data to the data structure I defined in the shared folder as per the above and which then returns an instance of that class to the client. The client, upon receiving the result back from the server, would store the result in a HashMap for in some other data structure I designed to store data on the client or in cookies if I wanted to use the information across sessions. You have lots of options but they all follow a similar pattern to the above. Jeff On Mon, Dec 6, 2010 at 10:52 AM, Mittal mitt...@gmail.com wrote: Yes, its application state for a User. Why do I need to query server information every time for a user, I think I should able to create client side object such as UserProfile, populate it from server side once user logs in and then pass client side UserProfile object where its required such as Header or Navigation pages. - Mittal On Dec 6, 9:47 am, Jeff Schwartz jefftschwa...@gmail.com wrote: In your case the state you want to preserve seems to be associated with a particular user, not the application, so you can use either cookies or servlet session state to persist the information when the user logs in and you can then query the information when displaying tabs or reacting to other user interface events. Jeff On Mon, Dec 6, 2010 at 9:39 AM, Mittal mitt...@gmail.com wrote: Here's the use case we are dealing with, SSO token shall be received by GWT application. SSO token shall have user profile and role information. Once I have read SSO token, I would like to use User Profile information to be available in header page and Role information in navigation page to control who see's what in terms of functionality (tabs). How do I store or hold token information as an application state ? - Mittal -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- *Jeff Schwartz* -- 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-tool...@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: How to handle application state ?
This is what I write in all my GWT applications when I need a client-side
cache:
import java.util.HashMap;
public class MyCache {
HashMapString, Object hashMap = new HashMapString, Object();
// singleton
private static MyCache instance = null;
private MyCache(){}
/**
* @return instance.hashMap
*/
// singleton
public static HashMapString, Object getCache() {
if(instance == null){
instance = new MyCache();
}
return instance.hashMap;
}
}
The above class is a singleton and has a factory method getCache().
And this is how I use it:
MyCache.getCache.put(Account,account);
.
.
.
Account account = (Account) MyCache.getCache().get(Account);
Feel free to use it in your applications.
Jeff
On Mon, Dec 6, 2010 at 6:38 PM, Mittal mitt...@gmail.com wrote:
Jeff,
I agree on creating a share object and storing into HashMap on client
side. But how do I share this HashMap on client side among different
screens such as Header, Navigation etc. (Other than passing HashMap
to these screens via some setter methods)
Mittal
On Dec 6, 11:23 am, Jeff Schwartz jefftschwa...@gmail.com wrote:
You shouldn't have to query for the information more than once but you do
need to store it some place and like I said, you have several options. If
you want to store it on the client and have the information persist even
after the user closes the browser (across sessions) then you can use
cookies. But first you need to get the data to the client.
If I were coding this I'd define a serializable class in a shared gwt
folder
that matches the data model for the information that I want to bring down
and use on the client. I'd then create a remote service (such as a GWT
RemoteService) that on the server queries for the data and outputs the
data
to the data structure I defined in the shared folder as per the above and
which then returns an instance of that class to the client. The client,
upon
receiving the result back from the server, would store the result in a
HashMap for in some other data structure I designed to store data on the
client or in cookies if I wanted to use the information across sessions.
You have lots of options but they all follow a similar pattern to the
above.
Jeff
On Mon, Dec 6, 2010 at 10:52 AM, Mittal mitt...@gmail.com wrote:
Yes, its application state for a User. Why do I need to query server
information every time for a user, I think I should able to create
client side object such as UserProfile, populate it from server side
once user logs in and then pass client side UserProfile object where
its required such as Header or Navigation pages.
- Mittal
On Dec 6, 9:47 am, Jeff Schwartz jefftschwa...@gmail.com wrote:
In your case the state you want to preserve seems to be associated
with a
particular user, not the application, so you can use either cookies
or
servlet session state to persist the information when the user logs
in
and
you can then query the information when displaying tabs or reacting
to
other
user interface events.
Jeff
On Mon, Dec 6, 2010 at 9:39 AM, Mittal mitt...@gmail.com wrote:
Here's the use case we are dealing with,
SSO token shall be received by GWT application.
SSO token shall have user profile and role information.
Once I have read SSO token, I would like to use User Profile
information to be available in header page and Role information in
navigation page to control who see's what in terms of functionality
(tabs).
How do I store or hold token information as an application state ?
- Mittal
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com
google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com
google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com
google-web-toolkit%252bunsubscr...@googlegroups.comgoogle-web-toolkit%25252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
--
*Jeff Schwartz*
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com
google-web-toolkit%2bunsubscr...@googlegroups.comgoogle-web-toolkit%252bunsubscr...@googlegroups.com
.
For more
