{{api-key}} in URL about iotagent-json HOT 8 CLOSED

Hi,

Concerning the {{api-key}} question, first of all that's not exactly a URL, but a MQTT topic; and the MQTT message does not allow headers HTTP-style AFAIK. The use of the API-Key as a prefix for all the topics of a set of devices (or a service) let us easily divide the interactions for different services, allowing some degree of communication control at the broker level (e.g.: ACLs can be defined for different API-KEY prefixes, to allow security mechanisms such as credentials or certificates to authenticate the user).

About how to get the API-Key, there are two possible ways: the Agent can have one global public API-Key configured in the config.js file, as explained in the configuration section. But the common way to get an API-Key would be to create a new configuration for a service, using the Configuration API, as described in the correspondent section of the IoT Agents Library Documentation.

This IoT Agent is still in an early stage, so the documentation is still to be completed. I will try to add some examples or tutorials to make it easier.

from iotagent-json.

Hi @dmoranj,
thanks for the answer!

I thought that api-key here is a security token, but if I understand you correctly - it is not, it is like a group-id?

Regarding documentation: we here from Mainflux project are decided to do transition to Fiware. We already have Dockerized Orion in place on our cloud, and we are are playing now with IoT Agents - both LWM2M and MQTT.

What I noticed here missing for iotagent-mqtt is real concrete example - step by step in a few curl lines, using some real example (like Orion is doing in this section: http://fiware-orion.readthedocs.org/en/develop/user/walkthrough_apiv1/index.html#context-management-using-ngsi10).

If you can help us posting this it will be real speed-up.

On the other hand we will help you prepare Docker image (we'll fork the repo and send you Pull Request) as soon as we figure out how this provisioning/registration/configuration/communication works :).

from iotagent-json.

Hi,

I have already created an issue to improve the documentation, and I expect to start working on that soon; but I want to finish some requested features before creating the step-bystep guides. I'll try to move it as soon as possible.

Thanks for the help with the Docker image, BTW.

from iotagent-json.

NP,
in the meantime I'll "use the source, Luke" ;)

from iotagent-json.

Concerning contributions, we also have to update the documentation with the contribution guidelines. They will be a copy of those in the LWM2M IOTA. Please read them and take them into account while contributing. Thanks.

from iotagent-json.

Yes, thanks. We at Mainflux adhere to even stricter set of rules, IMHO - take a look here at our CONTRIBUTING.md, and I suggest that these rules for iotagent-mqtt end-up in some CONTRIBUTING.md or reference some Fiware-wide conventions.

As for Inspiration about these "administrative metadata" files, I suggest you that you take a look at Docker project, they really did it well.

Question in the end - I am not an expert, but GPLv3 assures that project is patent-free (similar to Apache-2.0). When you accept contribution for this type of projects, I think that every commit must be signed-off with Developer Certificate of Origin (we use Linux' one) - to avoid CLA's and CCLA's, so that every contributor confirms that in his best knowledge he is not introducing some patent-burdened code. This is a good read on the subject: https://www.chef.io/blog/2009/08/11/why-we-chose-the-apache-license/

from iotagent-json.

@dmoranj #88 ready for your inspection.

from iotagent-json.

Closing this issue, as it seems to be a mix of the #84 issue and the #88 both implemented and closed.

from iotagent-json.