Hi Rami, I have looked the fopen() functions and I'm currently in doubt on how to do it in Java since I'm only passing the ACL dat file when configuring OcPlatform. Also, is your sample released in IoTivity 1.3.1 (couldn't find it) or is it for a future update?
Thank you, A. Lapprand Em ter, 26 de dez de 2017 às 22:15, Arthur Barros Lapprand <a...@cin.ufpe.br> escreveu: > Ohhhhh, I see! That should help me understand the issue. Will look into it! > > Thank you, > A. Lapprand > > Em Ter, 26 de dez de 2017 22:06, Rami Alshafi <ralsh...@vtmgroup.com> > escreveu: > >> Nope! Device_properties and introspection are completely separate things >> and not related. You do not need the introspection file for solving your >> error and the Unauthorized_req issue. >> >> Thanks, >> >> -Rami >> >> >> >> *From:* Arthur Barros Lapprand [mailto:a...@cin.ufpe.br] >> *Sent:* Tuesday, December 26, 2017 4:48 PM >> *To:* Rami Alshafi <ralsh...@vtmgroup.com> >> *Cc:* Morrow, Joseph L <joseph.l.mor...@intel.com>; Tonny Tzeng < >> tonny.tz...@gmail.com>; iotivity <iotivity-dev@lists.iotivity.org>; >> Matthews, Michael L <michael.l.matth...@intel.com> >> >> >> *Subject:* Re: [dev] FW: Android SECURED mode >> >> >> >> Hi Rami, >> >> Yes indeed, I'll have a look at it and try to implement as soon as I can. >> If the device properties file is the same as the introspection file Joseph >> mentioned before, which I believe it is, then all the better! For now I >> need some sleep. Thank you all and be back soon! >> >> Best regards, >> >> A. Lapprand >> >> >> >> 2017-12-26 21:16 GMT-03:00 Rami Alshafi <ralsh...@vtmgroup.com>: >> >> Arthur, >> >> I think I know what’s up!! This seems to be a symptom of a problem I had >> before! It is related to the device properties dat file. >> >> If this is the case then what is happening is your server and client dat >> files are perfectly fine but your fopen() function in the server and/or >> client expects to see the server/client svr file but instead it gets the >> device properties dat file and thinks it is a corrupted server/client svr >> file and then it will over write the good server/client svr file with >> another that is no good either. >> >> >> >> If this is the case, then reference the ServerFOpen(const char *path, >> const char *mode) function in my server app and the ClientFOpen(const char >> *file, const char *mode) function in my client app and implement them in >> your apps. Next, run your server and it will generate a >> device_properties.dat file. Copy that file to where the client app is >> running from and then run your client application. >> >> >> >> Let me know if that fixes your problem >> >> Thanks, >> >> -Rami >> >> *From:* Arthur Barros Lapprand [mailto:a...@cin.ufpe.br] >> *Sent:* Tuesday, December 26, 2017 4:02 PM >> *To:* Morrow, Joseph L <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 (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 >> <https://urlf.duocircle.io/?url=http%3A%2F%2Fwww.cbor.me&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1514332948&msgid=38e74fda-ea99-11e7-8127-5bff9d28ac92&html=1&h=1b1d6909>. >> 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 >> <https://urlf.duocircle.io/?url=http%3A%2F%2Fcbor.me&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1514332948&msgid=38e74fda-ea99-11e7-8127-5bff9d28ac92&html=1&h=0235c6ff>” >> 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
