[rfc][icedtea-web] conditional disabling of manifes tattributes

[Jiri Vanek]

On 04/15/2014 05:48 PM, Jiri Vanek wrote:
> On 04/11/2014 06:49 PM, Andrew Azores wrote:
>> On 04/11/2014 09:07 AM, Jiri Vanek wrote:
>>> On 04/10/2014 04:44 PM, Andrew Azores wrote:
>>>> On 04/10/2014 08:43 AM, Jiri Vanek wrote:
>>>>> Hi!
>>>>>
>>>>> This patch can disable the check for new manifest attributes.
>>>>> sevral motivations
>>>>>   -  I hate this feature
>>>>>   - the remembering of this actions may take time to implement
>>>>>   - and the most important  - the testsuite...
>>>>
>>>> Most important indeed.
>>>>
>>>>>
>>>>> will go both head and 1.5.
>>>>>
>>>>> I'm hesitating whether to make this property public via itw-settings... Well if so, then as
>>>>> another changeset. Any opinion about publish it in itw-settings?
>>>>>
>>>>> J
>>>>
>>>> Ok to push, so that we can clean up some of the noise in the test suite.
>>>>
>>>> RE putting it in itweb-settings - I think the cleanest way to do this, if it's to be done at
>>>> all, is
>>>> probably to add another security level. 'Minimal' or something perhaps? Because I don't think it
>>>> makes sense to add it in as a checkbox, for example, and have it possible to set security to High,
>>>> but disable manifest checks. I'm not sure if we really want to allow this, though. I can imagine
>>>> most users leaving the security level at Minimal once they discover that this gives them the least
>>>> amount of clicking to do before getting their applets to run :)
>>>
>>>
>>> Oh yes, that can be correct thing to do. But looking to the issue from this perspective, it is
>>> NO-GO  argument for it as it is done. Well all correct applications should be updated to support
>>> new attributes.. but the legaxy, and still used ones?
>
> I have pushed at the end. This shortcut for testsuite is needed.
>>>
>>> So I have another idea here - really extend ExtendedAppletsSecurity, and to allow "do not check
>>> manifest attributes" on the application/codebase  - So all those dialogs will be moreover based on
>>> your abstraction of Extended Applets security. Also remember alaca checkbox issue will be solved
>>> by this.
>>>
>>> Bu the extension of ExtendedAppletsSecurity will needed to be done really carefully - and prepared
>>> before implementation.
>>>
>>> What do you think?
>>
>> Sounds like it could be a lot of work, but should be worthwhile in the end. I think it will be very
>> nice if we can unify all of our dialogs like this so that they can all make use of the same
>> remembered action storage. Or at least, the ones that need to be able to remember actions. I'm not
>> sure about having the manifest attribute check be an option to be selected on the dialog though,
>> even with an option to remember it... but maybe it's the right thing to do. It just seems like the
>> dialogs are getting busier and busier and more confusing looking, but you're right that this option
>> will (hopefully) be used mostly for allowing some old applets which haven't been updated to be used
>> still. In that kind of situation, which I think is the target, then applying the setting to all
>> applets/globally maybe isn't the right choice. So as ugly and cluttered as the UI might become, I
>> suppose this really should be done on a per-applet basis (maybe in addition to having it
>> configurable globally?).
>>
>
> Hi attached patch is adding the basic support for multiple types of actions. Well it apeared that
> the implementation itself will be quit easy (if this approach will be used) but most troubles will
> be in itw-settings. The table will requires serious revork on level of filtering, sorting, delting
> and especially editing of first - action - column.
>
> General idea is - instead of one   ExecuteAppletAction unsignedAppletAction will be list of them,
> encapsualted in  AppletSecurityActions unsignedAppletAction;
> In file it will be encoded instead of current one char, as one-word string - see the tests.
> To read/write the correct action for given type, there will be set of getters/setters  - tight now
> there is
>   public ExecuteAppletAction getUnsignedAppletAction() {
> +        return getAction(0);
> +    }
> +
> +    public void setUnsignedAppletAction(ExecuteAppletAction a) {
> +        actions.set(0,a);
> +    }
>
> And they will encapsulate the order in list.
>
>
> If nothing else...This is nicely backward compatible, and scaleable for growth of "remember me"
> dialogs :)
>
> Once this is aproved -if ever -  I will add few more "on top of it" work like -table or rember for
> ALACAto se hw it works - before push itself.
> J.
>
>

This is a bit better - get rid of paranoid constant of MAX_LENGTH.

J.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: multipleActionsBasePatch2.patch
Type: text/x-patch
Size: 24436 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140416/53764d5e/multipleActionsBasePatch2-0001.patch>