About
  • This user has not yet committed.

Reviews

0 active reviews

Counts may include data that you cannot access.

Bjørn Ola Smievoll

NoearlieractivityNolateractivity
Bjørn Ola Smievoll

commented on OPENAM-670

17 Apr
This bug still affects OpenAM 10.0 I'm afraid.
Bjørn Ola Smievoll

attached one file to OPENAM-1029

27 Feb
URLEncoding patch for OAuthConf
oauth_2.diff
Bjørn Ola Smievoll

commented on OPENAM-1029

27 Feb
Thanks for accepting the patches, one less reason to maintain a separate build and thats always good.

Though, isn't there now again a risk of a NPE if result is null?

I also forgot to update the patch of OAuthConf with an additional URLEncoding, I'll attach it as a separate patch.
Bjørn Ola Smievoll

created OPENAM-1029, OPENAM-1028

19 Dec 11
Bjørn Ola Smievoll

summarized and closed CR-288

29 Nov 11
No summary.
Bjørn Ola Smievoll

started review CR-288

27 Sep 11
OPENAM-670 Patch
Bjørn Ola Smievoll

attached one file to OPENAM-670

23 Jun 11
Null check fix on pResponseProviderName.
JSONException.patch
Bjørn Ola Smievoll

commented on OPENAM-670

23 Jun 11
I've fiddled around a bit with this and I'm now able to reproduce the JSONException by changing an entitlement definition in the beta console, i.e. by giving a Resource Attribute a different value.

The first request following such a change triggers the reloading/recreation of a instance of a subclass of the Privilege interface. As the exception doesn't break the intended execution path of the code the result is OK and is probably cached, which is why the error doesn't occur on every call (I haven't totally grasped the inner workings of the entitlements engine yet so this may well be wrong).

As John Erik pointed out in the initial description the org.json.JSONObject.getString() method will throw an exception when an attempt to retrieve an undefined key is done.

The javadoc of the ResourceAttribute interface clearly indicates setting the pResponseProviderName is optional, so my conclusion is that there really should be null-checks in StaticAttributes.setState() and UserAttributes.setState().

I've attached a patch against svn rev 850 of trunk adding this check.

With this in place I'll see if I still get the permission error that commonly precede the JSONException, can't at the moment say if they're related.