Closed craigmulligan closed 7 years ago
All secrets are in plain text currently for simplicity but I'll salt em later.
Connects to #14
Hi @craig-mulligan,
I don't have experience with mongoose, but as far as I can see, this is what I had in mind.
In addition to what you store in the your client (or subscription) it would be good to fetch the user information with the SDK and place it also in the subscription. For this you have the getCurrentUserInfo.
This would be needed (in addition to recording some metadata for each data item that points to the device device which generated each peace of data stored in the data-api) to enforce who has access to which data item.
Yea, I can add user info too, thanks for checking it out.
Oh question, why do we have to set the id
when creating a client entity? Is it important? Also I'm not use the callback so can I just pass null?
Identity Management does not impose a particular schema for IDs, since in general different components (device manager, data api, or any other component creating entities) could have already generated its own ID, e.g. for devices that is the case. So, to remain agnostic from this, IDM always requires the external component using it to determine the id. You can pass null as the callback if you don't plan to use it. That is fine.
Hey @nopbyte, mind having a look if I am understanding the client creation part? Basically what I do is:
When creating a subscription (a job that polls the agile api and store's data) if you pass a token, we will create an idm client entity, then when we run that job, we authenticate with that client and request data from they api with that new clients authenticated token. Am I on the right track?