[rfc][icedtea-web] rememberable dialogues general solution - tech-preview
Jiri Vanek
jvanek at redhat.com
Mon Jun 1 18:12:46 UTC 2015
hi!
This patch is big refresh of code, which is handling dialogues.
Main task was to create mechanism, which will handle general saving of dialogues - eg both alacas, and permissions missing are heavily missing this feature. We are forcing users to use ignore-manifest attributes by not having this.
I'm aware of much more flaws in dialogues handling, and in this patch *had* to fix them
As benefit, this patch have many flaws - eg itw can not be completly builtt with it...:)
It can not be built, because I did not adapt ITW settings... but I have an plan.
Well it is serving as preview, where my next ..five?... pathces will be heading.
I do not except anybody to review it, but any feedback is worthy.
My mine concerns are going from fear, that I have probably intorduced many NPEs. Before this patch, null, as result of closing any dialog seemed to be handled.. somehow, sometimes wrongly, but was. Now I'm not so sure.
My idea was, to have an interface, and if SecurityPanel impl is implementing this interface, then it is automatically rememberable, adn ITW does rest for author of new dialog. This is done. If application use RemebmerPanel as one of its components, then it have implementation of this interface done.
Main secondary fix (after extraction of (RemebmerPanel) were return types from dialogs. ITW had legacy burden, that dialogs return 0 for yes, 1 for no, 2 for cancel or sandbox(!) or null if closed.
With this return schema - completely untraceable via code, completely unclear (there is a lot of comments in code like /*0 yes,1 no,2 whatever*/ )and absolutely not-typed - I could not do this So it had to be refactored too. Advantage (badly designed but still advantage) is, that via this integer default-selected button is choosen. I kept this behaviour, but I think it is nowhere used (if somebody can verify, I will be happy).
Attached is patch, and graph, how the message flow from posting , through dialog's threads and back to user space. Remember - I have added only the small branch which is handling whether dialogue is rembered or not. And even this is built on already well designed and tested extended applets security.
I think I will include the graph in package-info.html for /netx/net/sourceforge/jnlp/security/ (rfc!!)
Also I have kept current yAnN saving schema. I like it. And I removed all misuses of this. Now it is only signature of saved state of current dialogue (visited+approved(yES), remmeber yes (Always), visited and revoked (nO), alweys revoke (Never)). But current value of saved state, is handled via content of answer (eg YES, or SANDBOX, or many info of CompelxReturn from shortcut dialog. I have also removed all redundant reimplementation of this type.
The new structure of first collumn of .appletSecurity is now dialogClassName1:resolution{value(s)};dialogClassName2:resolution{value(s)};...
Where id is really dialog's name as writtenin java code. Resolution is one of the yAnN (so it is nicely backward comaptible!) nd value is, written by /dialogresults/ typ itself. So it can be practically anything (only spaces and { or } forbidden, and ; discouraged. Also it is reposnible for its reading.
What the patch do, and what will ongoing patches do:
- as last step, but must go first, I introduced type-safe returns from dialogues. From yesNo over yesNoCancel and yesNoSandbox to CompelxReturn from shortcut dialog.
- note: only yesNoSandbox and CompelxReturn are now used in this patch, I need to thing about it more deeply when I will be cretaing thsi first patch to push.
- each of those types is responsible for its save/storage
- see new package netx/net/sourceforge/jnlp/security/dialogresults/ and its usages
- create remmeberable dialogue interface, and basic impolementations of it (missng+matching alaca, acesswarning , applettrustwarning, UnsignedAppletTrustWarningPanel
- make them use of remberpanel
- impelment backward compatible storage and make dialog-thread to save/load remmeberableDialogue to/from it
- impelment read only itweb-settings for "first column"
- implement editable itweb-settings for "first column" (both those should be based on the RemeberabelDialogue interface and nothing else. I have pilot done, but it is not ready even for tech-preview)
I hope I will be able to implement three main stages in bit more patches.
Lukas + Jie - I would really like to missuse you for testnng of this feature. All dialogues have to be tested with new, type-safe return types. I tested half of them, and each had some hidden issue. It would be nice to do it on this big patch, and then on each pushed subpatch.
if you wil help with code review, it will be nice, but it is not mandatory. But for testing, I really beg for some assistance.
Best regards from CZ
J.
binaries:
https://jvanek.fedorapeople.org/itw/remmeberable-dialogues-proofOfConcept/
patch+the diagram
https://jvanek.fedorapeople.org/itw/remmeberable-dialogues-proofOfConcept/rememberableSolution-proofOfConcept.patch
https://jvanek.fedorapeople.org/itw/remmeberable-dialogues-proofOfConcept/ITW_DIALOGS
built binaries (to you do not need to bother with building code with error-ignoring compiler)
https://jvanek.fedorapeople.org/itw/remmeberable-dialogues-proofOfConcept/built-classes.xz
and whole checkout with patch applied ( i had some torubles with application...)
https://jvanek.fedorapeople.org/itw/remmeberable-dialogues-proofOfConcept/itw-rememeberable.xz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rememberableSolution-proofOfConcept.patch
Type: text/x-patch
Size: 207425 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20150601/66f6aee4/rememberableSolution-proofOfConcept-0001.patch>
-------------- next part --------------
ITW-thread(s) | dialogs-thread X
| X
presteps in SecurtyDialogs | X
| | X
prepare message | X
* set JNLPfile | X
* set type of dialog | X
see | X
* extrass... | X
* lock | X
| | X
post message to queue | X
| >------------------------------------> | <----------------------------------------------------------------------------------------------------------------------------| X
wait for result from | read message from queue | X
getUserResponse(lock lock)| | | X
| create instance of dialogue | X
| | | X
| acording to type of dialogue, create and place panel (this is important, panel is keeper of rememberable decission) | X
| | | X
| if panel is instance of RememberableDialogue | X
| else then | X
| | | | X
| | check whether this applet+action was already stored and pernamently remembered in .appletSecurity | X
| | no yes | X
| |<-------------------------| | | X
| | | | X
| | | | X
| | | | X
| | | | X
| add closing and disposing listener(s) to button(s) | | X
| | * set return value to listner? | | X
| | | | X
| accordingo to set value, set default selected button? | | X
| | | | X
| if his applet+action was already stored in .appletSecurity include text approved/denyed and when | | X
| | | | X
| wait for user to click buttton or close dialogue | | X
| | | | X
| --> set selected value (via listener?) to message, dispose dialog -> <- set stored value to message <-| | X
| | | X
| if panel is instance of RememberableDialogue crate new, update old(date/decission,jars...) record in .appletSecurity | X
| | | X
| <------------------------------------------------------------------------------------------< unlock lock of this messge >--------------------------------------------| X
read result from message | X
| | X
continue accordingly | X
X
More information about the distro-pkg-dev
mailing list