I am testing the here.com location REST API. I have setup REST oAuth credentials in the developer portal and have successfully requested an oAuth token via Postman. When I try to use the token in the fuel prices API, I receive the error:
"These credentials do not authorize access"
oAuth POST request:
Authorization: OAuth oauth_consumer_key="wD7h-u8jE03c0jRu2m4XBQ",oauth_signature_method="HMAC-SHA256",oauth_timestamp="1600812281",oauth_nonce="npygZT9FJ9f",oauth_version="1.0",oauth_signature="fM6AsYnp9jKHlY6ESyKwUwqIHQik4ad6spUeiWAh2ag%3D"
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: 169bc9d1-5ef6-46e6-aab8-d0d11d048d15
Host: account.api.here.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Request Body
Response Headers
Date: Tue, 22 Sep 2020 22:04:42 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 911
Connection: keep-alive
Pragma: no-cache
X-Request-ID: REQ-b62ce9c9-eddd-4c03-8e67-186a56c031b1
Cache-Control: no-store
X-Frame-Options: DENY
X-Response-Time: 53
X-Correlation-ID: e0c4b375-8fed-4b70-be56-2d78c6f37e18
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
X-Permitted-Cross-Domain-Policies: master-only
Response Body
{"access_token":"eyJhbGciOiJSUzUxMiIsImN0eSI6IkpXVCIsImlzcyI6IkhFUkUiLCJhaWQiOiJaVjhwbGFFWDdRekd2VUNXbUdGbiIsImlhdCI6MTYwMDgxMjI4MiwiZXhwIjoxNjAwODk4NjgyLCJraWQiOiJqMSJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1qVTJRMEpETFVoVE5URXlJbjAuLk8tRDdJQm9Mdzk5b1dxejJ1Vmx0Y1EuSmlYUmMwV0N6cVFUbVFicmhNaDNONkFENVJ6YWVMenFfdWpOWVZlekgyQ2dvbERLcFFEcUNrODFlMWFoMmlZZXZXZzFHNVhDZUtsZEc0WXhwX0pSU2lPaUkxUUNMRWZhakFscEFHQjdta0JLdjktbXllXzlqeDFGbzM2T0tUaDRuNXdxWEZVbnhtMkRYOHRQYjVZZUZBLl9qUlE0NU9PTmd3ZHpwY1c4cUxJck5hRmhYcTVLM1hzMHZzYl85MTFtVVU.R62C1fZVxt29r0VPA9jYVdWRbqO5lFH0yNtomCSxAnpTaHf4ed215u7o21RnwEjy-Dl2vgCAP8Oc4xNN4uoi2ImzwRtdtDU8y3wqOYHakRXyuP5PdvKejjpB1MAmw8TYVQkTfrfsgG972wo2g_0jx3VzmcOXJSl8wHU5y3rdEgNG-vDvV1wlJwQDX6ZKc2FLSzk1yEv9NSsAYur21PrnBfMImaenvGzEh1J747HmUfrHOPr-wRPvTQE4GNiOf4hWKXJrnPwpg85S_S8EZgGqlRVfNQ4V2g_7LfH1ZjFxiZrd8oZFPbnAI1ihDSBqaTy04HXotXsyp92YzDhVHwDavw","token_type":"bearer","expires_in":86399}
Get request to fuel REST API
GET https://fuel-v2.cc.ls.api.here.com/fuel/stations.json?prox=36.0029435,%20-78.9059841&fueltype=1
Request Headers
Authorization: Bearer eyJhbGciOiJSUzUxMiIsImN0eSI6IkpXVCIsImlzcyI6IkhFUkUiLCJhaWQiOiJaVjhwbGFFWDdRekd2VUNXbUdGbiIsImlhdCI6MTYwMDgxMjI4MiwiZXhwIjoxNjAwODk4NjgyLCJraWQiOiJqMSJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1qVTJRMEpETFVoVE5URXlJbjAuLk8tRDdJQm9Mdzk5b1dxejJ1Vmx0Y1EuSmlYUmMwV0N6cVFUbVFicmhNaDNONkFENVJ6YWVMenFfdWpOWVZlekgyQ2dvbERLcFFEcUNrODFlMWFoMmlZZXZXZzFHNVhDZUtsZEc0WXhwX0pSU2lPaUkxUUNMRWZhakFscEFHQjdta0JLdjktbXllXzlqeDFGbzM2T0tUaDRuNXdxWEZVbnhtMkRYOHRQYjVZZUZBLl9qUlE0NU9PTmd3ZHpwY1c4cUxJck5hRmhYcTVLM1hzMHZzYl85MTFtVVU.R62C1fZVxt29r0VPA9jYVdWRbqO5lFH0yNtomCSxAnpTaHf4ed215u7o21RnwEjy-Dl2vgCAP8Oc4xNN4uoi2ImzwRtdtDU8y3wqOYHakRXyuP5PdvKejjpB1MAmw8TYVQkTfrfsgG972wo2g_0jx3VzmcOXJSl8wHU5y3rdEgNG-vDvV1wlJwQDX6ZKc2FLSzk1yEv9NSsAYur21PrnBfMImaenvGzEh1J747HmUfrHOPr-wRPvTQE4GNiOf4hWKXJrnPwpg85S_S8EZgGqlRVfNQ4V2g_7LfH1ZjFxiZrd8oZFPbnAI1ihDSBqaTy04HXotXsyp92YzDhVHwDavw
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: d5d3944f-4c5c-44ef-8eb4-0202a4d669c0
Host: fuel-v2.cc.ls.api.here.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Response Headers
Content-Encoding: gzip
Content-Type: application/json
Date: Tue, 22 Sep 2020 22:11:15 GMT
Server: nginx-clojure
Vary: Accept-Encoding,Origin
X-HERE-RESPONSE-TIME: 0
Content-Length: 99
Connection: keep-alive
Response Body
{"Type":"Forbidden","Message":["These credentials do not authorize access"]}
Unfortunately, currently the Freemium plan doesn't have an access to Connected vehicle services https://developer.here.com/documentation#cvs
On https://developer.here.com/documentation/fuel-prices/dev_guide/topics/credentials.html you can see:
There are two kinds of credentials:
Development credentials - these credentials are for evaluation and
development. To obtain your development credentials, contact your
customer/sales representative and sign the appropriate evaluation
agreements.
Production credentials - these credentials are for commercial
deployment. To obtain your commercial credentials, sign the
appropriate commercial agreements. You must have completed all
testing, be ready for deployment and have signed a commercial
agreement before you apply for production credentials.
You can also read this Knowledge Base What other HERE Location Services limits apply to my Freemium or Pro plan? - there the information about Connected vehicle services will be added later.
I'm attempting to create a bridge between another service (as a data source) and Microsoft Power BI. However, I can't get the REST API to work properly.
So far I've succeeded in creating a web application in Azure AD, getting the Client ID and secret, receiving an access token for the API, but after this all I get is 403 Forbidden with no error message. However, if I try to access the API with an expired token, I get an error message telling me that the token is expired.
I've read some posts on the subject, but they all suggest that the REST API cannot be accessed without having a user log in and access Power BI first, which isn't possible in a service-to-service application.
How do I properly access the service without any user interaction?
Here are the requests and responses, censored a little bit.
Request 1:
POST /[our domain].com/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: flight-uxoptin=true; stsservicecookie=ests; x-ms-gateway-slice=productiona; stsservicecookie=ests
Host: login.microsoftonline.com
Connection: close
User-Agent: Paw/2.3 (Macintosh; OS X/10.11.3) GCDHTTPRequest
Content-Length: 203
grant_type=client_credentials&client_id=[client id]&client_secret=[client secret]&resource=https%3A%2F%2Fanalysis.windows.net%2Fpowerbi%2Fapi
Response 1:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
x-ms-request-id: 52d6713c-d50b-4073-b030-aa10e33fdf27
client-request-id: 3aef4765-d602-46a6-a8ce-4b7792f678e5
x-ms-gateway-service-instanceid: ESTSFE_IN_209
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: x-ms-gateway-slice=productiona; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/
X-Powered-By: ASP.NET
Date: Wed, 24 Feb 2016 08:24:29 GMT
Connection: close
Content-Length: 1243
{"token_type":"Bearer","expires_in":"3599","expires_on":"1456305870","not_before":"1456301970","resource":"https://analysis.windows.net/powerbi/api","access_token":"[access token]"}
Request 2:
GET /v1.0/myorg/datasets HTTP/1.1
Authorization: Bearer [access token]
Content-Length: 0
Host: api.powerbi.com
Connection: close
User-Agent: Paw/2.3 (Macintosh; OS X/10.11.3) GCDHTTPRequest
Response 2:
HTTP/1.1 403 Forbidden
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: deny
X-Content-Type-Options: nosniff
RequestId: 803cc0cb-c65d-4212-9ab8-aed4ffa9862a
Date: Wed, 24 Feb 2016 08:25:13 GMT
Connection: close
The APIs you're using require a user's access token. They access content in a user's account. So if you don't have the access token, you'll keep getting forbidden. So what you need to do is get the access token with the user the first time. Then store the refresh token. Then use the refresh token to get new access tokens as needed. If the refresh token expires, you need to ask the user to sign in again.
What do I set in Paw to allow for a login? I have tried to use the allow cookies with to no avail.
I am working through this tutorial on Github to learn the MEAN stack. Sign up seems to be working but sign in is not.
Sign up request is:
GET /auth/success HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: connect.sid=s%3A6q22s9GpNRDITB3wKBoxS1emnKCcIR3B.pI3dzqqtSBSBVgkzl7Uib4aqNAf%2Bh5iszoWDMzWPpR8
Host: localhost:3000
Connection: close
User-Agent: Paw/2.2.2 (Macintosh; OS X/10.10.3) GCDHTTPRequest
and the result is:
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 121
ETag: W/"79-56130229"
Date: Thu, 18 Jun 2015 19:52:43 GMT
Connection: close
{"state":"success","user":{"username":"admin","password":"$2a$10$AD5NBc6c6iZ09/eXuYd9oOfTEZ6MnRNYWneLy.SNPFAWf/HX1V0.6"}}
The user is created. But the login request fails every time; the request is:
GET /auth/failure HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: connect.sid=s%3A6q22s9GpNRDITB3wKBoxS1emnKCcIR3B.pI3dzqqtSBSBVgkzl7Uib4aqNAf%2Bh5iszoWDMzWPpR8
Host: localhost:3000
Connection: close
User-Agent: Paw/2.2.2 (Macintosh; OS X/10.10.3) GCDHTTPRequest
the response is:
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 72
ETag: W/"48-ed4f121"
Date: Thu, 18 Jun 2015 19:53:03 GMT
Connection: close
{"state":"failure","user":null,"message":"Invalid username or password"}
What it comes down to is: Is there something in paw that needs to be enabled to allow sign in testing or is my code more likely to be the problem? My code is almost verbatim from the module three part of that Github repo linked above. Any and all help would be appreciated.
Note: I did not post code on purpose as to not clutter the question. If you need to see something I can add it just let me know.
While I was not sure of my exact error I had with more trouble shooting i saw that you need to make sure that you have follow redirects on and cookies being saved.
---I have been experimenting on cookies/ session ids and have a little trouble digesting in the concepts.
I'm working on a Debian distro. Using Burp to capture/alter requests/ responses. What I know is below.
a. Cookies get stored in the client machine database at /root/.mozilla/firefox/pya18ecc.default/cookies.sqlite. In the moz_cookies table. I'm using sqlite3 to access the database.
b. Session variables are getting stored in /var/lib/PHP5 on the server.
The PHP code on the SERVER is below
<?php
require_once 'login.php';
$connection = new mysqli($db_hostname,$db_username,$db_password,$db_database);
if($connection->connect_error) die ($connect->connect_error);
if (isset($_SERVER['PHP_AUTH_USER']) &&
isset($_SERVER['PHP_AUTH_PW']))
{
$username = mysql_entities_fix($connection,$_SERVER['PHP_AUTH_USER']);
$password = mysql_entities_fix($connection,$_SERVER['PHP_AUTH_PW']);
$query = "SELECT * FROM user WHERE username = '$username'";
$result = $connection->query($query);
if(!$result) die ($connection->error);
elseif ($result->num_rows)
{
$row = $result->fetch_array(MYSQLI_NUM);
$result->close();
$salt1="!##$";
$salt2="$##!";
$token = hash('ripemd128',"$salt1$password$salt2");
if($token == $row[3])
{
session_start();
$_SESSION['username'] = $username;
$_SESSION['password'] = $password;
$_SESSION['forename'] = $row[0];
$_SESSION['surname'] = $row[1];
echo "$row[0] $row[1] : Hi '$row[0]' you are logged
in as '$row[2]'";
die("<p><a href = continue.php> CLICK HERE TO CONTINUE</a></p>");
}
else {die("Invalid Username/ Password Combination");}
}
else
{
die("Invalid Username/ Password Combination");
}
}
else
{
header('WWW-Authenticate: Basic realm="Restricted Section"');
header('HTTP/1.0 401 Unauthorized');
die("Please enter your username and password to Login");
}
$connection->close();
function mysql_entities_fix($connection,$var)
{
return htmlentities(mysql_entities_string($connection,$var));
}
function mysql_entities_string($connection,$var)
{
if (get_magic_quotes_gpc()) $var = stripslahes($var);
return $connection->real_escape_string($var);
}
?>
When I send in the request(1), it lookes like this.
request(1)
GET /ses3.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
The response(1) is a login page (Basic HTTP authentication)
response(1)
HTTP/1.0 401 Unauthorized
Date: Sat, 28 Mar 2015 07:27:44 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.36-0+deb7u3
WWW-Authenticate: Basic realm="Restricted Section"
Vary: Accept-Encoding
Content-Length: 48
Connection: close
Content-Type: text/html
Please enter your username and password to Login
----Till here there has no exchange of session ids or cookies. (If I'm wrong, prompt me ?)
I responded with the username and password and the request(2) is
request(2)
GET /ses3.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Authorization: Basic YnNtaXRoOm15c2VjcmV0
---- On forwarding the above request what I observe is that I've received the Session id: cl5mi7tbhdnobpv8kkau7thjo6 in the /var/lib/PHP5 even before forwarding the response(2). That's because Server
has created the same and is ready to fowrward it in the response (2)
The response(2) is
response(2)
HTTP/1.1 200 OK
Date: Sat, 28 Mar 2015 07:36:13 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.36-0+deb7u3
Set-Cookie: PHPSESSID=cl5mi7tbhdnobpv8kkau7thjo6; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must- revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 117
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
Bill Smith : Hi 'Bill' you are logged
in as 'bsmith'<p><a href = continue.php> CLICK HERE TO CONTINUE</a></p>
----Now on checking SELECT * FROM moz_cookies, I'm not seeing any cookies which are getting saved on the client m/c. So where are they getting saved ? (This is my first question)
Next I've deleted the session variable "cl5mi7tbhdnobpv8kkau7thjo6" from the server and again have hit the
refresh button on the client's browser. The request(3)/ response(3) are below
request(3)
GET /ses3.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: PHPSESSID=cl5mi7tbhdnobpv8kkau7thjo6
Authorization: Basic YnNtaXRoOm15c2VjcmV0
Connection: keep-alive
Cache-Control: max-age=0
response(3)
HTTP/1.1 200 OK
Date: Sat, 28 Mar 2015 07:50:01 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.36-0+deb7u3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 117
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
Bill Smith : Hi 'Bill' you are logged
in as 'bsmith'<p><a href = continue.php> CLICK HERE TO CONTINUE</a></p>
-----Now the Server has again got the same session variable set under the /var/lib/PHP5. Shouldn't the server not recognize the session variable ? Also if this is happening because of the saved Cookies, then why isn't I'm able to see them under moz_cookies table ..... Please explain ?(This is my second question)
A few items to consider:
Cookies can be stored on disk or in memory. How they are stored is dependent on browser settings (.e.g Private Browsing mode in Firefox) and server settings (see PHP docs on session handling).
HTTP connections can be cached using the Keep-Alive header.
It looks like you are set up to store session ids on the server in a file, but the browser cookie is being stored in memory rather than in a file, which is why you are seeing the PHP file but not a Firefox cookie file.
As to why the server is recognizing the session id even though you deleted the file, it looks like what is happening is that PHP knows the session is authenticated, meaning it must be cached in RAM on the server. (A PHP guru might be able to fill in the specifics of the session mechanics).
After receiving request 3, PHP looks for the session id file and when it doesn't see it, it writes the file again because it knows that the session is valid. This is expected behavior, because if you want to delete the session, you as a PHP programmer should be doing it in PHP rather than deleting the session id file behind the scenes.
You'll notice that the client sent the session id with request 3. The client will send the session id cookie with each request, but the server should not respond with the Set-Cookie instruction again during this session. The browser now has the session id cookie and can send it with each request, thus no further authentication is needed.
The weakness to this strategy is that it could leave open the possibility of session hijacking. If an attacker could obtain the session id cookie from your browser, they could execute commands against the server using your credentials.
Obtaining the session id may or may not be a trivial task for an attacker depending on many factors. If for instance the victim's computer is compromised with a virus or other malware controlled by the attacker, the attacker probably pwns the victim's computer at that point and can do whatever they want, including taking the session id. Other attacks use cross-site scripting ( XSS ) attacks to trick the victim's browser into divulging the session id.
There are specific defenses against XSS and session hijacking, again the subject is fairly complex and worth researching in detail. A more secure session, for instance, might use a one-time token that is changed with every response, although that strategy can be complicated by the use of asynchronous HTTP calls.
Till here there has no exchange of session ids or cookies. (If I'm wrong, prompt me ?)
No, that's correct. Until here, session_start hasn't been called, so there are no session cookies to exchange.
Now the Server has again got the same session variable set under the /var/lib/PHP5. Shouldn't the server not recognize the session variable ?
It probably should, but it isn't. What I think is happening: When a client sends a session id, the server is happy to use it, even if it doesn't know it yet. This can (in theory) be used for session fixation, which is why it is recommended to regenerate ids each time something in the session changes (in practice, session.use_trans_sid is set to 0 by default, which makes session fixation less of an issue).
What I find odd is that the data is also still there (I couldn't replicate this behavior). My guess would be that you are actually re-submitting the form?
Also if this is happening because of the saved Cookies, then why isn't I'm able to see them under moz_cookies table
My guess is that the cookies are still in the browser memory. Did you try the same thing, but deleting the cookie via the browser interface?
Misc
I know that this is just a test script, but still:
prepared statements are recommended over simple escaping.
don't store plaintext passwords in sessions).
don't echo user input unsanitized.
hashes should be user specific, not site specific.
htmlentities protects against XSS, not SQL injection, and should thus be applied when echoing data, not when inserting it into the database.
I've a DotnetOpenAuth authorization server which works great on my localhost. However after publishing it my refresh access token request is blocked.
The request for a accesstoken, with success
POST https://myurl/identity/oauth/token HTTP/1.1
Authorization: Basic dsjSDLFJKSKLJesww
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: DotNetOpenAuth.Core/4.2.1.13026
Host: myhost
Cache-Control: no-store,no-cache
Pragma: no-cache
Content-Length: 86
Expect: 100-continue
Connection: Keep-Alive
username=theusername&password=fancypassword&scope=somescope&grant_type=password
The refresh request:
POST https://myurl/identity/oauth/token HTTP/1.1
Authorization: Basic dsjSDLFJKSKLJesww
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: DotNetOpenAuth.Core/4.2.1.13026
Host: myhost
Cache-Control: no-store,no-cache
Pragma: no-cache
Content-Length: 272
Expect: 100-continue
refresh_token=_ttH%21IAAAAGiYhlufAaXURH5P2oDOnPYgJx7YhoR33isvZkPPvlyUgQAAAAHoBYyDMLhq1qwGHHH2uGrLoHZli77XHbCnSFJSKLFJ3kl2j3klj2kljKFSJKLSJKL#$k3ljfsklfjl2
And the response:
Technical Information (for support personnel)
Error Code: 403 Forbidden. The server denied the specified Uniform
Resource Locator (URL). Contact the server administrator. (12202)
Any help, guidelines, pointers in any direction, would be very much appriciated!
I changed the url/username/password/scope/base64/refreshtoken for this example.
Their seems to be a setting in the TMG Forefront - Authentication Delegation which blocked the request.
Method used by Forefront TMG to authenticate to the published Web
server:
No delegation, and the client cannot authenticate directly
No delegation, but client may authenticate directly
It was set to option 1 after changing it to 2 the request is no longer blocked!