[rfc][icedtea-web] PolicyEditor gains a real parser

[Jiri Vanek]

On 03/14/2015 09:19 PM, Andrew Azores wrote:
> Hi,
>
> Attached is an updated version of this patch, which makes the editor GUI display the actual PolicyIdentifiers, rather than just codebases. Nothing else has changed since the previous version (other than also updating the patch to apply cleanly on current HEAD), but I think that this patch is in a pretty good state right now, and I'd like to push it and continue working on it in further, smaller changesets. My next goals are to adapt the UI to allow modification of the signedBy and principals for each identifier, and then to introduce an "Advanced View" toggle of some sort which will toggle between the existing codebase-oriented simplified UI, and the full UI which I just outlined. After that, I will look at refactoring it all to use a single class as the point of contact with the sun classes, as I've already discovered earlier today that this changeset no longer builds with the latest JDK 8.

Just quick galnce - I'm against removal of ciodebase:((( I know it is hard, but some replcament 
hsould be deffined.

Also - I owuld like to release in month,  or two - no longer. How is your work on this suitbale with 
this schedule?

J.

>
> Thanks,
>
> Andrew
>
> ----- Original Message -----
>> On 01/30/2015 04:26 AM, Andrew Azores wrote:
>>> Hi,
>>>
>>> On 01/29/2015 06:23 AM, Jiri Vanek wrote:
>>>> I was not reading whole thread (lazyyY!)
>>>>
>>>> So maybe those were already answered:
>>>>
>>>> Why OPTIONS.CODEBASE disapeared??? I can not see its replacement.
>>>
>>> Before this patch, PolicyEditor's internal model assumes that codebases can
>>> be used as unique
>>> identifiers of sorts - each entry in a policy file always has exactly zero
>>> or one codebases, and
>>> does not have principals, or signedby. With this patch, the internal model
>>> becomes full-featured,
>>> like upstream policytool's, and PolicyEditor can actually handle policy
>>> entries with any combination
>>> of codebase/signedby/principal, just like policytool. The PolicyEditor GUI
>>> just doesn't have a way
>>> to display them (yet). So a -codebase selector is no longer guaranteed to
>>> return exactly one (or
>>> none) result, and I don't know what the expected behaviour would be if
>>> there were multiple matches
>>> in the policy file, especially when some of them may be "hidden".
>>
>> I think you should preserve this opinion. Maybe to change it from codebase to
>> keyword or whatever.
>> Or jsut keep codebase and specify tat it can accept any keyword.
>>
>> Now - why keyword - it will be used to match something in polici editor, or
>> to ad "header" of new
>> entry. Basic usecase - exactly the same as as you do with codebase param now.
>>
>> What do you think?
>>
>>>>
>>>> Also the patch do not apply   the  -        FILE("-file", "policy_file",
>>>> "PBOFile"), and CODEBASE("-codebase", "url", "PBOCodebase"); definitions
>>>> changed.
>>>
>>> Yes, I'll make that change this weekend I hope.
>>>
>>>>
>>>> The code itself is pretty god - especially via using the
>>>> import sun.security.provider.PolicyParser;
>>>>
>>>> *however*
>>>>
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/008072.html
>>>> "In JDK-9 we would have modules and you will not be able to use the
>>>> sun.* packages at all, so this changeset is useless for JDK9. "
>>>>
>>>> Makes me worrying about this approach. Especially also because of
>>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-October/029989.html
>>>>
>>>>
>>>> So if we are going to use it, it sholdbe changed to public api. So you
>>>> should have some adapter, which will allow simply switch between old and
>>>> new api. And ofcourse, somebody have to negotiate it with upstream.. oh
>>>> dear....
>>>
>>> Yea, this sounds problematic. I have no idea how to move forward with this
>>> kind of forward
>>> compatibility in mind, honestly.
>>
>> The only thing I have in mind is yu, creating only one class using sun*
>>
>> The rest of your work will use this  one class. Right now, in this class will
>> be regular calls to
>> regular methods, but if they will disapear for us, those calls will be
>> chnaged to reflection calls
>> or something like that. What do you think?
>>>
>>>>
>>>> Also, I.m aware of
>>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-November/030101.html
>>>> thread. It died without push. Or am I wrong?
>>>>
>>>
>>> Not wrong, it did die without push, but only because it was around that
>>> time that I discovered these
>>> sun parser bits, and found out that the PolicyIdentifier I was making there
>>> could be easily adapted
>>> and made much more useful by doing some rewrites and using the sun stuff,
>>> and then this whole patch
>>> happened. So really, that old patch just became this one :)
>>
>> cool. Thanx!
>>>
>>>>
>>>>
>>>>
>>>> To code:
>>>>
>>>>
>>>>    Why DisplayablePermission isnt regualr class?
>>>
>>> You mean why is it an inner static class rather than its own top level?
>>> Mostly just because the only
>>> context I intend it to be used it is within the Custom Policy Viewer. Its
>>> only reason to exist is
>>> because the Sun PolicyParser.PermissionEntry doesn't implement toString
>>> nicely, really, but I need
>>> the CustomPolicyViewer to be able to display its permissions, obviously. It
>>> seemed nicer to subclass
>>> the class I actually wanted to use (PermissionEntry) and have this
>>> implement toString than to make
>>> all my CustomPolicyViewer Swing stuff use custom adapters to render the
>>> collection of permission
>>> entries.
>>
>> wth.. oook...
>>
>>>
>>>>
>>>> the
>>>>
>>>> +    /**
>>>> +     * PolicyEditor is only designed to deal with grant entries with a
>>>> single codeBase -
>>>> +     * no signedBy and no principals. Any "identifiers" attached to
>>>> grant entries which
>>>> +     * do not strictly match this will be ignored and not displayed in
>>>> the UI.
>>>> +     */
>>>> +    static boolean isCodeBaseIdentifier(final PolicyIdentifier
>>>> identifier) {
>>>> +        return (identifier.getSignedBy() == null ||
>>>> identifier.getSignedBy().isEmpty())
>>>> +                && (identifier.getPrincipals() == null ||
>>>> identifier.getPrincipals().isEmpty())
>>>> +                && identifier.getCodebase() != null;
>>>>
>>>>
>>>> MEans, that all other policies will be unvisible, but not lost.
>>>>
>>>> What about showing them at least read only? Aka as plain text or
>>>> something like it... It wouldbe suspicious if they are "just not there"
>>>>
>>>>
>>>
>>> Yes, I've been intending to work on this somehow but have not yet had time.
>>> Do you have any
>>> suggestions on how to display them read-only? I was thinking maybe
>>> (temporarily, until somebody
>>> makes the PolicyEditor GUI properly handle the full permission entry
>>> feature set) just have another
>>
>> Only you can do this :))
>>> child window like the CustomPolicyViewer... or maybe just have them
>>> displayed in the
>>> CustomPolicyViewer itself, honestly. What do you think?
>>
>>
>> Right now, I think the read only policies canbe grayed in list, and when
>> clicked, then all our
>> checkboxes disapear, and read only textarea can occure with
>> selectedPolicy.toString()
>>
>>
>> hmm? Well stupid, but better then being silent about them and informative
>> enough as temporary solution.
>>>
>>>>
>>>> Why
>>>>    +public enum PolicyEditorPermissions implements Serializable {
>> snip...
>>
>>
>> rest is clear. Thank you!
>>
>>
>> J.
>>
>>