I am interested in accessing the list of active subscriptions, but after reading all the wiki about APIs (https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide#Context_subscriptions) i haven't find any operation that allows to get the list of them.
Is there any operation to do that? Anyone can give me details about it?
The NGSI API that Orion implements doesn't include any operation to get the list of existing subscription. It is assumed that each client knows the subscription it has created and manages it, no "administrative action" to get them all has been defined by NGSI.
The only posibility with the current Orion version is to query directly the database to get that information (e.g. in a side REST server running along the Orion context broker process). Considering the data model described in the Orion documentation, it is a matter of queriying on the csubs collection.
EDIT: Orion 0.25.0 includes an operation to get a list of subscriptions in the NGISv2 API: GET /v2/subscriptions. See this document for details.
Related
I have my public API running on AWS API Gateway, and now I want to add API keys to it, basically to see "who is using which endpoint and how many time per month/week/whatever". My API already has user management logic, with its own users db table.
The part I need help with is the analytics part - say I have this up and running, I need to be able to extract some sort of report saying, for each user (by name), how many calls were made to each endpoint. So far, the closest I've gotten was https://stackoverflow.com/a/52361117/1514576 which gets me the info I need by API key. The part that I'm missing is how I could potentially cross-reference this data with my "users" database table.
I was hoping one of you had faced a similar problem and could share how you handled it.
On page https://firebase.google.com/docs/firestore/best-practices, I saw this sentence:
Keep the number of snapshot listeners per client under 100.
I read the page on 2021/02/18, and I haven't found the clear meaning of client on that page.
What does client mean? Is it a (service) account? or is it a firestore.Client object? If it is a firestore.Client object, can I use multiple firestore.Client objects as a workaround to 100 snapshot listeners per client limit?
Per the oficial documentation, it refers to the firestore.Client object,
FirestoreClient provides access to Google Cloud Firestore. Use the
API to obtain a Firestore instance, which provides methods for
updating and querying data in Firestore
Here is a question similar to yours that can enlighten you even more about the difference between Listeners and Clients and how a Client can have multiple listeners.
We're starting to migrate our Website to a REST Service based system and are in the process of developing the core right now.
In our current setup a user has one or more "accounts" assigned which define what data he can see on the website. Only one account can be active for a given user at any time. Right now we store the selected account in the database and use it to filter all queries.
Now I'm not sure how to handle this properly in a REST environment. Possible solutions I found are:
Sending the requested account with every request
Storing the current account in the auth token. (We're using JWT for that)
Having the current account stored on the server and calling a specific resource to change it
Each of these has its pros and cons for our setup. Currently we're using the 3rd approach in our Website. But what would be the correct way to handle such a thing in a REST environment?
Yea the design you are dealing with is fairly bad, and what you really want to do is remove the state completely out of this system.
For that reason the first option is by far superior:
Sending the requested account with every request
If this is simply an id, there's a very simple way to do this, just prefix all your (relevant) routes / uris with this account id. For example:
http://api.example.org/accounts/{id}/...
This way the 'state' is maintained by virtue of which url you are accessing, and the server can be unaware of the state.
Using access logging, as detailed here: https://cloud.google.com/storage/docs/access-logs, we can download and analyze usage patterns for our data. However, looking at the actual data, I noticed that there is no data relating which user (or service-account) performed the operation. The closest seeming attribute in the usage logs as described here: https://cloud.google.com/storage/docs/access-logs#format is the cs_user_agent attribute. However, this attribute seems to describe more about the tool performing the access (i.e., gsutil or gcloud) rather than the user.
Is it possible to obtain information that relates the activity to a user/service-account? Perhaps using the s_request_id attribute?
Is there a technical reason this is missing? Or is it intended as a privacy-preserving mechanism?
You can read about the access log schema in our docs. cs_user_agent tells you what kind of program made the request, while s_request_id is a unique id for the request. The closest thing to what you need would be c_ip, which is the IP address of the machine making the request. You could possibly tie those to users. If this doesn't suffice, you could have your clients make requests only through some code you yourself have written which will log - in parallel to sending the request - the URL, method, any headers / metadata desired, and the user / account making the request.
I'm having issues with entities which has subscriptions and wanted to list all of them to check which one is problematic. How can I do that?