HI Nathan, Thanks for the quick response! I’ll try adding explicit acl2 entries, and let you know what happens.
Cheers! 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 > }, > > > > <>From: iotivity-dev-boun...@lists.iotivity.org > <mailto:iotivity-dev-boun...@lists.iotivity.org> > [mailto:iotivity-dev-boun...@lists.iotivity.org > <mailto:iotivity-dev-boun...@lists.iotivity.org>] On Behalf Of Steve Saunders > Sent: Saturday, March 17, 2018 8:27 PM > To: iotivity-dev <iotivity-dev@lists.iotivity.org > <mailto:iotivity-dev@lists.iotivity.org>> > Subject: [dev] Provisioningclient GET tests recently broken > > Hi All, > > Recently (within the last week I believe) changes have been merged which > causes some (or maybe all) of theprovisioningclient resource GET tests to > fail. > > For example, option 62 GET CSR … provisioningclient goes into an infinite > retry loop. I did a little bit of investigation and found that the function > > OCHandleResponse(endPoint, responseInfo) > > Is receiving responseInfo->result = CA_UNAUTHORIZED_REQ and > responseInfo->info.payload = NULL; > > I found this because when I rebased my in progress work for the new > security_profiles resource my provisioningtest testing started to fail, and I > have lost my primary means of testing. > > It is a pretty big deal for me to lose this with one week to get my stuff > done by Bangkok IPR start ... does anybody know what is going on? > > Kind Regards > Steve > > PS: > > I looked through the devlist emails, and found this, perhaps some related > code was added to address the concern below, but may have broken > provisioningclient? > > Looks like current implementation of provisioning client doesn't check > doxm.sct value from server and use PSK credential type by default. > > Best regards, > Aleksey Volkov
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
