Nathan Adding the ace entry suggested below did the trick. Thanks You Sir!!!
Steve > On Mar 17, 2018, at 3:49 PM, Heldt-Sheller, Nathan > <nathan.heldt-shel...@intel.com <mailto:nathan.heldt-shel...@intel.com>> > wrote: > > Hi Steve, > > It’s possible that the wildcard changes caused this to (correctly, I’m > afraid!) quit working. If you send me a log file from the Server, with some > idea of where the “CA_UNAUTHORIZED” happens (e.g. “on the 2nd GET to the /csr > Resource, it fails”) I can verify whether the access control layer is > rejecting the request based on no matching ACE in the /acl2. > > Or, a quicker black box test would be to try adding an explicit /acl2 entry > for the /csr (or whichever SVR you’re accessing), since “*” no longer applies > to SVRs… the provisioningclient shouldn’t have been depending on that “*” > access but maybe it is after onboarding is done and it closes the OBT session > (and loses “OTM session access”). E.g. instead of: > > { > "aceid": 3, > "subject": { "uuid": "10101010-1010-1010-1010-101010101010" > }, // where this is the UUID of the provisioningclient, say > "resources": [{ "wc": "*" }], > "permission": 15 > }, > > > Add > > { > "aceid": 3, > "subject": { "uuid": "10101010-1010-1010-1010-101010101010" }, > "resources": [ > { "href": "/oic/sec/acl2" }, > { "href": "/oic/sec/cred" }, > { "href": "/oic/sec/doxm", > { "href": "/oic/sec/pstat" } //etc > ], > "permission": 15 > }, > >
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
