I am currently calling a service which requires mutual authentication with curl and ubuntu, currently
I have the following certificates certRoot.cer, certSub.cer, domain.com.cer and pubkey.pem, to add the certificates to the path /etc/ssl/certs/ca-certificates.crt transform them all to a format pem and i made the call:
curl -v \
--key /etc/ssl/certs/ca-certificates.crt \
-u "user:password" \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data-raw '{"info":"data"}' \
https://endpoint.com:4445/api/path
This call itself is correct and returns the following information:
* Trying ip...
* Connected to endpoint.com (ip) port 4445 (#0)
* found 136 certificates in /etc/ssl/certs/ca-certificates.crt
* found 536 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: endpoint.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=CO,ST=STATE,L=DATA,O=DATA,OU=Sistemas,CN=endpoint.com
* start date: Tue, 03 Sep 2019 14:42:57 GMT
* expire date: Thu, 02 Sep 2021 14:42:57 GMT
* issuer: C=CO,ST=DATA,L=DATA,L=ADDRESS,O=DATA,OU=Gerencia de Sistemas,CN=DATA Sub CA Terceros
* compression: NULL
* ALPN, server did not agree to a protocol
* Server auth using Basic with user 'user'
> POST api/path HTTP/1.1
> Host: endpoint.com:4445
> Authorization: Basic dXNycHJ1X2Jpb2NyZWRpdDpQc123YmExMjM7
> User-Agent: curl/7.47.0
> Accept: application/json
> Content-Type: application/json
> Content-Length: 920
>
* upload completely sent off: 920 out of 920 bytes
< HTTP/1.1 403 Forbidden
< Date: Tue, 06 Apr 2021 21:37:21 GMT
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Content-Security-Policy: frame-ancestors 'none'
< Content-Length: 234
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /api/path
on this server.</p>
</body></html>
* Connection #0 to host endpoint.com left intact
but at the moment in which the call is verified from the api side, it indicates that the certificate was not sent and rejects the connection, I imagine that is why it returns the error 403 (forbidden).
I have also tried to do it by passing the certificates directly, but it returns this error:
curl -v \
--key pubkey.pem \
--cert domain.com.cer \
-u "user:password" \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data-raw '{"info":"data"}' \
https://endpoint.com:4445/api/path
In this case the answer is the following:
* Trying ip...
* Connected to domain.com (ip) port 4445 (#0)
* found 136 certificates in /etc/ssl/certs/ca-certificates.crt
* found 536 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* error reading X.509 key or certificate file: Error in parsing.
* Closing connection 0
curl: (35) error reading X.509 key or certificate file: Error in parsing.
I clarify that all this also happens through a vpn and the connection to this vpn is already ok, if anyone has any idea how I can solve this problem I thank you very much, it can be with using any language or terminal client.
To complete this call successfully I did it with python, then I leave the code that I use:
import socket
import ssl
host_addr = 'domain.com'
host_port = 4445
server_sni_hostname = 'domain.com'
server_cert = '../DESTINATION.cer' #CERTIFICATE OF DESTINATION, IN PEM FORMAT ( -----BEGIN CERTIFICATE----- ...... -----END CERTIFICATE----- )
client_cert = '../CUSTOMER_CERTIFICATE.cer' #CUSTOMER CERTIFICATE, IN PEM FORMAT ( -----BEGIN CERTIFICATE----- ...... -----END CERTIFICATE----- )
client_key = '../CUSTOMER_PRIVATE_KEY.key' #CUSTOMER PRIVATE KEY, IN PEM AND PKCS8 FORMAT (-----BEGIN PRIVATE KEY----- ....... -----END PRIVATE KEY-----)
basicAuthHeader = 'dXNlcjpwYXNzd29yZA==' #USER:PASSWORD >> BASE64
method = 'POST /path/of/service HTTP/1.1\r\n'
headers = 'Host:'+host_addr+'\r\nContent-Type:application/json\r\nAuthorization:'+basicAuthHeader+'\r\nAccept:application/json\r\n\r\n'
body = '{"data":"string","data1":"string","data2":"string","data3":"string","data4":"string"}'
context = ssl.create_default_context(ssl.Purpose.SERVER_AUTH, cafile=server_cert)
context.load_cert_chain(certfile=client_cert, keyfile=client_key)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
conn = context.wrap_socket(s, server_side=False, server_hostname=server_sni_hostname)
conn.connect((host_addr, host_port))
print("SSL established. ")
print("Sending:")
conn.send(bytes(method+headers+body, 'utf-8'))
print("Receiving")
received = conn.recv(36000)
print(received)
print("Closing connection")
conn.close()
I hope it will be of help to you in the future, for me it was a long task until I reached the solution.
Related
I have an HTTPS endpoint in MongoDB Realm. How can I get the values of individual query string parameters inside a function? I'm trying to use the Request object, but I can only get back the entire querystring.
Sample URL: https:///endpoint/search?param1=apple¶m2=banana
The endpoint calls the function:
exports = function(){
query = context.request.rawQueryString;
return {query};
};
A GET request to the endpoint returns:
{
"query": "param1=apple¶m2=banana"
}
How can I modify my function to get values of a named query string parameter, e.g.?
const queryParam1 = request.query.param1 would evaluate to "apple".
Thank you.
Grab the specific fields from the query object:
const {value1, value2} = query;
I believe the variable names need to match the query string parameters. For example, assume the following CURL command (notice the query string parameters):
curl --include \
--verbose \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--request POST "https://eastus2.azure.data.mongodb-api.com/app/simplewebservice-ryzao/endpoint/test?queryStringParam1=abc&queryStringParam2=123" \
--data '{ "fieldA": { "$int": "1" }, "fieldB": {"$date": "2022-09-26T22:20:17.123Z" } }'
Because I have two query string parameters I need to catch them using their specific names - queryStringParam1 and queryStringParam2. See the code listing below for a complete working function:
exports = function({ query, headers, body}, response) {
try {
if(body === undefined) {
throw new Error(`Request body was not defined.`)
}
const {queryStringParam1, queryStringParam2} = query;
console.log(queryStringParam1);
console.log(queryStringParam2);
console.log("contentTypes = " + headers["Content-Type"])
var bodyJson = EJSON.parse(body.text());
console.log(bodyJson);
var calculatedObject = new Object();
calculatedObject.queryStringParam1 = queryStringParam1;
calculatedObject.queryStringParam2 = queryStringParam2;
calculatedObject.requestPayloadFieldA = bodyJson.fieldA;
calculatedObject.requestPayloadFieldB = bodyJson.fieldB;
response.setStatusCode(200);
response.setBody(JSON.stringify(calculatedObject));
} catch (error) {
response.setStatusCode(400);
response.setBody(error.message);
console.log(error.message);
}
};
In this example, I simply repackage and reply with the same data as what was sent. The response payload combines query string variables and request payload variables into a single response payload.
Example of output:
barry#barry-laptop:~$ curl --include --verbose --header "Accept: application/json" --header "Content-Type: application/json" --request POST "https://eastus2.azure.data.mongodb-api.com/app/simplewebservice-ryzao/endpoint/test?queryStringParam1=abc&queryStringParam2=123" --data '{ "fieldA": { "$int": "1" }, "fieldB": {"$date": "2022-09-26T22:20:17.123Z" } }'
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 20.71.94.254:443...
* Connected to eastus2.azure.data.mongodb-api.com (20.71.94.254) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=data.mongodb-api.com
* start date: Aug 8 12:45:54 2022 GMT
* expire date: Nov 6 12:45:53 2022 GMT
* subjectAltName: host "eastus2.azure.data.mongodb-api.com" matched cert's "eastus2.azure.data.mongodb-api.com"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x56145e5b6e80)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> POST /app/simplewebservice-ryzao/endpoint/test?queryStringParam1=abc&queryStringParam2=123 HTTP/2
> Host: eastus2.azure.data.mongodb-api.com
> user-agent: curl/7.81.0
> accept: application/json
> content-type: application/json
> content-length: 78
>
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* We are completely uploaded and fine
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 2147483647)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200
HTTP/2 200
< vary: Origin
vary: Origin
< x-appservices-request-id: 633227f5d92f1e1d9c61bb7b
x-appservices-request-id: 633227f5d92f1e1d9c61bb7b
< x-frame-options: DENY
x-frame-options: DENY
< date: Mon, 26 Sep 2022 22:30:13 GMT
date: Mon, 26 Sep 2022 22:30:13 GMT
< content-length: 148
content-length: 148
< content-type: text/plain; charset=utf-8
content-type: text/plain; charset=utf-8
< server: envoy
server: envoy
<
* Connection #0 to host eastus2.azure.data.mongodb-api.com left intact
{"queryStringParam1":"abc","queryStringParam2":"123","requestPayloadFieldA":{"$int":"1"},"requestPayloadFieldB":{"$date":"2022-09-26T22:20:17.123Z"}}
We are receiving an error ACCESS_TOKEN_SCOPE_INSUFFICIENT when trying to run the runReport method with the Google Analytics Data GA4 API.
As you can see in the debugging dump, have all necessary scopes in the authorization to make the request:
Request:
curl -X POST -H "User-Agent: python-requests/2.27.1" -H "Accept-Encoding: gzip, deflate" -H "Accept: */*" -H "Connection: keep-alive" -H "Content-Length: 399" -H "Content-Type: application/json" -d '{"dateRanges": [{"startDate": "2022-04-25", "endDate": "2022-04-25"}], "dimensions": [{"name": "date"}, {"name": "eventName"}, {"name": "sessionDefaultChannelGrouping"}, {"name": "sessionSource"}, {"name": "source"}], "metrics": [{"name": "eventCount"}, {"name": "eventValue"}, {"name": "newUsers"}, {"name": "sessions"}], "metricFilter": null, "dimensionFilter": null, "limit": 100000, "offset": 0}' 'https://analyticsdata.googleapis.com/v1beta/properties/264786259:runReport?access_token=REMOVED'
Response
{
"error": {
"code": 403,
"message": "Request had insufficient authentication scopes.",
"status": "PERMISSION_DENIED",
"details": [
{
"#type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "ACCESS_TOKEN_SCOPE_INSUFFICIENT",
"domain": "googleapis.com",
"metadata": {
"service": "analyticsdata.googleapis.com",
"method": "google.analytics.data.v1beta.BetaAnalyticsData.RunReport"
}
}
]
}
}
further debugging dump
% curl -X POST -H 'Accept: */*' -H 'Connection: keep-alive' -H 'Content-Length: 399' -H 'Content-Type: application/json' -H 'User-Agent: python-requests/2.27.1' -d '{"dateRanges": [{"startDate": "2022-04-13", "endDate": "2022-04-13"}], "dimensions": [{"name": "date"}, {"name": "eventName"}, {"name": "sessionDefaultChannelGrouping"}, {"name": "sessionSource"}, {"name": "source"}], "metrics": [{"name": "eventCount"}, {"name": "eventValue"}, {"name": "newUsers"}, {"name": "sessions"}], "metricFilter": null, "dimensionFilter": null, "limit": 100000, "offset": 0}' 'https://analyticsdata.googleapis.com/v1beta/properties/264786259:runReport?access_token=<REMOVED>' -vv
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 2a00:1450:400d:805::200a...
* TCP_NODELAY set
* Connected to analyticsdata.googleapis.com (2a00:1450:400d:805::200a) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=upload.video.google.com
* start date: Mar 28 02:05:27 2022 GMT
* expire date: Jun 20 02:05:26 2022 GMT
* subjectAltName: host "analyticsdata.googleapis.com" matched cert's "*.googleapis.com"
* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f8cda80f400)
> POST /v1beta/properties/264786259:runReport?access_token=<REMOVED> HTTP/2
> Host: analyticsdata.googleapis.com
> Accept: */*
> Connection: keep-alive
> Content-Length: 399
> Content-Type: application/json
> User-Agent: python-requests/2.27.1
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* We are completely uploaded and fine
< HTTP/2 403
< www-authenticate: Bearer realm="https://accounts.google.com/", error="insufficient_scope", scope="https://www.googleapis.com/auth/analytics.readonly https://www.googleapis.com/auth/analytics https://www.google.com/analytics/feeds https://www.google.com/analytics/feeds/data https://www.google.com/analytics/feeds/"
< vary: X-Origin
< vary: Referer
< vary: Origin,Accept-Encoding
< content-type: application/json; charset=UTF-8
< date: Thu, 21 Apr 2022 08:10:43 GMT
< server: ESF
< cache-control: private
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
< accept-ranges: none
<
{
"error": {
"code": 403,
"message": "Request had insufficient authentication scopes.",
"status": "PERMISSION_DENIED",
"details": [
{
"#type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "ACCESS_TOKEN_SCOPE_INSUFFICIENT",
"domain": "googleapis.com",
"metadata": {
"method": "google.analytics.data.v1beta.BetaAnalyticsData.RunReport",
"service": "analyticsdata.googleapis.com"
}
}
]
}
}
* Connection #0 to host analyticsdata.googleapis.com left intact
* Closing connection 0
could you please let us know why this request fails although we have authorized all the required scopes?
You are sending an access token with your request.
When you requested consent of the user in order to get that access token. You must have requested consent with one of the following scopes
https://www.googleapis.com/auth/analytics.readonly
https://www.googleapis.com/auth/analytics
With out it your access token has insufficient authentication scopes. Request access of the user again and request the proper scopes.
I am attempting to use the Rest API in Magento 2. I have a piece of PHP that uses cURL to first get an admin token for my Magento user, then use the token to return a piece of Magento data (in this example a list of product types). The first part returns a token with no problems, but the second part comes back with an HTTP 401 Basic Authentication error.
My code is:
<?php
// Get handle for token retrieval
$userData = array("username" => "user", "password" => "password!");
$ch = curl_init("https://my.magento/rest/V1/integration/admin/token/");
// Set options
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($userData));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: application/json", "Content-Length: " . strlen(json_encode($userData))));
curl_setopt($ch, CURLOPT_VERBOSE, true);
$verbose = fopen('/tmp/curl.log', 'w+');
curl_setopt($ch, CURLOPT_STDERR, $verbose);
// Get token
$token = curl_exec($ch);
echo "Token returned: " . $token . "<BR><BR>";
// Display log
rewind($verbose);
$verboseLog = stream_get_contents($verbose);
echo "Verbose information 1:\n<pre>", htmlspecialchars($verboseLog), "</pre>\n";
echo "About to get product<BR>";
// Get handle for product types
$ch = curl_init("https://my.magento/rest/V1/products/types/");
// Set options
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "GET");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: application/json", "Authorization: Bearer " . json_decode($token)));
curl_setopt($ch, CURLOPT_VERBOSE, true);
$verbose = fopen('/tmp/curl.log', 'w+');
curl_setopt($ch, CURLOPT_STDERR, $verbose);
// Get types
$result = curl_exec($ch);
echo "Result: " . $result . "<BR>";
// Display log
rewind($verbose);
$verboseLog = stream_get_contents($verbose);
echo "<BR>Verbose information 2:\n<pre>", htmlspecialchars($verboseLog), "</pre>\n";
?>
And the browser output is:
Tokenreturned: "t8iskt68xlo5frf9hhtc1lk8wmqzbzx8"
Verbose information 1:
* About to connect() to my.magento port 443 (#2)
* Trying 104.25.128.20...
* Connected to mymagento (nn.nn.nn.nn) port 443 (#2)
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=ssl379212.cloudflaressl.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated
* start date: Oct 26 00:00:00 2018 GMT
* expire date: May 04 23:59:59 2019 GMT
* common name: ssl379212.cloudflaressl.com
* issuer: CN=COMODO ECC Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> POST /rest/V1/integration/admin/token/ HTTP/1.1
Host: sand2.firetoys.co.uk
Accept: */*
Content-Type: application/json
Content-Length: 48
* upload completely sent off: 48 out of 48 bytes
< HTTP/1.1 200 OK
< Date: Wed, 31 Oct 2018 12:50:01 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 34
< Connection: keep-alive
< Set-Cookie: __cfduid=d69af7d1f0a1205231a8867c1f45875621540990201; expires=Thu, 31-Oct-19 12:50:01 GMT; path=/; domain=.my.magento; HttpOnly
< X-Frame-Options: SAMEORIGIN
< X-UA-Compatible: IE=edge
< Pragma: no-cache
< Expires: -1
< Cache-Control: no-store, no-cache, must-revalidate, max-age=0
< Accept-Ranges: bytes
< Set-Cookie: PHPSESSID=9p378rsfito8gfocnrufucssh6; expires=Wed, 31-Oct-2018 13:50:01 GMT; Max-Age=3600; path=/; domain=sand2.firetoys.co.uk; secure; HttpOnly
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 47263eb629ea0ce9-LHR
<
* Connection #2 to host my.magento left intact
About to get product
Result:
Verbose information 2:
* About to connect() to my.magento port 443 (#3)
* Trying nn.nn.nn.nn...
* Connected to my.magento (nn.nn.nn.nn) port 443 (#3)
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=ssl379212.cloudflaressl.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated
* start date: Oct 26 00:00:00 2018 GMT
* expire date: May 04 23:59:59 2019 GMT
* common name: ssl379212.cloudflaressl.com
* issuer: CN=COMODO ECC Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> GET /rest/V1/products/types/ HTTP/1.1
Host: sand2.firetoys.co.uk
Accept: */*
Content-Type: application/json
Authorization: Bearer t8iskt68xlo5frf9hhtc1lk8wmqzbzx8
< HTTP/1.1 401 Unauthorized
< Date: Wed, 31 Oct 2018 12:50:01 GMT
< Content-Length: 0
< Connection: keep-alive
< Set-Cookie: __cfduid=d38c9e4bc3019d9ac55c7f68f5c5ca1161540990201; expires=Thu, 31-Oct-19 12:50:01 GMT; path=/; domain=.my.magento; HttpOnly
< X-Varnish: 7995397
< WWW-Authenticate: Basic
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 47263eb70f5b3512-LHR
<
* Connection #3 to host my.magento left intact
When I try just browsing directly to https://my.magento/rest/V1/products/types/ I get a Magento error back saying I am not authorised for the Products resource, which I would expect as I am sending no token or login credentials, but at least it is getting through to Magento.
Any ideas??
I should add that the server is set for Basic authentication, and if I replace the Bearer auth with the necessary Basic auth in the header for the GET, it returns the Magento message about not having access to the resource, which is fair enough. So I guess there are two questions:
How can I get past the basic authentication and still include the bearer authentication in my GET request, given that you can't put two authentications into the header?
Why does the initial POST to get the token work without any basic auth??
"How can I get past the basic authentication and still include the bearer authentication in my GET request, given that you can't put two authentications into the header?"
Disable auth for /index.php/rest location (in webserver)
"Why does the initial POST to get the token work without any basic auth??"
If the POST location is protected then you should get a 401 response.
Did you put the username and password on url on post request? http://user:pass#my.magento/rest/V1/
By the way, putting user:pass#my.magento into URL, will be translated into Authorization: User .
But you also set Authorization: Bearer t8iskt68xlo5frf9hhtc1lk8wmqzbzx8 which will overwrite the http authentification Authorization.
I've tried using Net::Twitter::Role::OAuth to add Sign in with Twitter to my application.
I've used this successfully in the past, but not with SSL enabled, which apparently is now required by the Twitter API. I have a controller action very similar to the examples in the synopsis:
sub twitter_authorize : Local {
my($self, $c) = #_;
my $nt = Net::Twitter->new(traits => [qw/API::RESTv1_1 OAuth/], %param);
my $url = $nt->get_authorization_url(callback => $callbackurl);
$c->response->cookies->{oauth} = {
value => {
token => $nt->request_token,
token_secret => $nt->request_token_secret,
},
};
$c->response->redirect($url);
}
However, this fails at the $nt->get_authorization_url() call with a 401 Unauthorized error.
Looking at the oauth/request_token docs, I tried running the request through cURL, as follows:
curl --request 'POST' 'https://api.twitter.com/oauth/request_token' --header 'Authorization: OAuth oauth_consumer_key="xxxx", oauth_nonce="xxxx", oauth_signature="xxxx", oauth_signature_method="HMAC-SHA1", oauth_timestamp="xxxx", oauth_callback="oob", oauth_version="1.0"' --verbose
And the response is as follows:
* About to connect() to api.twitter.com port 443 (#0)
* Trying 199.16.156.104...
connected
* Connected to api.twitter.com (199.16.156.104) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES128-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Twitter, Inc.; OU=Twitter Security; CN=api.twitter.com
* start date: 2014-08-03 00:00:00 GMT
* expire date: 2016-12-31 23:59:59 GMT
* subjectAltName: api.twitter.com matched
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
* SSL certificate verify ok.
> POST /oauth/request_token HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: api.twitter.com
> Accept: */*
> Authorization: OAuth oauth_consumer_key="xxxx", oauth_nonce="xxxx", oauth_signature="xxxx", oauth_signature_method="HMAC-SHA1", oauth_timestamp="xxxx", oauth_callback="oob", oauth_version="1.0"
>
< HTTP/1.1 401 Authorization Required
< cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
< content-length: 44
< content-security-policy-report-only: default-src https:; connect-src https:; font-src https: data:; frame-src https: http://*.twimg.com http://itunes.apple.com about: javascript:; img-src https: data:; media-src https:; object-src https:; script-src 'unsafe-inline' 'unsafe-eval' about: https:; style-src 'unsafe-inline' https:; report-uri https://twitter.com/i/csp_report?a=NVXW433SMFUWY%3D%3D%3D&ro=true;
< content-type: text/html; charset=utf-8
< date: Tue, 21 Oct 2014 10:29:57 UTC
< expires: Tue, 31 Mar 1981 05:00:00 GMT
< last-modified: Tue, 21 Oct 2014 10:29:57 GMT
< pragma: no-cache
< server: tsa_b
< set-cookie: _twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCD2PQTJJAToHaWQiJTE3M2Q4OWIyZWE1Nzc1%250AZmYxMjRkYmUyZDVjOTBlYjQxIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy%250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--b807e4ebb8d45756e9686971b951a549d0d83b61; domain=.twitter.com; path=/; secure; HttpOnly
< set-cookie: guest_id=v1%3A141388739758201626; Domain=.twitter.com; Path=/; Expires=Thu, 20-Oct-2016 10:29:57 UTC
< status: 401 Unauthorized
< strict-transport-security: max-age=631138519
< vary: Accept-Encoding
< x-connection-hash: 54a185631d5f0b3a3a9dc46fe1f40a57
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-mid: 0258025664ce095129d0cc294100d71a2e6e66ac
< x-runtime: 0.01294
< x-transaction: 6fad295009a89877
< x-ua-compatible: IE=edge,chrome=1
< x-xss-protection: 1; mode=block
<
* Connection #0 to host api.twitter.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Failed to validate oauth signature and token
Weirdly, if I remove the oauth_callback key from the Authorization header, it works fine and I get the tokens. However, the API docs suggest that this parameter is required. Is there something wrong with how I'm passing in the oauth_callback item?
I've tried setting it to oob (which is supposed to work for "out of band" access). And I've copied the encoded URL from the API docs. It doesn't work with either.
As it works without oauth_callback, it's not a time issue on my machine, as is a commonly reported problem. I haven't tried sending the Net::Twitter request without the callback (I haven't checked if that's possible) but I assume that would fix it there too. However, I do need the request to have a valid callback URL or the user won't be redirected back to the application for the rest of the sign in flow.
Adam,
I was having a similar issue and after a thorough investigation of what other Twitter API wrapper libraries were doing discovered that the oauth_callback needed to be encoded twice.
On doing a retrospective? search to get a little more explanation/clarity I found the following SO answer Twitter Oauth URL encoding inconsistencies? which extremely succinctly explained the issue I was having.
Is this perhaps the issue you have encountered?
Following some of the examples provided in the Invoicing REST API https://developer.paypal.com/docs/api/#invoicing I am always receiving an AUTHORIZATION_ERROR.
Here is an example:
First retrieving my token:
curl https://api.sandbox.paypal.com/v1/oauth2/token \
> -H "Accept: application/json" \
> -H "Accept-Language: en_US" \
> -u "AbNzCxxxxs6iVF0:EBhQWxxxxxxrgefvhb" \
> -d "grant_type=client_credentials"
{"scope":"openid https://uri.paypal.com/services/invoicing https://api.paypal.com/v1/payments/.* https://api.paypal.com/v1/vault/credit-card/.* https://api.paypal.com/v1/vault/credit-card","access_token":"F9Ig.4FXq1DQICPrMaUUb0-K--3dWBHvqRck636df4A","token_type":"Bearer","app_id":"APP-80W284485P519543T","expires_in":28800}%
Then using that token to create an invoice:
curl -v -X 'POST' 'https://api.sandbox.paypal.com/v1/invoicing/invoices' \
> -H 'Content-Type: application/json' \
> -H 'Authorization: Bearer F9Ig.4FXq1DQICPrMaUUb0-K--3dWBHvqRck636df4A' \
> -d '{
quote> "merchant_info": {
quote> "email": "rdg#rapiddg.com",
quote> "first_name": "Mike",
quote> "last_name": "Bopp",
quote> "business_name": "RDG",
quote> "phone": {
quote> "country_code": "001",
quote> "national_number": "5032141716"
quote> },
quote> "address": {
quote> "line1": "1234 Main St.",
quote> "city": "Portland",
quote> "state": "OR",
quote> "postal_code": "97217",
quote> "country_code": "US"
quote> }
quote> }
quote> }'
* Adding handle: conn: 0x7ff110804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7ff110804000) send_pipe: 1, recv_pipe: 0
* About to connect() to api.sandbox.paypal.com port 443 (#0)
* Trying 23.52.155.39...
* Connected to api.sandbox.paypal.com (23.52.155.39) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_RC4_128_SHA
* Server certificate: api.sandbox.paypal.com
* Server certificate: VeriSign Class 3 Secure Server CA - G3
* Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5
* Server certificate: Class 3 Public Primary Certification Authority - G2
> POST /v1/invoicing/invoices HTTP/1.1
> User-Agent: curl/7.30.0
> Host: api.sandbox.paypal.com
> Accept: */*
> Content-Type: application/json
> Authorization: Bearer F9Ig.4FXq1DQICPrMaUUb0-K--3dWBHvqRck636df4A
> Content-Length: 387
>
* upload completely sent off: 387 out of 387 bytes
< HTTP/1.1 401 Unauthorized
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< PROXY_SERVER_INFO: host=slcsbjava3.slc.paypal.com;threadId=220
< Paypal-Debug-Id: 0329fb0c0e560
< WWW-Authenticate: OAuth
< Content-Type: application/json
< DC: origin2-api.sandbox.paypal.com
< Date: Fri, 02 May 2014 15:31:53 GMT
< Connection: close
< Set-Cookie: DC=origin2-api.sandbox.paypal.com; secure
<
* Closing connection 0
{"name":"AUTHORIZATION_ERROR","message":"Authorization error occurred.","debug_id":"0329fb0c0e560"}%
I can successfully send a payment request as is done here: https://developer.paypal.com/docs/integration/direct/make-your-first-call/
But for some reason the Invoice does NOT work.
I have verified that in my sandbox app I have enabled invoicing
Any help appreciated, thanks in advance.
Please change the email address(rdg#rapiddg.com) to the one that linked to the app you created before.
Please go ahead to check the email address in your REST APP.