On Friday, May 23, 2014 3:59:35 PM UTC+2, Zied Hamdi OneView wrote: > > Hi, > > I want to talk about GWT authorizations to brainstorm an architecture that > supports it natively. > > It's somehow surprising a framework that is in advance (adopted the Fog > computing more than 5 years ago) doesn't provide a native support for > security routines. Workarounds are naturally possible, but no real core > solution is available, to specify how it should be done according to best > practices and have developers immediately knowing what they do when they > want to implement security in GWT. > > There are some open sources that already propose solutions for this > subject, they or developers who used them are naturally welcome to discuss > the even ad odd points from their feedback. > > Before I started this discussion I made a tour on the available solutions > and I found all what I discovered either too intrusive (imposes its own > architecture that might not be compatible with existing projects), or too > superficial (means there is no central way of doing things). > > With the evolution of IT, many thinkers brought new ways of solving > problems. All problems can't be solved with one only pattern and overusing > a pattern can lead to bad architectures (hardly maintainable code). > > AOP is an example of these best practice ideas that couldn't be overused. > It decomposes a layer (in a n layer architecture) into different logically > splitted layers. In AOP the interceptor knows about his host but the host > doesn't event know the AOP exists. This is a good approach to separate > concerns. The logger, the security some visual adjustments etc... can > intercept the program without this latter knowing about them. > > Another best practice pattern is the single access point: it is somehow > related to the proxying because when all your program flow passes through a > single object/method/facade, it is easy to intercept events and add logic. > > The event oriented programming is a direct iteration on these two > patterns, it states that a shared event bus can make the entire application > connected and make it possible to plug itself on the program without > impacting it. > > I proposed a solution based on this approach to solve the security feature > lack in GWT: an interception entry point to the creation of widgets to > permit plugging into it and doing other interesting things GWT isn't > obliged to be responsible of. > > My proposal is > here<https://code.google.com/p/google-web-toolkit/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars&groupby=&sort=&id=8727> > > https://code.google.com/p/google-web-toolkit/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars&groupby=&sort=&id=8727 > > A > discussion<https://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliY>already > happened in the user forum too about the subject. > > Your ideas and comments are welcome :) >
There's one big flaw with your proposal: it's not really “transparent”; the code “using” it has to know it's there (i.e. it's not AOP as you described it), because some @UiField could be 'null' or not visible (depending on actual implementation). I believe applying such a rule as “this widget might not be created at all” globally might solve some use cases, but opens other issues: e.g. how do I layout my screen depending on what's actually visible? Another rather big issue with the proposal is that it only applies to UiBinder. How do you solve the same problem when you're not using UiBinder? How about navigation in your app? (when you use History.newItem, or Places, or Activities, or a third-party solution such as GWTP – OK, GWTP has its own “security” feature) There's also the question of “what to do?” when a precondition is not met? Should the widget not be created at all? should it be hidden? should it matter to the user of the API? What if I'd prefer that my button be visible but disabled? Last, but not least, having such an API in GWT for widgets but nothing related to communications (GWT-RPC, RequestFactory) is likely to lead to applications that aren't actually secure, because developers have a false sense of security provided by the API that just doesn't create their widgets. So, my advice, as already given elsewhere, is: build what meets your immediate need (either from scratch, or on top of UiBinder, or as a fork of UiBinder), iterate on the API until you're satisfied, then (possibly) iterate again to try to solve other use-cases. If you forked UiBinder, try to come up with an extension API (preferably not extending/reusing the generator, but rather providing extensions to it, similar to how ResourceGenerator and CustomFieldSerializer allow modifying the generator's behavior) on which you could build your security-oriented feature and try to upstream the patch. When and if your library got enough traction, then you can propose it's made part of GWT core (and if the Steering Committee agrees, then you would probably become its maintainer then, responsible for reviewing patches et al.) Also, more technically-speaking, if you can build it as an annotation processor (or possibly another kind of pre-processor) rather than a GWT generator, it could be even better. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9864fb65-def9-49cd-93b0-7e9c287ee1a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
