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"}}
Related
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 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.
I have a Cloudformation template for the serving of S3 content over HTTPS, via Cloudfront (see stack at end).
It works fine over HTTPS -
(env) justin#justin-XPS-13-9360:~/work/gists/ae46e471eb0e10e877731d787a9fbc2a$ curl -iv https://cloudfront-https-demo.s3-eu-west-1.amazonaws.com/index.json
* Trying 52.218.90.64...
* TCP_NODELAY set
* Connected to cloudfront-https-demo.s3-eu-west-1.amazonaws.com (52.218.90.64) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; CN=*.s3-eu-west-1.amazonaws.com
* start date: Aug 4 00:00:00 2020 GMT
* expire date: Aug 9 12:00:00 2021 GMT
* subjectAltName: host "cloudfront-https-demo.s3-eu-west-1.amazonaws.com" matched cert's "*.s3-eu-west-1.amazonaws.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert Baltimore CA-2 G2
* SSL certificate verify ok.
> GET /index.json HTTP/1.1
> Host: cloudfront-https-demo.s3-eu-west-1.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< x-amz-id-2: zVJ4idiIpuyIJIDvXIXbykQe9Po1YebyXEnYMLPkQydhwPLBpkypQfas3vCKuMIfd2cv+yISoqo=
x-amz-id-2: zVJ4idiIpuyIJIDvXIXbykQe9Po1YebyXEnYMLPkQydhwPLBpkypQfas3vCKuMIfd2cv+yISoqo=
< x-amz-request-id: 3E4B1B22DB6EE25D
x-amz-request-id: 3E4B1B22DB6EE25D
< Date: Tue, 25 Aug 2020 19:32:49 GMT
Date: Tue, 25 Aug 2020 19:32:49 GMT
< Last-Modified: Tue, 25 Aug 2020 15:42:18 GMT
Last-Modified: Tue, 25 Aug 2020 15:42:18 GMT
< ETag: "50521abab7a013be83ee00ded3f9f424"
ETag: "50521abab7a013be83ee00ded3f9f424"
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Type: application/json
Content-Type: application/json
< Content-Length: 19
Content-Length: 19
< Server: AmazonS3
Server: AmazonS3
<
{"hello": "world"}
* Connection #0 to host cloudfront-https-demo.s3-eu-west-1.amazonaws.com left intact
(I pushed an index.json file to the bucket)
but a little too well, as it also still serves plain HTTP, despite me specifying https-only in the template -
(env) justin#justin-XPS-13-9360:~/work/gists/ae46e471eb0e10e877731d787a9fbc2a$ curl -iv http://cloudfront-https-demo.s3-eu-west-1.amazonaws.com/index.json
* Trying 52.218.88.232...
* TCP_NODELAY set
* Connected to cloudfront-https-demo.s3-eu-west-1.amazonaws.com (52.218.88.232) port 80 (#0)
> GET /index.json HTTP/1.1
> Host: cloudfront-https-demo.s3-eu-west-1.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< x-amz-id-2: 9MKgLpvr1BmjF49D98VGThFi0JN4wUzAtIaocNh/8DTss54Zlo+/WFMymbLTdKpUoN0fvvLpMLg=
x-amz-id-2: 9MKgLpvr1BmjF49D98VGThFi0JN4wUzAtIaocNh/8DTss54Zlo+/WFMymbLTdKpUoN0fvvLpMLg=
< x-amz-request-id: 5H1V5SBZAJAY2QAW
x-amz-request-id: 5H1V5SBZAJAY2QAW
< Date: Tue, 25 Aug 2020 19:33:27 GMT
Date: Tue, 25 Aug 2020 19:33:27 GMT
< Last-Modified: Tue, 25 Aug 2020 15:42:18 GMT
Last-Modified: Tue, 25 Aug 2020 15:42:18 GMT
< ETag: "50521abab7a013be83ee00ded3f9f424"
ETag: "50521abab7a013be83ee00ded3f9f424"
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Type: application/json
Content-Type: application/json
< Content-Length: 19
Content-Length: 19
< Server: AmazonS3
Server: AmazonS3
<
{"hello": "world"}
* Connection #0 to host cloudfront-https-demo.s3-eu-west-1.amazonaws.com left intact
What do I need to do to the template to turn off plain HTTP / leave me with HTTPS only ?
---
AWSTemplateFormatVersion: '2010-09-09'
Parameters:
AppName:
Type: String
Resources:
CloudFrontOAI:
Type: AWS::CloudFront::CloudFrontOriginAccessIdentity
Properties:
CloudFrontOriginAccessIdentityConfig:
Comment: access-identity-passport-front.s3.amazonaws.com
SiteCloudFrontDist:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Enabled: true
DefaultRootObject: index.json
Origins:
- DomainName:
Fn::Sub:
- ${app_name}.s3.amazonaws.com
- app_name:
Ref: AppName
Id:
Fn::Sub:
- ${app_name}-site-cf-origin
- app_name:
Ref: AppName
S3OriginConfig:
OriginAccessIdentity:
Fn::Sub:
- origin-access-identity/cloudfront/${oai}
- oai:
Ref: CloudFrontOAI
DefaultCacheBehavior:
AllowedMethods:
- HEAD
- GET
- OPTIONS
ForwardedValues:
QueryString: false
TargetOriginId:
Fn::Sub:
- ${app_name}-site-cf-origin
- app_name:
Ref: AppName
ViewerProtocolPolicy: https-only
ViewerCertificate:
CloudFrontDefaultCertificate: true
SiteBucket:
Type: AWS::S3::Bucket
Properties:
BucketName:
Ref: AppName # NB same as app for URL convenience
SiteBucketPolicy:
Type: AWS::S3::BucketPolicy
Properties:
Bucket:
Ref: SiteBucket
PolicyDocument:
Statement:
- Action: s3:GetObject
Effect: Allow
Principal: '*'
Resource:
Fn::Sub:
- arn:aws:s3:::${bucket_name}/*
- bucket_name:
Ref: SiteBucket
Version: '2012-10-17'
In both cases you are using domain:
cloudfront-https-demo.s3-eu-west-1.amazonaws.com
This is not a CloudFront domain, which has format of, e.g.:
d111111abcdef8.cloudfront.net
It looks to me that you are using the url of the form:
https://<bucket name>.s3-<AWS Region>.amazonaws.com/<object name>
However, this is not CloudFront URL as indicated in the docs:
Use your Amazon S3 URL to verify that your content is publicly accessible, but remember that this is not the URL you'll use when you're ready to distribute your content with CloudFront.
Need to modify the bucket policy to disable non- secure connections -
{
"Version": "2012-10-17",
"Id": "ExamplePolicy",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket_name/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "true"
}
}
}
]
}
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?
I'm having a problem with the paypal IPN callback. Paypal's IPN callback stopped working, in sandbox environment.
I've been testing my client's website, for the past weeks, and it has always been working correctly - The payment was made, and a callback IPN was sent back to the website, confirming the payment, and updating the website's database.
I haven´t change anything in my code, and it suddenly stopped working. The payment is still made and saved in the paypal account, but the IPN is always retrying... it doesn't complete.
Here's the code in use:
<?php
// STEP 1: read POST data
// Reading POSTed data directly from $_POST causes serialization issues with array data in the POST.
// Instead, read raw POST data from the input stream.
$raw_post_data = file_get_contents('php://input');
$raw_post_array = explode('&', $raw_post_data);
$myPost = array();
foreach ($raw_post_array as $keyval) {
$keyval = explode ('=', $keyval);
if (count($keyval) == 2)
$myPost[$keyval[0]] = urldecode($keyval[1]);
}
// read the IPN message sent from PayPal and prepend 'cmd=_notify-validate'
$req = 'cmd=_notify-validate';
if(function_exists('get_magic_quotes_gpc')) {
$get_magic_quotes_exists = true;
}
foreach ($myPost as $key => $value) {
if($get_magic_quotes_exists == true && get_magic_quotes_gpc() == 1) {
$value = urlencode(stripslashes($value));
} else {
$value = urlencode($value);
}
$req .= "&$key=$value";
}
// STEP 2: POST IPN data back to PayPal to validate
$ch = curl_init('https://www.sandbox.paypal.com/cgi-bin/webscr');
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $req);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_FORBID_REUSE, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Connection: Close'));
// In wamp-like environments that do not come bundled with root authority certificates,
// please download 'cacert.pem' from [link removed] and set
// the directory path of the certificate as shown below:
// curl_setopt($ch, CURLOPT_CAINFO, dirname(__FILE__) . '/cacert.pem');
if( !($res = curl_exec($ch)) ) {
// error_log("Got " . curl_error($ch) . " when processing IPN data");
curl_close($ch);
exit;
}
curl_close($ch);
……
?>
Firing some outputs to text files, I discovered that it passes the first Step and stops on the Second, before
if( !($res = curl_exec($ch)) ) {
I've already submitted three help requests to PayPal, but still didn't get an answer from them.
The cURL request initiates a HTTP POST back to PayPal in order to validate the IPN message. If it stops at this step, it means you do receive the IPN POST from PayPal, but you've got a problem connecting back to PayPal.
What does // error_log("Got " . curl_error($ch) . " when processing IPN data"); contain?
In order to resolve this, test the HTTPS connection from your server to the following addresses:
https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate
https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_notify-validate
For example, you can run cURL directly from your server (assuming you've got SSH access);
curl -v https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_notify-validate
This should return something similar to the following:
$ curl -v https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_notify-validate
* About to connect() to www.sandbox.paypal.com port 443 (#0)
* Trying 173.0.82.77...
* connected
* Connected to www.sandbox.paypal.com (173.0.82.77) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/ssl/certs/ca-bundle.crt
CApath: none
* 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 AES256-SHA
* Server certificate:
* subject: 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; businessCategory=Private Organization; serialNumber=3014267; C=US; postalCode=95131-2021; ST=California; L=San Jose; street=2211 N 1st St; O=PayPal, Inc.; OU=PayPal Production; CN=www.sandbox.paypal.com
* start date: 2011-09-01 00:00:00 GMT
* expire date: 2013-09-30 23:59:59 GMT
* common name: www.sandbox.paypal.com (matched)
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)06; CN=VeriSign Class 3 Extended Validation SSL CA
* SSL certificate verify ok.
> GET /cgi-bin/webscr?cmd=_notify-validate HTTP/1.1
> User-Agent: curl/7.28.1
> Host: www.sandbox.paypal.com
> Accept: */*
>
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Wed, 14 Aug 2013 20:15:53 GMT
< Server: Apache
< X-Frame-Options: SAMEORIGIN
< Set-Cookie: xxxxx
< X-Cnection: close
< Set-Cookie: xxxx domain=.paypal.com; path=/; Secure; HttpOnly
< Set-Cookie: Apache=10.72.128.11.1376511353229960; path=/; expires=Fri, 07-Aug-43 20:15:53 GMT
< Vary: Accept-Encoding
< Strict-Transport-Security: max-age=14400
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host www.sandbox.paypal.com left intact
**INVALID* Closing connection #0**
* SSLv3, TLS alert, Client hello (1):
If you receive a timeout or an SSL handshake error, you will need to investigate this separately.