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: [email protected]
[mailto:[email protected]] On Behalf Of Steve Saunders
Sent: Saturday, March 17, 2018 8:27 PM
To: iotivity-dev <[email protected]>
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 the provisioningclient 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
[email protected]
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
