here.com API credentials failure - here-api

Solved - answer below
I just signed up for a trial account with here.com, registered an app, and tried using the credentials. I'd used this exact same request before with the demo app id, and credentials but now with the registered trial account credentials it's failing. Any advice? Does it take a long time for the credentials to actually become valid?
curl -X GET \
-H 'Content-Type: *' \
--get 'https://route.cit.api.here.com/routing/7.2/calculateroute.json' \
--data-urlencode 'waypoint0=53.011766,-2.224905' \
--data-urlencode 'waypoint1=53.028236,-2.198126' \
--data-urlencode 'mode=fastest;car;traffic:enabled' \
--data-urlencode 'app_id=<valid app id>' \
--data-urlencode 'app_code=<valid app code>' \
--data-urlencode 'departure=2016-09-10T13:54:29Z' | jsonpipe | less
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 528 100 528 0 0 2191 0 --:--:-- --:--:-- --:--:-- 2200
/ {}
/response {}
/response/_type "ns2:RoutingServiceErrorType"
/response/type "SystemError"
/response/subtype "SystemError"
/response/details "These credentials do not authorize access. Please contact your customer representative or submit a request here https://developer.here.com/contact-us to upgrade your account. You can also get valid credentials by registering for a free trial license on https://developer.here.com."
/response/metaInfo {}
/response/metaInfo/timestamp "2016-09-09T14:06:15Z"
/response/metaInfo/mapVersion "8.30.63.156"
/response/metaInfo/moduleVersion "7.2.72.0-55447"
/response/metaInfo/interfaceVersion "2.6.25"

Eventually consistent database somewhere, about an hour later it started working.

I was getting this issue when trying to invoke the weather services from Tibco Rest plugin using invokerestapi activity. Though I was using app_id and app_code generated from the project setup in here site with free plan. This issue got resolved when I used the demo app_id and demo app_code provided in the examples of the same site.

Related

How do I access Firestore using CURL with an API Key and service account token?

I am trying to access my Firestore database using cURL from a terminal session. I have read through the REST API documentation for Firestore and the Authentication documentation for authenticating Oauth and services accounts. I have set up a services accounts and IAM roles in API dashboard. I cannot determine from the documentation what the correct path and syntax and what do use for the API Key and the BEARER token. For example, I am trying to receive a json response for the USER xyz, document field FNAME that is stored in a Firestore DATABASE (note - where do i find the the databaseID?) that is in PROJECT testproject.
Here is the CURL command lists in the documentation -
curl \
'https://firestore.googleapis.com/v1beta1/%5BNAME%5D?key=[YOUR_API_KEY]' \
--header 'Authorization: Bearer [YOUR_ACCESS_TOKEN]' \
--header 'Accept: application/json' \
--compressed
curl --request POST \
'https://firestore.googleapis.com/v1beta2/%5BNAME%5D:exportDocuments?key=[YOUR_API_KEY]' \
--header 'Authorization: Bearer [YOUR_ACCESS_TOKEN]' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{}' \
--compressed
Questions are - what do I use for the [YOUR_API_KEY] ?
What do I use for the [YOUR ACCESS TOKEN] -
I have tried the following from credentials for a Service account that I set up
Service account - Key - 3......................e76
Unique ID - 1............39
for the API KEY and the ACCESS TOKEN and get a 403 error back
I also have a Oauth credentials -
Client ID - 2.....113-95.......cpqrarqb.....qnrpc.apps.googleusercontent.com
Client Secret - L......lq
PATH
https://firestore.googleapis.com/v1/projects/{project_id}/databases/{database_id}/collectionGroups/{collectionId}/fields/{field_id}
Which didn't work either...
Again, I am trying to access and read and write data to my Firestore database using CURL - as a proxy for what will be my REST API's. Any help and assistance much appreciated.
From the curl commands you have pasted I understand that you want to export your firestore collections to a Cloud Storage bucket. Furthermore I understand you obtained the curl commands from the api explorer of the exports method.
To provide an api key value to [YOUR_API_KEY], you first need to create an api key in your GCP project; here is the process:
Go to the credentials section.
Click on the option at the top called 'Create Credentials'.
Select API key.
Copy and keep safe the value thrown by the Cloud Console (this is your api key).
If you want to know more about API keys, you can visit this.
To provide an oauth token value, you can do the following:
You can open Cloud Shell.
Run command gcloud auth application-default print-access-token.
Copy and keep safe the value thrown by Cloud Shell (this is your oauth token).
Please note that there are several ways to create an oauth token but the one I specified is the fastest one. You may also use the oauth playground to generate your token; keep in mind that the token is valid for 60 minutes.
As per the database id I have used (default) and here I include my curl statement:
curl --request POST \
'https://firestore.googleapis.com/v1/projects/[PROJECT_ID]/databases/(default):exportDocuments?key=[YOUR_API_KEY]' \
--header 'Authorization: Bearer [YOUR_ACCESS_TOKEN]' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{"collectionIds":["users"],"outputUriPrefix":"gs://[BUCKET_PATH]"}' \
--compressed

How to POST to Wordpress with Basic Auth using (ba)sh cURL?

1. What I'm trying
I'm trying to POST to my Wordpress website with (bash) cURL but what seems to be not working is the user authorization.
So far, what I've been attempting is
curl \
-u ${USERNAME}:${PASSWORD} \
-X POST \
-H "Content-Type: application/json" \
-d '{"title": "this is a test"}' \
--url http://mywebsite.com.br/wp-json/wp/v2/posts/
2. What I get
{
"code": "rest_cannot_create",
"message": "Sorry, you are not allowed to create posts as this user.",
"data": {"status": 401}
}
What am I doing wrong? Maybe the -u flag is not the one I'm looking for? That's what I usually try when using BasicAuth; is it not the case here? Is the wp-json specification correct?
In the question, I'm using Basic Authentication, which actually needs to be enabled.
You can do it by downloading the WP Basic Auth Plugin from Github and then uploading, installing and activating it within your Wordpress website.
Once that's done, the question's code should work fine.

How to get the http request to work on my browser

I am using the here-api to get a 7 day forecast for my application. When I copy and paste the code onto my browser from the Here documentation using my app-code and app-id, it says that my app-id and app-code are invalid. I am wondering why this is happening since i have an account with Here and am using the code they provided.
I have already tried switching them.
https://weather.api.here.com/weather/1.0/report.json
?app_id={xxxxxx}
&app_code={xxxxxx}
&product=forecast_7days_simple
&latitude=41.83
&longitude=-87.68
When i enter this request i expected json in return but instead get a page that says my code is invalid. I am using safari but have tried chrome and i still get the same problem
Make sure to remove the curly brackets around the credentials, and to remove newlines (if any) that were added in the documentation for readability.
If you do have valid credentials, the following request should work:
https://weather.api.here.com/weather/1.0/report.json?app_id=xxxx&app_code=yyyy&product=forecast_7days_simple&latitude=41.83&longitude=-87.68
Use the query like below. For any query you can use the swagger here . And, from the "view code" button you can download either the curl or the jQuery snippet.
curl \
-X GET \
-H 'Content-Type: *' \
--get 'https://weather.api.here.com/weather/1.0/report.json' \
--data-urlencode 'product=forecast_7days_simple' \
--data-urlencode 'latitude=52.516' \
--data-urlencode 'longitude=13.389' \
--data-urlencode 'oneobservation=true' \
--data-urlencode 'app_id={YOUR_APP_ID}' \
--data-urlencode 'app_code={YOUR_APP_CODE}'

Academic Knowledge Cognitive Services Labs API error 500

I have obtained API keys for the Cognitive Services Labs by Microsoft here, but when I try using the example provided in the API "Try me" page for the graphSearch method, I get a 500 server error after about 20 seconds. Other API endpoints (interpret, evaluate) seem to be working well. Here's my query (also tried via the "Try me" page):
export SERVER=api.labs.cognitive.microsoft.com
curl "https://${SERVER}/academic/v1.0/graph/search?mode=json" \
-H "Host: ${SERVER}" \
-H 'Content-Type: application/json' \
-H "Ocp-Apim-Subscription-Key: ${API_KEY}" \
--data '{"path":"/paper/AuthorIDs/author","paper":{"type":"Paper","NormalizedTitle":"graph engine","select":["OriginalTitle"]},"author":{"return":{"type":"Author","Name":"bin shao"}}}'
I've written an inquiry via the Cognitive Services UserVoice portal but with no answer so far. The service is not listed in the Azure Status page.
I want to know whether my query or account registration is faulty, or is this a temporary problem. Should be easy to answer.

How to add a post via WordPress REST API with publish date in the future?

I want to add a new post to a WordPress site and set a publishing date in the future using the WordPress 4.7 REST API and bash, curl and the JSON-Tool "jq" on the client side. I have added the basic-auth plugin to WordPress so that I can use this type of authentication.
I initially upload the posting like this:
curl -s --location --basic --user 'name:password' \
--url "https://<server>/wp-json/wp/v2/posts" \
-d "title=Testpost" -d "content=This is a new post." | \
jq -r '"id: \(.id), date: \(.date), status: \(.status), title: \(.title.raw)"'
> id: 45, date: 2017-02-07T10:10:31, status: draft, title: Testpost
Ok, this is as expected. Let's see whether changing the post works:
curl -s --location --basic --user 'name:password' \
--url "https://<server>/wp-json/wp/v2/posts/45" \
-d "title=Other title" | \
jq -r '"date: \(.date), status: \(.status), title: \(.title.raw)"'
> date: 2017-02-07T10:20:32, status: draft, title: Other title
Ok, works.
Now I want to publish the post at 3 PM ("curl" parameters shrunk as they do not change):
curl ... "/wp-json/wp/v2/posts/45" \
-d "date=2017-02-07T15:00:00" | \
jq -r '"id: \(.id), date: \(.date), status: \(.status)"'
> id: 45, date: 2017-02-07T10:29:32, status: draft
Nope. Date changed to the moment the request was issued, not the requested publishing date. Ok, perhaps status "pending"?
curl ... "/wp-json/wp/v2/posts/45" \
-d "status=pending" -d "date=2017-02-07T15:00:00" | \
jq -r '"id: \(.id), date: \(.date), status: \(.status)"'
> id: 45, date: 2017-02-07T10:36:24, status: pending
Well, state is set to "pending", but date is still wrong. Perhaps explicitly setting the state to "future"?
curl ... "/wp-json/wp/v2/posts/45" \
-d "status=future" -d "date=2017-02-07T15:00:00" | \
jq -r '"id: \(.id), date: \(.date), status: \(.status)"'
> id: 45, date: 2017-02-07T10:36:48, status: publish
WHAT??? What is happening here? Now, the post is published with the current date. Precisely what I did not want to have.
But if I now, with the published post, reissue the same request
curl ... "/wp-json/wp/v2/posts/45" \
-d "status=future" -d "date=2017-02-07T15:00:00" | \
jq -r '"id: \(.id), date: \(.date), status: \(.status)"'
> id: 45, date: 2017-02-07T16:00:00, status: future
...it does the job - at least to some extent. Somehow, the time is interpreted as UTC, but finally the post is correctly set into "future" state.
Question 1: How do I get the post into this state without having it published in the first place?
Question 2: Why is the date interpreted as UTC? Wouldn't that be "date_gmt"?
What am I missing here?
Ok, I think I got the status stuff (question 1).
Solution:
You can change the publishing date to something in the future by setting the post status to private intermediately. The following two commands change the draft's publish date to some future point of time without a premature publishing:
curl ... "/wp/v2/posts/45" -d "status=private"
curl ... "/wp/v2/posts/45" -d "status=future" -d "date=2017-02-07T15:00:00"
Explanation:
Ok, and why is that? It's a feature of the WordPress core which prevents the intended operation. Let's dig through it:
The REST API is implemented below wp-includes/rest-api/endpoints. For handling posts, the code is class-wp-rest-posts-controller.php. Updating a post is handled by update_item() beginning in line 670 (in WP 4.7.2).
That function does not do that much. Mainly, it calls wp_update_post() in the WordPress core. That method is implemented in wp-includes/post.php, starting in line 3534 (sic!).
Not far after the method start we find the troublesome lines of code:
// Drafts shouldn't be assigned a date unless explicitly done so by the user.
if ( isset( $post['post_status'] ) &&
in_array($post['post_status'], array('draft', 'pending', 'auto-draft')) &&
empty($postarr['edit_date']) &&
('0000-00-00 00:00:00' == $post['post_date_gmt']) )
$clear_date = true;
else
$clear_date = false;
And this is the problem: All data checked here are the already stored information of the post. Even if I transfer a new status future with my update request through the REST API, it is not evaluated at this place. $clear_date is set solely from the information in the database. And as our post is inserted as a draft and all the other conditions match, too, it will always be true which leads the method to drop all updates to the date fields some lines further. So, there is no way to change the publish date of the post as long as the post's state is one of draft, pending or auto-draft. The core simply overwrites all intended changes to the publishing date with what it feels is "right".
The solution, as written at the beginning of this reply, is to change the post's state intermediately to private. That status does neither trigger any publishing actions nor is it on the "special handling list" of wp_update_posts(). Therefore, we can change the date in a second step - and then also update the state so that the post will be published.
I feel that this is after all a bug. In my opinion, the critical part of wp_update_post() should take the new post status of an update into consideration and leave the new date untouched if the new state is (at least) one of published or future.

Resources