[gwt-contrib] Re: Native Authorization in GWT
Hi Thomas, I decided to put the library as you suggested in a separate project, and to make it evolve to a state where it can be presented as an alternative to UiBinder. Here's the link, all unit tests pass. If any body wants to contribute, you're welcome https://code.google.com/p/ui-binder-factory-proxy/ Le vendredi 23 mai 2014 14:59:35 UTC+1, Zied Hamdi OneView a écrit : 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 herehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 https://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 A discussionhttps://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliYalready happened in the user forum too about the subject. Your ideas and comments are welcome :) -- 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/95ae19ac-c132-4938-87ba-dab37d5c1796%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
I created an issuehttps://code.google.com/p/google-web-toolkit/issues/detail?id=8735where I specify more clearly the change proposal: https://code.google.com/p/google-web-toolkit/issues/detail?id=8735 I'm getting this message: I'm just unable to push the code for review Tue May 27 12:28:27 2014 Pushing to https://gwt.googlesource.com/gwt POST git-receive-pack (24854 bytes) remote: Resolving deltas: 2% (1/34) remote: Resolving deltas: 5% (2/34) remote: Resolving deltas: 8% (3/34) remote: Resolving deltas: 11% (4/34) remote: Resolving deltas: 14% (5/34) remote: Resolving deltas: 17% (6/34) remote: Resolving deltas: 20% (7/34) remote: Resolving deltas: 23% (8/34) remote: Resolving deltas: 26% (9/34) remote: Resolving deltas: 29% (10/34) remote: Resolving deltas: 32% (11/34) remote: Resolving deltas: 35% (12/34) remote: Resolving deltas: 38% (13/34) remote: Resolving deltas: 41% (14/34) remote: Resolving deltas: 44% (15/34) remote: Resolving deltas: 47% (16/34) remote: Resolving deltas: 50% (17/34) remote: Resolving deltas: 52% (18/34) remote: Resolving deltas: 55% (19/34) remote: Resolving deltas: 58% (20/34) remote: Resolving deltas: 61% (21/34) remote: Resolving deltas: 64% (22/34) remote: Resolving deltas: 67% (23/34) remote: Resolving deltas: 70% (24/34) remote: Resolving deltas: 73% (25/34) remote: Resolving deltas: 76% (26/34) remote: Resolving deltas: 79% (27/34) remote: Resolving deltas: 82% (28/34) remote: Resolving deltas: 85% (29/34) remote: Resolving deltas: 88% (30/34) remote: Resolving deltas: 91% (31/34) remote: Resolving deltas: 94% (32/34) remote: Resolving deltas: 97% (33/34) remote: Resolving deltas: 100% (34/34) remote: Resolving deltas: 100% (34/34) remote: remote: Processing changes: refs: 1 remote: Processing changes: refs: 1, done To https://gwt.googlesource.com/gwt ! [remote rejected] uibinderfactory - master (prohibited by Gerrit) error: failed to push some refs to 'https://gwt.googlesource.com/gwt' -- 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/3a667318-c74a-4178-bec7-62165643293e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
You have to push to the special reference refs/for/master to create a review to be merged to the 'master' branch. git push origin HEAD:refs/for/master (replace HEAD with a local branch if you don't want to push the current commit but another reference/commit) Note, you also have to install the hook that will generate the Change-Id line on commit; see http://www.gwtproject.org/makinggwtbetter.html#submittingpatches If you hadn't installed it already, just amend your commit and the hook will run and modify your commit message appropriately. Also keep in mind that 1 commit == 1 review ! On Tuesday, May 27, 2014 1:32:35 PM UTC+2, Zied Hamdi OneView wrote: I created an issuehttps://code.google.com/p/google-web-toolkit/issues/detail?id=8735where I specify more clearly the change proposal: https://code.google.com/p/google-web-toolkit/issues/detail?id=8735 I'm getting this message: I'm just unable to push the code for review Tue May 27 12:28:27 2014 Pushing to https://gwt.googlesource.com/gwt POST git-receive-pack (24854 bytes) remote: Resolving deltas: 2% (1/34) remote: Resolving deltas: 5% (2/34) remote: Resolving deltas: 8% (3/34) remote: Resolving deltas: 11% (4/34) remote: Resolving deltas: 14% (5/34) remote: Resolving deltas: 17% (6/34) remote: Resolving deltas: 20% (7/34) remote: Resolving deltas: 23% (8/34) remote: Resolving deltas: 26% (9/34) remote: Resolving deltas: 29% (10/34) remote: Resolving deltas: 32% (11/34) remote: Resolving deltas: 35% (12/34) remote: Resolving deltas: 38% (13/34) remote: Resolving deltas: 41% (14/34) remote: Resolving deltas: 44% (15/34) remote: Resolving deltas: 47% (16/34) remote: Resolving deltas: 50% (17/34) remote: Resolving deltas: 52% (18/34) remote: Resolving deltas: 55% (19/34) remote: Resolving deltas: 58% (20/34) remote: Resolving deltas: 61% (21/34) remote: Resolving deltas: 64% (22/34) remote: Resolving deltas: 67% (23/34) remote: Resolving deltas: 70% (24/34) remote: Resolving deltas: 73% (25/34) remote: Resolving deltas: 76% (26/34) remote: Resolving deltas: 79% (27/34) remote: Resolving deltas: 82% (28/34) remote: Resolving deltas: 85% (29/34) remote: Resolving deltas: 88% (30/34) remote: Resolving deltas: 91% (31/34) remote: Resolving deltas: 94% (32/34) remote: Resolving deltas: 97% (33/34) remote: Resolving deltas: 100% (34/34) remote: Resolving deltas: 100% (34/34) remote: remote: Processing changes: refs: 1 remote: Processing changes: refs: 1, done To https://gwt.googlesource.com/gwt ! [remote rejected] uibinderfactory - master (prohibited by Gerrit) error: failed to push some refs to 'https://gwt.googlesource.com/gwt' -- 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/bf896b37-0992-43d4-bc06-a548e88f76b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
Hi Colin, Thanks for your reply. I'm now convinced you have a pretty stable vision of the rules of UiBinder, I wanted to let the community be able to have my modificatio that I find very valuable, that's why I was spamming yesterdy (sunday), before I leave this part of the project and get less reactive to submit the code. - UiBinder is totally declarative - if it had the feature to wire in logical statements, we should equally have loop and conditional constructs. This depends on how far you can go when you say it's declarative: can it be declared partly in another file? because this is what I propose: that's why I don't want the user to have access to the object model but only to its identification (UiBinder class name, feidl name) - Not everyone uses UiBinder, not everything can be done with UiBinder Not everyone uses ClientBundle, people can write they css manually for example. This shouldn't be an argument to remove ClientBundle from GWT - I don’t see a full proposal anywhere So I started just asking to be able to override some methods (asked GWT to make them protected so we can override GWT classes, declare our own Generator and intercept calls on superclasses instead of copying all the access restricted classes : almost all the package) - isAllowed and isVisible were proposed methods only for the draft and for pedagogic reasons to understand the purpose). In reality theres's only one method in the GWT UiBinder: UiBinderWidgetFactory.create() * T extends Widget T create(ClassT widget, String uiBinder, String fieldName)* Notice I intentionally did that there's no access to the model instance so the information remains simple and clear (in a declarative roles file). This answers the first point and the one where you propose to have more dynamic information on what's elsewhere in the view. This is definitely unwanted. The purpose of this is only to build a complete UiBinder template with all possible combinations, and then filter what has to be shown for each profile. Now, each developer will be able to provide his own UiBinderWidgetFactory and use UiBinder for the layout, and his own static declaration for the rules. Which are two distinct concepts that shoudn't be mixed together in annotations or templates. This is why I'm talking about AOP: this is a layer that souldn't be seen by the application. Note: The meaning of @Provided doesn't interfere with this feature. these are two distinct things: if you decide to create you widget manually, don't expect us to jump infront to change whant you're doing. it's the expected behavior Finally t's fair to me that if the user loggs out or changes his profile/roles, the application is reloaded. This doesn't happen sufficiently often in applications to justify special code treatments (it's 0.01% of the code in an app :). @Thomas: thanks for your answer and sorry for the amount of mails you found this morning :) - every @UiField will be non-null after the call to createAndBindUi to any @UiField might be null I answered to this question by telling you that we can impose the retunrned Widget from the factory is not null (for the first versions). But the specification that says it hasn't to be null is not written in the stone. We might after all consider that if the user wants it to be null and decides it to be that way (in his own code), so he will have null. This only gives control to the user, it doesn't surprise him by changing what was there in his existing code (the default WidgetFactory will continue to create fields blindly). Only if a user decides he will furnish his own Widgetfactory and that he wants a field to be null under certain circumstances, he will get what he asked for. - It's not just that, it's deciding whether it'll be created or not. This can be checked and forbidden in the generated code, even if I think it's intrusive to oblige the user to have non null fields where he wants them null. Finally, a per user (or/ per profile or/ per timezone or/ any) Widget personalization at creation is possible with this approach: it's the responsibility of the developer to separate authorizations from css styling but it's not the GWT responsibility anymore anyway. So even though the GWT WidgetFactory has only one method create(), the implementations might have other methods like getStyles(), isToBeCreated(), isVisible(), isEnabled() @Thomas : the bug you linked me to is interesting since it proposes a factory too, except that the factory is per UiBinder (which might be a good thing for performance) . The odd point I saw in answers is that it is aware of what widgets are in the component : It looses its declarative abstract tooling concept that way. But the spirit is indeed the same In my proposition I have two arguments: (uiBinderFileName, fieldName), where they propose to attach a factory per UiBinder so they have only one parameter (or have it hardcoded as
[gwt-contrib] Re: Native Authorization in GWT
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? I've just realize what you meant Thomas, but I really don't agree, that's why I didn't get it : - AOP can intercept methods to completely abort their call, it is still AOP (it is even surely what AOP is for). It can clearly be used to hide an element, that still doesn't mean the code that undergoes the AOP influence has to know there was an AOP code. It just has to sustain that possibility but it doesn't know from where it came. - The result hosting code has anyway to deal with a field that doesn't exist or that is invisible. It has to either do it manually in traditional GWT, or have it done by another automatic/configurable process in what I'm proposing. Behind the AOP there can be many possible solutions, GWT is not obliged to decide which to adopt, this can be handled as separate solutions: for example : - A map of profiles where each profile has a map of UiBinder name keys where it specifies in the value the look and visibility of fields (this way only fields that have special treatment are handled specifically) - The inverse process: methods in the Widget mangaer interface to say isVisible(String uiWidget, String field), getStyles(String uiWidget, String field). Which allows a more abstract interface but can show performance issues on large applications - a magic client factory that handles all this in a special library Possibilities are open. The important thing is to be able to catch the moment a widget is about to be created to be able to have control on the decision. That's the whole point of this feature request -- 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/ae8635a1-371a-4b5d-9d9f-947b110f518b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
I forgot to say it's done and it works, I can submit the code under that bug id, but since the bug was closed I'm trying to justify why I think this feature is important -- 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/cb748642-c029-41fa-a807-853a1c71eb99%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
This seems to be a pretty quiet discussion so far, with mostly Zied
responding to himself and Thomas’s one initial reply, but it is a holiday
weekend here in the US, so that might be contributing to the lack of
additional responses. I haven’t had the chance to even look at the initial
proposal until this morning, but at a glance, I agree that it would be an
interesting successor to uibinder or add-on to uibinder, but likely a poor
modification of uibinder. I’m going to completely ignore the security
aspect, as the ‘best practice’ is to ‘do it on the server’, and never ever
trust the client. If you try trusting the client, you are better of just
omitting the security to avoid any false sense of safety ;).
- UiBinder is totally declarative - if it had the feature to wire in
logical statements, we should equally have loop and conditional constructs.
- Not everyone uses UiBinder, not everything can be done with UiBinder -
use of this tool will be limited to users and use-cases that already are
good fits for uibinder. Anything that is @UiField(provided=true)/@UiFactory
may be ineligible (since they may be have some runtime decided type, so the
UiBinder generator can’t see their moving target of setters), any cells or
other non-uibinder-able ui components can’t work either.
- I don’t see a full proposal anywhere, but from the issue at
code.google.com it appears that the intention is to provide isAllowed and
isReadOnly, and these cases only at initial widget creation, based on a
String idPath, synchronously. Implications from here: All possible
permissions that the app might ever access need to be loaded preemptively,
and from that the server needs to know (and have sent) all possible paths
that the app might have, permissions can’t change without the app being
reloaded (either user gets errors from the server when permissions change
while the app is running, or whole app should be refreshed when any
permission change of current user, group, or other business logic changes),
and permissions are never data-dependent (no need to ever check if the user
‘owns’ the given object, etc).
- isAllowed is a bit of a terrifying prospect - either it is not being
rendered as the specified type (i.e. all @UiFields must be Object and
typed-checked at runtime), or they are left as null (and null checked for
any .add, .setWidget that uses them, any add/setter called *on* them, and
any {} reference made *to* them across all of uibinder internals). Again,
not very declarative, since the type assumptions that can be made by users
authoring the matching .java and .ui.xml need to assume that any of their
declared code in xml might just be ignored and not available in .java.
Were I doing this, I’d go in another direction - don’t try to rewrite
UiBinder into an imperative language, but instead make your own
non-declarative xml-widgets that cover the required cases. Support
conditions and looping, expect to call out to java (or better yet let java
call back in to note that a state change has happened in permissions), and
accept more data, such as the current model object, etc. No need to be
accommodating to UiBinder or non-UiBinder, since this is a new tool
entirely.
For fun, I made a aop-replacement tool, ostensibly for simple ui hints
about permissions for access to things. The goal wasn’t to demonstrate that
*all* AOP can be achieved with simpler constructs, but instead to show that
much if it can, much of the time, with very little code. This tool was
annotation based - define your own annotations and the logic that drives
them, stick them on fields in the view, and ask the rules to run when any
changes are made. For example, this annotation means ‘call
.setVisible(currentUser.group == foo) on any widget with
@OnlyVisibleTo(foo) on it. This is triggered by extending an interface and
keying off of the view type and the model type - the resulting object has a
‘apply’ method that lets it take the view and the model, and applies the
various rules declared in the view.
Annotation:
https://bitbucket.org/niloc132/generated-permissions/src/909e8cd41449c34ca2e3e659de921dc4221342e5/src/main/java/com/colinalworth/gwt/perms/sample/client/Sample.java?at=master
Sample that uses the annotation:
https://bitbucket.org/niloc132/generated-permissions/src/909e8cd41449c34ca2e3e659de921dc4221342e5/src/main/java/com/colinalworth/gwt/perms/sample/client/OnlyVisibleTo.java?at=master
I’m not proposing that this is the only way to solve this, but it is
compatible with regular java views or UiBinder (just stick the annotations
next to the @UiField). I also am not pushing this as a way to solve this
sort of problem out of concerns for developers confusing the concept of
hiding or disabling a widget with actual authorization, but am instead
trying to move this toward a sort of binding tool, but for properties other
than what editors normally work with (i.e. getter/setter against
[gwt-contrib] Re: Native Authorization in GWT
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? As I mentioned it in the user group discussion: the fact that a field is not created is a good thing since it permits to the user to early detect he is trying to deal with a field that will not exist in certain conditions (I called that a runtime-compiler: since it checks if there are potential bugs at runtime). Furthermore, the field is not obliged ot be null, it can be parametrized with a factory strategy (create non visible fields or create them null): in any case it will be less hardcoded than the actual solution that does raw GWT.create() without any possible choice. *By the way, how do you justify that you prefer a hardcoded solution to an extensible one???* We both know it's not AOP, it can't be since there's no proxying mechanism. But it works as if it was: *you can intercept the widget creation and do decide if you want the default process to be executed or/and yours. *The purpose and soul of AOP is this, so let's not lock on implementation technical details. 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) UiBinder is a framework for creating widgets through a declarative syntax: it provides services that don't have to exist when you do things manually. When you use ClientBundle, you don't say ClientBundle is a big issue because it doesn't handle css files that are not declared in it. It's pretty the same logic: either you use UiBinder and get it with its services, or you do the work manually a no one will blame you. 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? *You don't have to think about what to do, it's the whole point of the feature*: a factory/manager will decide if it does raw GWT.create() (as today), or do more sophisticated logic: leaves the field null, does some css additions depending on the logged profile, ect... (you won't see it nor have to deal with it in the GWT core code), it's out of your control at this point. Naturally GWT will furnish a default factory that will continue to do raw GWT.create() as it did until now, but users could declare another factory in the module to override that behavior. 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. There's a plethora of security solutions for the java framework, users may choose to adopt JAAS, Spring security, server bundled security systems (this is another feature request: to use separate urls for methods to be able to intercept a method call and apply security constraints on it, it's another subject). Anyway, GWT is mainly the client side, the ecosystem is different in that part that is translated to js. There's no need for GWT to be responsible for the java language, as soon as we are on the java side, we're in another world that evolved many years before GWT and that has many many solutions for security. So maybe a product will raise someday to unify the declarations on the GWT side with the ones on the server, but that's definitely not a required thing 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.) I'm
[gwt-contrib] Re: Native Authorization in GWT
After doing the patch I can tell you the main points and benefits of the
change:
To be able to do the job, I had to change the signature
of AbstractFieldWriter.writeFieldDefinition() to make it aware of the
context of the field (the document that declares the field)
com.google.gwt.uibinder.rebind.AbstractFieldWriter.writeFieldDefinition(IndentedWriter,
TypeOracle, OwnerClass, FieldWriter, DesignTimeUtils, int, boolean)
I changed the hardcoded line
initializer = String.format((%1$s) GWT.create(%1$s.class),
getQualifiedSourceName());
to an overridable method
initializer = writeInitilizerForField(ownerClass, field);
in my code I just overrided (this could be done in a GWT
UiBinderFieldFactory class instead of my AuthManager)
protected String writeInitilizerForField(OwnerClass ownerClass, FieldWriter
field) {
return String.format((%1$s)
fr.onevu.auth.client.common.patch.auth.AuthManager.create(%1$s.class,
\%2$s\, \%3$s\), getQualifiedSourceName(),
ownerClass.getOwnerType().getQualifiedSourceName(), field.getName());
}
knowing that in AuthManager I delegate the creation of the field to the
concrete implementation of AuthorizationSpecifier that is by default in the
module declaration
replace-with
class=fr.onevu.auth.client.common.patch.auth.DefaultAuthorizationSpecifier
when-type-is
class=fr.onevu.auth.client.common.patch.auth.AuthorizationSpecifier/
/replace-with
This is not an invasive code at all and it doesn't break the architecture
of the UiBinder. It might bring bugs if a panel is null and you assume it
isn't, then for a first version, you might forbid returning null from the
factory, but it's still a powerful feature will little change in the code.
If I had to say it in one sentence it would be:
*Giving the hand to the user to handle his widgets at creation instead of
assuming to know what the user wants to do. *
Le vendredi 23 mai 2014 14:59:35 UTC+1, Zied Hamdi OneView a écrit :
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
herehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727
https://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727
A
discussionhttps://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliYalready
happened in the user forum too about the subject.
Your ideas and comments are welcome :)
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this
[gwt-contrib] Re: Native Authorization in GWT
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 herehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 https://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 A discussionhttps://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliYalready 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
