Recently some registrations of commands expired so I am trying to patch their "expires" attribute. However, I receive a 405 method not allowed message error.
Retrieving info about the registration:
curl -X GET \
http://localhost:1026/v2/registrations/5d3ff3e2ab1e270d7775a7bf \
-H 'Accept: application/json'
{
"id": "5d3ff3e2ab1e270d7775a7bf",
"expires": "2019-08-29T07:38:10.00Z",
"dataProvided": {
"entities": [
{
"id": "urn:ngsi-ld:ActuatorScreenshot:001",
"type": "Actuator"
}
],
"attrs": [
"Screen"
]
},
"provider": {
"http": {
"url": "http://localhost:4041"
},
"supportedForwardingMode": "all",
"legacyForwarding": true
},
"status": "active"
}
I attempted following the example from http://telefonicaid.github.io/fiware-orion/api/v2/stable/:
curl -X PATCH \
http://localhost:1026/v2/registrations/5d3ff3e2ab1e270d7775a7bf \
-d '{
"expires":"2040-10-04T00:00:00"
}'
But as I said I got the error message:
405 Method Not Allowed
Feel free to ask for more info.
The operation to modify registrations has not been yet implemented in Orion 2.2.0 (last version in the moment of writing this). As mentioned in Orion documentation:
Orion implements registration management as described in the NGSIv2
specification, except for the following aspects:
List item PATCH /v2/registration/<id> is not implemented. Thus, registrations cannot be updated directly. I.e., updates must be done
deleting and re-creating the registration. Please see this
issue about
this.
However, the workaround is pretty simple: delete the old registration and create a new one with the modified parameters.
Related
Edit: The checks are successfully populated when run on: pull_request
When I set the event that triggers my workflow to
on:
pull_request
then the checks are automatically populated. I was running it with workflow_dispatch before.
Original question below
When running a GitHub Action workflow, each job that runs automatically publishes a check. I can verify this with the checks endpoint of the REST API
curl \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer TOKEN"\
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/OWNER/REPO/commits/REF/check-runs
This returns an object like
{
"total_count": 3,
"check_runs": [
{
"id": 9950586881,
"name": "deploy",
"status": "completed",
"conclusion": "success",
...
},
{
"id": 9950580659,
"name": "api-test",
"status": "completed",
"conclusion": "success",
...
},
{
"id": 9950580441,
"name": "ui-test",
"status": "completed",
"conclusion": "success",
...
},
]
}
I set these exact status checks ([deploy, ui-test, api-test]) as required passing before merging.
However, those status checks never get updated in the pull request UI (even though they are there in the REST API call...)
However, when I go to GitHub desktop, it shows that those status checks are there (and passing!)
For anyone else looking at this problem, I found that the workflow_dispatch event type was not sufficient to actually populate checks on the PR. Instead, I had to use the pull_request event type. Now it works.
We use Orion to register subscriptions. There are two kinds of subscriptions in our application:
user subscriptions: they are created by the user using our GUI.
internal subscriptions: they are used by the system for communication between the components.
The problem is to distinguish the two, in order to present the user with only user-oriented subscriptions.
Which field of the subscriptions can I use? It would be nice to have a field "type", for instance.
I agree with what Jose Manuel says, it would be a really nice feature.
In addition to his reply, in the meantime I think you can use "metadata" field in subscriptions for distinguish between user subscriptions and internal subscriptions. Just have in mind that this field is not supposed for this purposes and its kind a "dark" way to implement the behavior that you want.
Here is an example of a subscription creation with my approach. In this case you create a subscription with the metadata field "isInternal" that just tells you that this is an internal subscription. Then you can use another different metadata field as a token, just to identify a user subscription:
curl -X POST \
http://localhost:1026/v2/subscriptions \
-H 'Content-Type: application/json' \
-d '{
"description": "A subscription to get info about Room1",
"subject": {
"entities": [
{
"id": "Room1",
"type": "Room"
}
],
"condition": {
"attrs": [
"temperature"
]
}
},
"notification": {
"http": {
"url": "http://localhost:1028/accumulate"
},
"attrs": ["temperature"],
"metadata": ["isInternal"]
}
}'
For more information about metadata field in subscriptions and his normal use please refer to this documentation.
In the future probably it would be nice to open the possibility to extra fields in a subscription (application defined) and to be able make queries over subscriptions (something which cannot be currently done).
A solution could be to make use of the description field associated to subscription to distinghuish between both types.
I have made this subscription but it notifies always a attribute is changed.
curl --include \
--header 'Content-Type: application/json' \
--request POST \
--data-binary '{
"attrsFormat":"legacy",
"description": "Day subscription",
"subject": {
"entities": [
{
"idPattern": "es-leon-.*",
"type": "Event"
}
],
"condition": {
"attrs": [
"idEvent",
"Title",
"dFlag"
],
"expression": {
"q": "dFlag>0"
}
}
},
"notification": {
"http": {
"url" : "http://localhost:5050/notify"
},
"attrs": [
"idEvent",
"Title",
"dFlag"
]
}
}' \
'http://localhost:1026/v2/subscriptions'
I want that orion notify when any attribute described in the condition is changed AND the condition is satisfied.
Example I have in orion this entitys:
Concert1 (idEvent=Mozart, Title=Mconcert, dFlag=1)
Concert2 (idEvent=Salieri, Title=Sconcert, dFlag=0)
I want that when I made a change to any attribute of Concert1, as the condition is satisfied, it will notify.
In the case of Concert2, as the condition is not satisfied, it will not notify.
Is it posible? what I have wrong in this subscription example?
In the documentation do not said much:
condition: Condition that will trigger the notification. It can have
two optional properties:
attrs: array of attribute names
expression: an expression composed of q, georel, geometry and coords (see "List entities" operation above about this field).
List entities
q: A query expression, composed of a list of statements separated by ;, i.e. q=statement;statements;statement. See Simple Query Language specification. Example: temperature>40.
Version de orion: 1.1
This could be due to a problem in subscriptions cache management in Orion 1.1. So, the solution in that version is to disable cache using -noCache CLI option.
The bug has been identified (see this issue in github) and solved for Orion 1.2.
Would like to know how to authenticate to (for example):
http://www.example.com:8080/openam/UI/Login?realm=CUR&module=CURAuthn
preferably by POSTing JSON via REST over /json/authenticate.
I'm guessing it would be http://www.example.com:8080/openam/UI/Login?realm=CUR&authIndexType=module&authIndexValue=CURAuthn correct?
In any case this module doesn't take the standard X-OpenAM-Username or X-OpenAM-Password headers.
It takes a bunch of custom fields, called ID tokens. For instance it uses IDToken1, IDToken2, IDToken3, ...
How should I go about submitting the tokens to this plugin using the json authentication service? Thanks
All this is explained in the OpenAM's Developer's Guide section 3.4.
The REST URL for your custom module would be:
http://www.example.com:8080/openam/json/authenticate?authIndexType=module&authIndexValue=CURAuthn
If you module doesn't use the standard username/password credentials you'll have to pass your credentials in the request body as JSON.
You would start by sending a empty POST request to OpenAM:
$ curl \
--request POST \
--header "Content-Type: application/json" \
http://www.example.com:8080/openam/json/authenticate?authIndexType=module&authIndexValue=CURAuthn
You should get a response similar to this (based on your custom callbacks):
{
"authId": "eyAid...GDYaEQ",
"template": "",
"stage": "Module11",
"header": "Using CURAuthn",
"callbacks": [
{
"type": "NameCallback",
"output": [
{
"name": "prompt",
"value": "FirstCallback"
}
],
"input": [
{
"name": "IDToken1",
"value": ""
}
]
},
{
"type": "NameCallback",
"output": [
{
"name": "prompt",
"value": "SecondCallback"
}
],
"input": [
{
"name": "IDToken2",
"value": ""
}
]
},
//More callbacks here
]
}
After that just collect the credentials from the user input, fill in the empty values and submit the JSON payload back to the same URL. Make sure you use the same "authId" throughout the authentication process.
I wrote a blog post about custom authentication chains and how to communicate with them via REST. Take a look, it might be helpful.
I am using the FIWARE IoT agent [1] to communicate with my devices using MQTT protocol, I create a command to be able to update my device value, Here is my request to create a device:
curl -X POST http://193.48.247.247:80/iot/devices \
-i \
-H "Content-Type: application/json" \
-H "Fiware-Service: egmsmartcity" \
-H "Fiware-ServicePath: /egmsmartcitypath" \
-d ' { "devices": [ { "device_id": "streetlight1",
"entity_name": "sensors:streetlight1",
"entity_type": "sensors",
"protocol": "PDI-IoTA-MQTT-UltraLight",
"timezone": "Europe/Paris",
"endpoint": "notUsed",
"commands": [{ "name": "streetlight1", "type": "command", "value": ""}] } ] }'
Since I am using MQTT, the filed endpoint is not used on my case but if I delete it the MQTT does not notify my device.
This request is working but is it the correct way to create a device to be able to send a command to my device via MQTT?
Thanks in advance for your help!
[1]https://github.com/telefonicaid/fiware-IoTAgent-Cplusplus
This field ("endpoint": "notUsed") comes from a previous functionality that is no longer implemented (it did not make sense in MQTT). Thus since recent versions onwards it is ignored and can be deleted. Perhaps you are using a previous version of the IoT Agent and this is why it is mandatory although not functional.
Thanks for using IDAS!