Hi Joseph (or Joey, I don't know which),

I can see the ACL I set before converting but I'm far from seeing the
Device ID I mentioned above (5fd82524-0f91-050b-bc3c-2707d57ac132). Perhaps
I'm missing something? And by CBOR payload does that imply the byte array
received in the callback?

Regards,
A. Lapprand

2017-12-26 17:19 GMT-03:00 Morrow, Joseph L <joseph.l.mor...@intel.com>:

> Hi Arthur,
>
> I don’t know if you’re running on Linux or on Windows. But in any case,
> from a Linux Terminal or Cygwin Terminal (eg. Git Bash on Windows), you can
> pass the following command to retrieve the contents of your .dat file.
>
> xxd -p [arthur].dat
>
> Then copy the hex contents to your clipboard. Paste it in the right dialog
> at www.cbor.me. Then click on the Left Arrow to the left of the word
> “Bytes” at the top of the page.
>
> The left dialog will get populated. Copy everything in the quotes (where
> ‘…’) is the hex contents of CBOR content within CBOR key ‘doxm': "h’…’”
>
> Empty the right dialog (ctrl+a + backspace), Paste the doxm contents and
> you should see the Device ID you mentioned below in this body of DOXM.
>
> Likewise, you should be able to see the configurations you set for ACL
> before you converted with json2cbor. Just be sure to notice that there is
> CBOR hex within the CBOR payload, so you will have to convert those
> sub-components with “cbor.me” as well.
>
> Thanks,
>
> Joey Morrow
>
> From: Arthur Barros Lapprand <a...@cin.ufpe.br>
> Date: Tuesday, December 26, 2017 at 10:48 AM
>
> To: Joseph L Morrow <joseph.l.mor...@intel.com>
> Cc: Tonny Tzeng <tonny.tz...@gmail.com>, iotivity <
> iotivity-dev@lists.iotivity.org>, Rami Alshafi <ralsh...@vtmgroup.com>,
> "Matthews, Michael L" <michael.l.matth...@intel.com>
> Subject: Re: [dev] FW: Android SECURED mode
>
> Hi Joseph,
>
> I couldn't find the error code but I did look into the error=ERROR flag
> which is described as a "generic error". Precisely, this one:
> "org.iotivity.base.OcException: stack error in onGetCallback ERROR". I
> don't know about the [introspection].dat file but I did look at that
> server_fopen() code before. I'm did convert the UUID to a string but it's
> not really human readable, probably because the OcPlatform.getDeviceId() is
> returning a random generated ID. On my client app, when the
> OnResourceFound() callback is triggered and I print the
> ocResource.getServerId() it comes out as 
> "5fd82524-0f91-050b-bc3c-2707d57ac132",
> which is nothing like the ID in the ACL. I may be confused about that since
> I don't know if the ServerId should be the same. Nevertheless, I'm sending
> the .dat files and .json ACL just in case someone want to have a look and
> possibly find something wrong. Oh, and about the introspection file, do I
> need to set it up if I want the ACL to work?
>
> Thank you,
> A. Lapprand
>
> Em ter, 26 de dez de 2017 às 15:11, Morrow, Joseph L <
> joseph.l.mor...@intel.com> escreveu:
>
>> Hi Arthur,
>>
>> Quick Tip: Most of the errors are OCStackErrors. If you have a non
>> HTTP-looking error (eg. 404, 501, …4.04, 5.01, …), then it is likely
>> defined in octypes.h. Please compare to the enumeration found in
>> <iotivity>/resource/csdk/include/octypes.h.
>>
>> A common error is ’46’ which means “Unauthorized.” This has occurred to
>> me in many cases:
>>
>>
>>    - IoTivity has overwritten your SVR *.dat file and therefore
>>    corrupted all of your configurations
>>       - This can happen if you’re providing your own
>>       “[arthurs_cbor].dat" file but forget about the [introspection].dat 
>> file.
>>       Please verify you use a similar if-check as found in
>>       <iotivity>/resource/examples/lightserver.cpp:server_fopen().
>>       - This can also happen if for some reason your *.dat file doesn’t
>>       follow correct CBOR format or if something in there isn’t the right 
>> format.
>>       Perhaps your device ID is wrong, for instance. To verify the SVR was 
>> loaded
>>       correctly, please see that your Device ID is as you’ve defined it by
>>       calling (C++ SDK). You can either debug or convert the UUID to a 
>> string and
>>       print it out.
>>
>> “
>> OCUUIdentity id;
>>
>> OC::OCPlatform::getDeviceId(&id);
>> “
>>
>>    - The ACLs in your config are set up correctly. I will defer to
>>    someone else for that info.
>>    - If any symmetric keys (ie. Raw) or pins are being used in your SVR
>>    file, make sure they match on both sides (server & client).
>>
>> Thanks,
>>
>> Joey Morrow
>>
>> From: Arthur Barros Lapprand <a...@cin.ufpe.br>
>> Date: Tuesday, December 26, 2017 at 5:04 AM
>> To: Joseph L Morrow <joseph.l.mor...@intel.com>
>> Cc: Tonny Tzeng <tonny.tz...@gmail.com>, iotivity <
>> iotivity-dev@lists.iotivity.org>, Rami Alshafi <ralsh...@vtmgroup.com>,
>> "Matthews, Michael L" <michael.l.matth...@intel.com>
>>
>> Subject: Re: [dev] FW: Android SECURED mode
>>
>> Hi Joseph,
>>
>> I have done as you described and it indeed changed the situation. The
>> error which before had the UNAUTHORIZED_REQ flag now has the ERROR flag. I
>> don't really know what this flag means but I'm searching it.
>>
>> Regards,
>> A. Lapprand
>>
>> Em seg, 25 de dez de 2017 às 14:38, Morrow, Joseph L <
>> joseph.l.mor...@intel.com> escreveu:
>>
>>> Hi Arthur,
>>>
>>> My coworker Michael and I just found the following solution. We placed
>>> this in our Client’s Discovery Callback for the timebeing. As you may
>>> notice, you can call setHost() at any time after discovery has occurred.
>>>
>>> The reason you need to perform the setHost() function, is because the
>>> C++ SDK doesn’t automatically assume you want to use the "coaps://“ (ie.
>>> Secure communications) version of the Resource’s URI. It assumes you want
>>> to use the “coap://“ version and the Server will reject this if your
>>> resource(s) were created with the OC_SECURE flag. (Note: I’ve just recently
>>> heard you no longer need to specify the “OC_SECURE” flag as all resources
>>> are created as Secure Resources now by default.)
>>>
>>> foo( std::shared_ptr<OC::OCResource> resource )
>>>
>>> {
>>>
>>>   //
>>>
>>>   // Find the first secure coaps endpoint in the list of hosts. If it's
>>> there
>>>
>>>   // then use it; otherwise use the unsecure coap endpoint.
>>>
>>>   //
>>>
>>>   auto resourceHostList = resource->getAllHosts();
>>>
>>>
>>>
>>>   for (auto &host : resourceHostList)
>>>
>>>   {
>>>
>>>     if (std::string::npos != host.find("coaps://"))
>>>
>>>     {
>>>
>>>       resource->setHost(host);
>>>
>>>
>>>
>>>       break;
>>>
>>>     }
>>>
>>>   }
>>>
>>>
>>> // If you keep a single copy of your discovered resource, take the copy
>>> of it here for you to use later in your application.
>>>
>>> MyDiscoveredResources.push_back(resource); // For a quick test, just
>>> call "resource.get()" and see if the server side is honoring your request
>>> now.
>>>
>>>
>>> }
>>>
>>> Thanks,
>>>
>>> Joey Morrow
>>>
>>> From: <iotivity-dev-boun...@lists.iotivity.org> on behalf of Arthur
>>> Barros Lapprand <a...@cin.ufpe.br>
>>> Date: Sunday, December 24, 2017 at 6:51 PM
>>> To: Tonny Tzeng <tonny.tz...@gmail.com>
>>> Cc: iotivity <iotivity-dev@lists.iotivity.org>, Rami Alshafi <
>>> ralsh...@vtmgroup.com>
>>> Subject: Re: [dev] FW: Android SECURED mode
>>>
>>> I am using both OC_NONSECURE and OC_SECURE flags when registering the
>>> resources and attempting a GET request with the OcResource I get from the
>>> OnResourceFound callback. Odd, isn't it?
>>>
>>> Thank you,
>>> A. Lapprand
>>>
>>> Em dom, 24 de dez de 2017 às 23:46, Tonny Tzeng <tonny.tz...@gmail.com>
>>> escreveu:
>>>
>>>> What flags did you pass to the registerResource() function? note that
>>>> if you want to communicate over non-secure endpoint, you need to pass
>>>> OC_NONSECURE flag explicitly while registering the resource. The
>>>> simpleserver server doesn't work in non-secure mode for the same reason, no
>>>> passing OC_SECURE flag doesn't imply the use of non-secured endpoint. Hope
>>>> this helps.
>>>>
>>>> Regards,
>>>> Tonny
>>>>
>>>> On 25 December 2017 at 10:09, Arthur Barros Lapprand <a...@cin.ufpe.br>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I got to test the ACLs Rami provided while changing the server json by
>>>>> adding these ACEs:
>>>>>
>>>>> {
>>>>>     "aceid": 6,
>>>>>     "subject": {"conntype": "anon-clear"},
>>>>>     "resources":[
>>>>>         { "href":"*"}
>>>>>     ],
>>>>>     "permission": 14
>>>>> },
>>>>> {
>>>>>     "aceid": 7,
>>>>>     "subject": {"conntype": "auth-crypt"},
>>>>>     "resources":[
>>>>>         { "href":"*"}
>>>>>     ],
>>>>>     "permission": 14
>>>>> }
>>>>>
>>>>> So in theory I guess my server should respond to any request. Sadly that 
>>>>> didn't
>>>>> work so now I'm somewhat confused. I noticed the UNAUTHORIZED_REQ message
>>>>>  is sent to the client by a COAP host (not COAPS). Maybe I'm compiling 
>>>>> IoTivity
>>>>>  with the wrong scons settings? Also, how do I know my client is using 
>>>>> COAPS? I've
>>>>> seen someone asking this recently but I don't remember where. Is it also 
>>>>> obligatory
>>>>> for me to do the pairing/onboarding/credentials stuff aside setting them 
>>>>> through the json?
>>>>>
>>>>> Thank you,
>>>>>
>>>>> A. Lapprand
>>>>>
>>>>>
>>>>> Em qui, 21 de dez de 2017 às 15:11, Rami Alshafi <
>>>>> ralsh...@vtmgroup.com> escreveu:
>>>>>
>>>>>> That’s a mistake! Thanks for pointing that out! I will fix it. The
>>>>>> “1” at the beginning should not be there J
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Rami
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Arthur Barros Lapprand [mailto:a...@cin.ufpe.br]
>>>>>> *Sent:* Thursday, December 21, 2017 8:02 AM
>>>>>> *To:* Rami Alshafi <ralsh...@vtmgroup.com>
>>>>>> *Subject:* Re: FW: [dev] Android SECURED mode
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just noticed the sample you linked has "rowneruuid":
>>>>>> "132323232-3232-3232-3232-323232323232" in the pstat section. Is
>>>>>> there an explanation to that "1" at the beginning of the id? shouldn't it
>>>>>> be the same as the client's id?
>>>>>>
>>>>>> Thanks again,
>>>>>>
>>>>>> A. Lapprand
>>>>>>
>>>>>>
>>>>>>
>>>>>> Em qui, 21 de dez de 2017 às 10:18, Arthur Barros Lapprand <
>>>>>> a...@cin.ufpe.br> escreveu:
>>>>>>
>>>>>> Hi Rami,
>>>>>>
>>>>>> Sorry for the delayed answer. I'm pretty overcrumbed these days so I
>>>>>> can't test it right now, but the email was very useful! Like I said to 
>>>>>> the
>>>>>> others I'll give feedback once I manage to test those suggestions.
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> A. Lapprand
>>>>>>
>>>>>>
>>>>>>
>>>>>> Em ter, 19 de dez de 2017 às 15:42, Rami Alshafi <
>>>>>> ralsh...@vtmgroup.com> escreveu:
>>>>>>
>>>>>> Arthur,
>>>>>>
>>>>>> I meant to send this e-mail to you but I just learned it did not make
>>>>>> to you. Hopefully, this one will.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Rami
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Wouter van der Beek (wovander) [mailto:wovan...@cisco.com]
>>>>>> *Sent:* Tuesday, December 19, 2017 5:22 AM
>>>>>> *To:* Rami Alshafi <ralsh...@vtmgroup.com>
>>>>>> *Subject:* RE: [dev] Android SECURED mode
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is email is now on the dmtools reflector and not on the iotivity
>>>>>> reflector..
>>>>>>
>>>>>> Hence Arthur can’t see this email
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Rami Alshafi [mailto:ralsh...@vtmgroup.com
>>>>>> <ralsh...@vtmgroup.com>]
>>>>>> *Sent:* 18 December 2017 18:43
>>>>>> *To:* Wouter van der Beek (wovander) <wovan...@cisco.com>;
>>>>>> dmtools...@members.openconnectivity.org
>>>>>> *Subject:* RE: [dev] Android SECURED mode
>>>>>>
>>>>>>
>>>>>>
>>>>>> Arthur,
>>>>>>
>>>>>> Please reference my sample applications at
>>>>>> https://gerrit.iotivity.org/gerrit/#/c/22513/
>>>>>> <https://urlf.duocircle.io/?url=https%3A%2F%2Fgerrit.iotivity.org%2Fgerrit%2F%23%2Fc%2F22513%2F&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513689724&msgid=99c3285a-e4bf-11e7-8fcd-5f906d21262c&html=1&h=b068c5c2>
>>>>>>
>>>>>> For convenience, I will explain the server’s SVR database.
>>>>>>
>>>>>> There are 4 main sections which are ACL, Pstat, Doxm and Cred.
>>>>>>
>>>>>> Assuming your client cannot onboard devices, the server\device needs
>>>>>> to be in RFNOP state which is reflected in the following settings.
>>>>>>
>>>>>> The ACL must have an ACE giving the client the right permissions
>>>>>>
>>>>>>                 Aceid: whatever number
>>>>>>
>>>>>>                 Subject: set it to {“uuid”: The uuid of the client}
>>>>>>
>>>>>>                 Resources: information of the resource like its href
>>>>>> and interface and resource type.
>>>>>>
>>>>>>                 Permission: this is bitmask
>>>>>>
>>>>>> Set the rowneruuid of the ACL to the uuid of the client
>>>>>>
>>>>>> In the pstat section, set the dos.s to 3 and isop to true and cm to 0
>>>>>> and the rowneruuid to the uuid of the client
>>>>>>
>>>>>> In the doxm section, set the owned flag to true and the devowneruuid
>>>>>> and rowneruuid to the uuid of the client.
>>>>>>
>>>>>> Assuming you want to use the “justworks” security model, set the cred
>>>>>> section like in the sample applications.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Rami
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:*dmtools...@members.openconnectivity.org [
>>>>>> mailto:dmtools...@members.openconnectivity.org
>>>>>> <dmtools...@members.openconnectivity.org>] *On Behalf Of *Wouter van
>>>>>> der Beek (wovander)
>>>>>> *Sent:* Monday, December 18, 2017 2:38 AM
>>>>>> *To:* dmtools...@members.openconnectivity.org
>>>>>> *Subject:* [OCF dmtools_tg] FW: [dev] Android SECURED mode
>>>>>>
>>>>>>
>>>>>>
>>>>>> FYI
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:*iotivity-dev-boun...@lists.iotivity.org [
>>>>>> mailto:iotivity-dev-boun...@lists.iotivity.org
>>>>>> <iotivity-dev-boun...@lists.iotivity.org>] *On Behalf Of *Tonny Tzeng
>>>>>> *Sent:* 17 December 2017 08:16
>>>>>> *To:* Max Kholmyansky <max...@gmail.com>
>>>>>> *Cc:* iotivity <iotivity-dev@lists.iotivity.org>
>>>>>>
>>>>>>
>>>>>> *Subject:* Re: [dev] Android SECURED mode
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> We just posted an article at 01.org
>>>>>> <https://urlf.duocircle.io/?url=https%3A%2F%2F01.org%2Fblogs%2Fttzeng%2F2017%2Fsecurely-accessing-iot-devices-based-javascript&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=7e525f59>
>>>>>>  talking
>>>>>> few security concept in IoTivity. Though we were using iotivity-node as 
>>>>>> an
>>>>>> example, I think the following steps would get your Client accesses to 
>>>>>> the
>>>>>> Server securely:
>>>>>>
>>>>>> (1) your Server need to register the resource with
>>>>>> ResourceProperty.SECURE flag in order to use the secured endpoint;
>>>>>>
>>>>>> (2) allow the "auth-crypt" connection requests in the SVD dB;
>>>>>>
>>>>>> (3) use an Onboarding Tool to establish ownership with both the
>>>>>> Client and the Server;
>>>>>>
>>>>>> (4) mutual install the credentials of each other by pairing the
>>>>>> devices with the OBT
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Tonny
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 17 December 2017 at 14:38, Max Kholmyansky <max...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Arthur,
>>>>>>
>>>>>>
>>>>>>
>>>>>> You should be able to communicate between the client and the server
>>>>>> on Android, using SECURED=1 library.
>>>>>>
>>>>>>
>>>>>>
>>>>>> First, to set your "di" (client or server) - you need to specify the
>>>>>> "di" value inside the DAT file (containing security information) - you 
>>>>>> can
>>>>>> look at the samples. I never succeeded with setting the "di" using API, 
>>>>>> and
>>>>>> I don't know if it's supported.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Second, even using SECURED=1, in the server, you can allow any client
>>>>>> (even not authenticated) to access any resource.
>>>>>>
>>>>>> The relevant ACL entry looks like: (you may need to change the
>>>>>> "aceid"):
>>>>>>
>>>>>> {
>>>>>>
>>>>>>     *"aceid"*: 5,
>>>>>>     *"subject"*: { *"conntype"*: *"anon-clear" *},
>>>>>>     *"resources"*: [
>>>>>>         { *"href"*: *"*" *}
>>>>>>     ],
>>>>>>     *"permission"*: 14
>>>>>> }
>>>>>>
>>>>>> This is definitely not the way to configure it in production, but it 
>>>>>> should allow you to keep developing, without caring about access 
>>>>>> permissions for a while.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Max
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 14, 2017 at 8:54 PM, Arthur Barros Lapprand <
>>>>>> a...@cin.ufpe.br> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have a few beginner-leveled questions about secure mode in Android.
>>>>>> Let me explain the situation:
>>>>>>
>>>>>> I have created two apps (one for Server/Controlee and the other for
>>>>>> the Client/Controller) and I'm able to FIND and GET/POST/OBSERVE them
>>>>>> without problems. As this is a simple example, I now want to do the same
>>>>>> things but with SECURED=1. I should note that I am usually running both
>>>>>> apps in the same device (not the emulator, but my cellphone).
>>>>>>
>>>>>> So I started looking everywhere and discovered I could do this with a
>>>>>> local ACL and supposedly everything would be ok. Turns out it didn't, 
>>>>>> which
>>>>>> is why I am here. So my questions are:
>>>>>>
>>>>>> - Do I need anything else to use the SECURED flag in Android apart
>>>>>> from registering resource as secure and passing the ACL to the
>>>>>> PlatformConfig and configure it?
>>>>>>
>>>>>> - I read that when configuring the Platform with an ACL the DeviceID
>>>>>> should be set with the ID inside it. So as it failed I tried debugging 
>>>>>> the
>>>>>> ID, which led me to confusion about PlatformID and DeviceID. When loading
>>>>>> the ACL the DeviceID comes as a random byte[]. However, I can set the
>>>>>> DeviceID in the code and retrieve it just fine. The thing is, the ID
>>>>>> recieved by the Client (ServerID) isn't the same I set in the code. I'm 
>>>>>> not
>>>>>> sure if it's something about the encoding tricking me or if it's 
>>>>>> something
>>>>>> else. Can someone please shed me some light?
>>>>>>
>>>>>>
>>>>>>
>>>>>> In short, the Client can find the resources (they are registered with
>>>>>> SECURE type) but can't make a correct GET/POST/OBSERVE request, returning
>>>>>> UNAUTHORIZED_REQ. Any tips about this flag and Android are welcome.
>>>>>>
>>>>>> Sorry for the long post, thank you in advance!
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> iotivity-dev mailing list
>>>>>> iotivity-dev@lists.iotivity.org
>>>>>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>>>>>> <https://urlf.duocircle.io/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=0ab5454f>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> iotivity-dev mailing list
>>>>>> iotivity-dev@lists.iotivity.org
>>>>>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>>>>>> <https://urlf.duocircle.io/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=0ab5454f>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
_______________________________________________
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

Reply via email to