APIKey Authentification missing for /transit/Departures v8 - here-api

I am having trouble using the "Next Departures" call as described here:
https://developer.here.com/documentation/public-transit/api-reference-swagger.html
I clearly states that an authentification via APIKey should be possible, however I always get an
"Bearer token invalid. Bearer missing or bearer value missing."
All other calls to the api work fine with my APIKey methode, also if I generate a Bearer Token and use this, it works. However generating a Token that expires for just this call, is not my preferred method.
As the documentation also includes the APIKey method, I guess this is a bug, or I am doing something wrong?
Thanks

You need to enter “&apikey” (all small letters) and it will work.

Related

Why Doesn't my Authorization Header need "Bearer"?

I am currently working with a group of applications that are running on two separate, but equivalent, environments (Referred to as ENV1 and ENV2). I have been using OAuth 2.0 for Authorization and when I receive a response after requesting an access token from the OAuth service (I am making my requests through Postman) I get a response that looks like this from ENV1 and ENV2:
As far as I am aware, I believe that this "token_type": "Bearer" means that when I send in the access_token to my application I need to do so like this:
By sending in the token through the Authorization header, prefixed with "Bearer". This approach works fine on ENV1 but on ENV2 the request fails unless I send in the token alone with no "Bearer" prefix:
If I send in the Authorization header with the "Bearer" prefix, I get a 401 Unauthorized error as the response. This is the help tip that Postman provides(Emphasis mine):
Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
The problem here is that there IS a WWW-Authenticate header field, and it contains "Bearer", which I would assume is a "challenge applicable to the requested resource" seeing as the token response contained "token_type": "Bearer":
Questions:
Why would this be different between environments?
How is this even possible? The documentation I have found on OAuth 2.0 shows that the "Bearer" prefix is needed for requests like the ones I am trying to make. (for example, in section 2.1 of the documentation here)
From your description, it seems that the environments are not actually identical. E.g. maybe ENV2 is behind a gateway that adds the Bearer prefix to the header. Or the API on ENV2 (or the gateway) is configured to read the header without the prefix.
When the OAuth Server returns the access token, it gives you the type - a bearer token. That type means, that the token is just this - a bearer token - as opposed to a Proof-of-Possession token. When you send a bearer token to an API, you don't have to provide any additional information that would prove that you are the owner of the token. (you can compare bearer with the DPoP standard)
The Bearer Token Usage standard does require you to use the prefix Bearer in the authorization header (as you pointed out), but it doesn't mean that all the APIs and gateways implement that standard correctly, or that they use that standard at all.
To summarize:
it's up to the gateway/API to decide in what format they want the Authorization header, and that has nothing to do with the type of the token (a bearer token). It's nice when they use standards, but they don't have to.
In your setup, there must be some kind of difference between the environments if the same request is treated differently between them. If you own the environments you should investigate what is configured differently. If you don't own them, you should contact the owner's support to solve the issue.

Using Bearer Token In modheader

I know modheader extension allows us to modify the header of a request. And as such we can handle authorization use cases by specifying Token. But what I've seen so far is the use of basic tokens. My question is : Does modheader allow us to specify Bearer Token as in tools like Postman or Thunder Client ? If Yes then how to do it ? Thanks for any hint
It works using the header Name "Authorization" and the value "Bearer YOURTOKEN"
Header configuration

Bearer token invalid on here fuel prices API even though apikey is included as parameter

I am new to Here and am trying to make my first API call but I keep getting back this error:
{"Type":"Unauthorized","Message":["Bearer token invalid. Bearer missing or bearer value missing."]}
Here's the URL that I'm using to call the API:
https://fuel-v2.cc.api.here.com/fuel/stations.json?apiKey=${hereApiKey}&prox=${lat},${lng},1600
I have also tried including the api key in an authorization header and get the exact same thing. I've tried with apikey= and apiKey= and the results are the same. I've also tried moving the apikey param to after the prox param (though I know that shouldn't matter). I feel like I'm following the documentation when it says that I can use api key authentication for this call and that app code authentication is deprecated, so I'm not sure what I'm doing wrong.
I am currently on a Here Freemium plan and making this call from a Node JS server application.
The token expires in 24 hours, you need to generate a new token and test again
In order to use OAuth token authentication please use the below request
https://fuel-v2.cc.ls.api.here.com/fuel/stations.xml?prox=52.516667,13.383333,5000
And in header please include
Authorization = Bearer "Oauth token"
other way to include the token is -
https://developer.here.com/documentation/fuel-prices/dev_guide/topics/request-here-environments.html

HERE.com Places API, "ApiKey is missing" error message, but it isn't

I've tried the below request (with two different proper API keys), on the HERE Places API, but I get an auth error.
Request:
https://places.sit.ls.hereapi.com/places/v1/autosuggest
?at=40.74917,-73.98529
&q=chrysler
&apiKey=g51V9*****N4-_GTA
Response:
401
{
"error": "Unauthorized",
"error_description": "ApiKey is missing."
}
I've also tried OAuth, I can get the request token, but when I use this for the places request I get an HTML webpage (for HERE place API) as the response, rather than an expected JSON or XML reponse.
Is anyone able to get any of the example requests to work for Places API?
I had this issue before aswell. Trying the exact same request as you, in Postman with my own apiKey, made the request successfull.
Try making the URL a single line, there might be newline characters hidden somewhere.
This has solved this issue for me many times using this API.
Example:
https://places.sit.ls.hereapi.com/places/v1/autosuggest?at=40.74917,-73.98529&q=chrysler&apiKey=g51V9*****N4-_GTA
You need to check the key name it may wrong
you should check it out into the documentation of api. and see key name
try key name apikey or api_key or api-key instead of apiKey
https://places.sit.ls.hereapi.com/places/v1/autosuggest
?at=40.74917,-73.98529
&q=chrysler
&apikey=g51V9*****N4-_GTA
Please refer to this guide for the updated list of domains to use with apiKey.
For places, the domain is: places.ls.hereapi.com
Disclosure: I'm a product manager at HERE Technologies
In my case I was using : https://github.com/julianshen/gin-limiter with the provided example

Withings API No Response on request_token

I have setup everything as described in the steps in answer to the post withings api authentication.
However, when i copy and paste the final URL generated in Step 2 (Send request to the URL:), I get no response on my browser and the screen remains empty.
Is there any reason for why it might be happening ?
OAUTH TOKEN and OAUTH SECRET - will I get two of them appended to callback url ?
Each paramter string was supposed to be URL encoded in signature i.e URLEncoder.encode("key=value","UTF-8")
I have used temboo API to get the user tokens.
They have two steps Initial oauth and final oauth.

Resources