Wagtail-API: html_url does not include port - wagtail

I am passing the html_url through href. However, since it does not include the port 8000, the request is rejected (err: "localhost refused to connect.").
get-request: json
"items": [
{ "id": 3,
"meta": { "type": "home.HomePage",
"detail_url": "http://localhost/api/v2/pages/3/",
"html_url": "http://localhost/",
"slug": "home",
"first_published_at": "2018-02-11T03:08:18.344199Z"
},
"title": "Home"
}]
Is there a way to include my port?

Related

Returning 404 error when asking for userboostrap in microservices

I'm trying to develop microservices on cumulocity.
I'm following this https://cumulocity.com/guides/microservice-sdk/java/.
I'm able to create the application having this response
"availability": "MARKET",
"id": "23",
"key": "TESTMICRO-microservice-key",
"manifest": {
"imports": [],
"noAppSwitcher": true
},
"name": "TESTMICRO",
"owner": {
"self": "my_tenant/tenant/tenants/management",
"tenant": {
"id": "management"
}
},
"requiredRoles": [
"ROLE_INVENTORY_READ"
],
"roles": [
"ROLE_CUSTOM_MICROSERVICE"
],
"self": "my_tenant/application/applications/23",
"type": "MICROSERVICE"
}
Nevertheless when I try the GET URL/application/applications/23/bootstrapUser it returns me 404 Error.
Anyone that can help me?
You probably need to subscribe the application to the tenant:
POST {{url}}/tenant/tenants/{{tenant}}/applications
Body
{
"application": {
"id": "{APPLICATION_ID}"
}
}

Non-Primitive Values from a Registered Content Provider are not showing a value

I'm using the /v2/registrations endpoint to register a content provider with the legacyForwarding flag being set. Therefore my Content Provider is offering the v1/queryContext endpoint
When I am returning a simple value (Integer, String etc.) such as a temperature the data is added to the context correctly:
{
"contextResponses": [
{
"contextElement": {
"attributes": [
{
"name": "temperature",
"type": "Number",
"value": 27
}
],
"id": "urn:ngsi-ld:Store:001",
"isPattern": "false",
"type": "Store"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
However when trying to return an array of strings as shown from a Context Provider.
{
"contextResponses": [
{
"contextElement": {
"attributes": [
{
"name": "tweets",
"type": "Array",
"value": [
"String 1",
"String 2"
]
}
],
"id": "urn:ngsi-ld:Store:002",
"isPattern": "false",
"type": "Store"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
I can see the request being sent in the log and I can retrieve the following entity:
{
"id": "urn:ngsi-ld:Store:002",
"type": "Store",
"address": {
"type": "PostalAddress",
"value": "",
"metadata": {}
},
"location": {
"type": "geo:json",
"value": "",
"metadata": {}
},
"name": {
"type": "Text",
"value": "Checkpoint Markt",
"metadata": {}
},
"tweets": {
"type": "Array",
"value": "",
"metadata": {}
}
}
As you can see the "tweets" value is blank, but the attribute exists and the type has been successfully received.
My question is how should I return an Array or an Object as a value from a Content Provider so that Orion is able to display the data received correctly?
Further investigation from the Orion Team shows that this was indeed a bug and an issue was raised against Orion 2.0.0. With the latest release, the bug has now been fixed.
The solution is to upgrade to a later version of Orion - currently 2.1.0 (at the time of writing)

Send workflow information to custom connector

I need help with sending workflow information in header/body of calls to custom connector. I am trying to load a drop down list in one of the parameters of a logic app using values returned from an API call. The API end point requires basic workflow information such as the resource group and workflow name which are normally available in headers of http requests from logic app execution.
Normally when I use #{workflow().name} in logic app's json, it is substituted with the workflow name. In case of custom connector, the WDL syntax is passed as is without any transformation.
Here is a simplified swagger json with all relevant sections.
{
"swagger": "2.0",
"info": {
"title": "{{dynamicHostName}}",
"version": "1.0.0"
},
"host": "{{dynamicHostName}}",
"basePath": "/",
"schemes": [
"https"
],
"paths": {
"/sftpsource": {
"post": {
"operationId": "SftpSource",
"summary": "Sftp as source system",
"description": "Use Sftp as source system",
"produces": [
"application/json"
],
"consumes": [
"application/json"
],
"parameters": [
{
"name": "params",
"in": "body",
"required": true,
"schema": {
"type": "object",
"properties": {
"hostName": {
"type": "string",
"x-ms-summary": "Host Name",
"x-ms-visibility": "advanced"
},
"portNumber": {
"type": "string",
"x-ms-summary": "Port Number",
"x-ms-visibility": "advanced"
},
"userName": {
"type": "string",
"x-ms-summary": "User Name",
"x-ms-visibility": "advanced"
},
"password": {
"type": "string",
"x-ms-summary": "Password",
"x-ms-visibility": "advanced"
},
"filePath": {
"type": "string",
"x-ms-summary": "File Path"
},
"system": {
"type": "string",
"x-ms-visibility": "advanced",
"x-ms-summary": "System",
"x-ms-dynamic-values": {
"operationId": "GetTaggedSystems",
"parameters": {
"workflow-name": "#{workflow().name}"
},
"value-path": "systemId",
"value-title": "systemName"
}
}
}
}
}
],
"responses": {
"202": {
"description": "Request is queued"
},
"500": {
"description": "Server Error"
}
}
}
},
"/taggedSystems" : {
"get": {
"operationId": "GetTaggedSystems",
"summary": "Tagged Systems",
"x-ms-visibility": "advanced",
"description": "Get all systems tagged to this flow",
"parameters": [
{
"name": "workflow-name",
"in": "header",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"description": "OK",
"schema": {
"$ref": "#/definitions/TaggedSystems"
}
},
"202": {
"description": "Work is still in progress"
},
"500": {
"description": "An error occured while trying to fetch tagged systems."
}
}
}
}
},
"definitions": {
"TaggedSystems": {
"type": "array",
"items": {
"type": "object",
"properties": {
"systemId": {
"type": "string"
},
"systemName": {
"type": "string"
}
},
"required": [
"systemId",
"systemName"
]
}
}
}
}
You can have an internal parameter defined as header/body where you can pass dynamic expressions of what you need from the workflow environment at the time of execution of the flow.
For complete information regarding the flow, you can pass #{workflow()} as an internal parameter.
Hope it helps.

How to avoid loading attachments data from Gmail Rest API get message

How to avoid loading attachments data from Gmail Rest API with get message request.
Using the fields parameter at least we can avoid loading few fields but when I want to load message body, attachment data also coming along with body just like IMAP
You don't get the attachment like you do in IMAP. You get an attachmentId which you have to use in an additional request to get the attachment.
I just sent a message with an attached image to myself. This is what the response from the API looks like:
{
"id": "1573ec1aa0976b42",
"threadId": "1573ec1aa0976b42",
"labelIds": [
"SENT",
"INBOX",
"IMPORTANT",
"UNREAD"
],
"snippet": "",
"historyId": "939514",
"internalDate": "1474226662000",
"payload": {
"mimeType": "multipart/related",
"filename": "",
"headers": [ ... ],
"body": {
"size": 0
},
"parts": [
{
"mimeType": "multipart/alternative",
"filename": "",
"headers": [
{
"name": "Content-Type",
"value": "multipart/alternative; boundary=94eb2c0d3cba8637a2053ccd2461"
}
],
"body": {
"size": 0
},
"parts": [
{ ... },
{
"partId": "1",
"mimeType": "image/png",
"filename": "Screen Shot",
"headers": [ ... ],
"body": {
"attachmentId": "ANGjdJ-bmCvsIaV-4KfALXzVV_D567w4i6ksLnwIZhLAl3VXCE335663UbmOLC_vbLrCFusNtnWVpdTv3i88uR482kFwLZqAcwmI7C5gFlamob2aK4-lqAPlCZs17jtCQR9y5Mt4nnpP_Kg64N9qgXbDF0E2vYnEw4xwtEKEo4fRIAbc94ZjjfynFD832mh1B37XFMt-bYw9wkNv24xBife0koBNYpKs-gGLJkfu2EoZouqunGDX9ry1jq2jW2AClWcFXPXvgRBMjUcoRDPtvb9LLLrBhDjU1hu6r1Ibc3c2BSoBogT8QyIp2VUCuFU",
"size": 1511996
}
}
]
},
"sizeEstimate": 1513185
}
As you can see, it just contains an attachmentId and no actual attachment data.

Why is attachmentId missing in payload/parts/body from certain emails?

I'm using the gmail API to first generate a list of all attachments, and then download the attachments on demand.
I'm basically calling GET https://www.googleapis.com/gmail/v1/users/me/messages/{ID}?key={YOUR_API_KEY} on all message ids that have an attachment, and then grabbing all the attachmentIds to use with the messages.attachments API later. This works for the majority of my attachments, but I notice for certain emails, the attachment ID is missing.
Heres an example response (with certain parts omitted) from such one of those emails:
{
"id": "114fda8b3fe57cb1",
"threadId": "114fda8b3fe57cb1",
"labelIds": [
"INBOX"
],
"snippet": "",
"historyId": "1027074",
"payload": {
"mimeType": "multipart/mixed",
"filename": "",
"headers": [
],
"body": {
"size": 0
},
"parts": [
{
},
{
"partId": "1",
"mimeType": "image/jpeg",
"filename": "IMG_3746.JPG",
"headers": [
{
"name": "Content-Type",
"value": "image/jpeg; name=\"IMG_3746.JPG\""
},
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "Content-Disposition",
"value": "attachment; filename=\"IMG_3746.JPG\""
},
{
"name": "X-Attachment-Id",
"value": "f_1ydodxn"
}
],
"body": {
"size": 447292 <------ Here is where I would expect attachmentId to be...
}
},
{
}
]
},
"sizeEstimate": 2873869
}
Here's what the parts/body looks like from a response from a message that has everything I expected:
"body": {
"attachmentId": "ANGjdJ9CRk8VcuxPzOMnGhFQdJpB6vc7xNAZTw5Gav3jZRQkEi3lRvELnjUTEqQtpiJDkKx8IR3qEOyT0wW6LD_tQ3NvPWDucURPaW0xUBJm8gwP-De9hOt7DbciRdfYCX79JWoHtGS2cooTzpAfZwYXc2lmcjCeL_SvgCZAtIEOVs45atTOsx9BCb02aJzNAvga2f3OdsBNbUkCyyZWQZGB0bHQf4q30BmoDFLrBhq67k3f5VOpOxsFl4QDLS5Md-JxhbQ1qsFk_usEUvcOqFsNgckmtj6y0zrKyDDc8g",
"size": 536
}
I can't use GET messages/attachments without the attachmentId... whats going on? What am I missing?
Looks like that was an issue with some older attachments. Should be resolved now.
In my case (using API in Python) the attachmentId was never in the body.
I went here:
https://developers.google.com/gmail/api/reference/rest/v1/users.messages/get
to use "Try this method" window
and I found the attachmentId in parts[1].body

Resources