Re: WOOgnl, redux
Re: WOOgnl, redux
- Subject: Re: WOOgnl, redux
- From: Paul Yu <email@hidden>
- Date: Sun, 13 Aug 2017 19:02:07 -0400
Is this an ABAC implementation?
Paul
Sent from my iPhone
Please excuse iOS autocomplete
> On Aug 13, 2017, at 5:08 PM, Morris, Mark <email@hidden> wrote:
>
> This is a topic that was discussed back in 2011, but my searches haven’t
> turned up a satisfactory solution.
>
> Some quick background info, we have information-dense, complex pages, and
> there are a variety of permission levels for internal and external users that
> needed to be implemented at field-level granularity.
>
> My approach was to create a method for determining edit-ability in the
> superclass for each area’s components that maps permission level with field
> name:
>
> public boolean editingEnabledByField( String field )
>
> … which I’m calling using WOOgnl in WOConditionals as the condition and in
> custom components like this:
>
> <wo:OurCustomComponent
> editingEnabled="~editingEnabledByField(\”thisFieldName\")" expanded="$true" />
>
> This actually works fine as far as the functionality goes. The issue is our
> logs get filled with warnings that look like error messages, one for every
> field for every page hit. Since the bindings on these pages are synchronized,
> the log messages apparently occur when the value of “editingEnabled” tries to
> get pushed into “editingEnabledByField(”thisFieldName”)”, which obviously
> isn’t possible. (So getting the value from the ognl expression works fine,
> setting to the ognl expression does not.)
>
> In 2011 Mike Schrag wrote about almost this exact same question:
>
>> this seems wrong to me ... it's not the ognl is intrinsically unsettable
>> it's that you're trying to set a value on an ognl expression that definitely
>> ISN'T settable. either you should turn off automatic binding synchronization
>> on SelectByCharacterPopupEditField and manually sync, or this patch should
>> maybe be smarter about how it determines "setability" in ognl. i would be
>> afraid of breaking anyone who might be taking advantage of settable ognl
>> expressions. i don't, offhand, know how to perform that check -- whether
>> ognl has API to do it or if it's even possible.
>
> The patch he was referring to was:
>
> public WOOgnlAssociation(String s) {
> super(s);
> _isValueSettable = false;
> }
>
> … which is a sledgehammer approach that probably wouldn’t be applicable in
> general. However, picking up from where Stefan left off there, perhaps this
> is at least a partial solution (that I think will work for my case anyway):
>
> public WOOgnlAssociation(String s) {
> super(s);
> if( s != null && s.matches( ".+\\(.*\\S.*\\)" ) ) {
> _isValueSettable = false;
> }
> }
>
> This regex checks to see if there’s a method call with some sort of parameter
> (by looking for something followed by “(“ followed by some non-whitespace
> followed by “)”).
>
> Does this seem reasonable? Any counterexamples where a matching key path
> should be settable? I know that ognl expressions can include parentheses as
> well, but I would think those also would not be settable, right?
>
> Thanks for any tips or advice!
>
> Regards,
> Mark
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden