DigitalOcean > SPACES : delivery static assets of Rails app - digital-ocean-spaces

I spent all day trying to use spaces to delivery static assets.
Tutorial1 with Cloudfront
Tutorial2 with Cloudfront
And it took me only 5 minutes to make it work on Cloudfront without any configuration except the domain name ... (l). Here is the configuration file on Cloudfront.
{
"ETag": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Distribution": {
"Id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"ARN": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Status": "Deployed",
"LastModifiedTime": "2021-12-18T16:45:54.406000+00:00",
"InProgressInvalidationBatches": 0,
"DomainName": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.cloudfront.net",
"ActiveTrustedSigners": {
"Enabled": false,
"Quantity": 0
},
"ActiveTrustedKeyGroups": {
"Enabled": false,
"Quantity": 0
},
"DistributionConfig": {
"CallerReference": "9670d28a-cfff-4dd5-9d98-0d377018507b",
"Aliases": {
"Quantity": 0
},
"DefaultRootObject": "",
"Origins": {
"Quantity": 1,
"Items": [
{
"Id": "tiredoftrying - staging",
"DomainName": "tiredoftrying.digitaloceanspaces.com",
"OriginPath": "",
"CustomHeaders": {
"Quantity": 0
},
"CustomOriginConfig": {
"HTTPPort": 80,
"HTTPSPort": 443,
"OriginProtocolPolicy": "https-only",
"OriginSslProtocols": {
"Quantity": 3,
"Items": [
"TLSv1",
"TLSv1.1",
"TLSv1.2"
]
},
"OriginReadTimeout": 30,
"OriginKeepaliveTimeout": 5
},
"ConnectionAttempts": 3,
"ConnectionTimeout": 10,
"OriginShield": {
"Enabled": false
}
}
]
},
"OriginGroups": {
"Quantity": 0
},
"DefaultCacheBehavior": {
"TargetOriginId": "tiredoftrying - staging",
"TrustedSigners": {
"Enabled": false,
"Quantity": 0
},
"TrustedKeyGroups": {
"Enabled": false,
"Quantity": 0
},
"ViewerProtocolPolicy": "allow-all",
"AllowedMethods": {
"Quantity": 2,
"Items": [
"HEAD",
"GET"
],
"CachedMethods": {
"Quantity": 2,
"Items": [
"HEAD",
"GET"
]
}
},
"SmoothStreaming": false,
"Compress": true,
"LambdaFunctionAssociations": {
"Quantity": 0
},
"FunctionAssociations": {
"Quantity": 0
},
"FieldLevelEncryptionId": "",
"CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6"
},
"CacheBehaviors": {
"Quantity": 0
},
"CustomErrorResponses": {
"Quantity": 0
},
"Comment": "",
"Logging": {
"Enabled": false,
"IncludeCookies": false,
"Bucket": "",
"Prefix": ""
},
"PriceClass": "PriceClass_All",
"Enabled": true,
"ViewerCertificate": {
"CloudFrontDefaultCertificate": true,
"MinimumProtocolVersion": "TLSv1",
"CertificateSource": "cloudfront"
},
"Restrictions": {
"GeoRestriction": {
"RestrictionType": "none",
"Quantity": 0
}
},
"WebACLId": "",
"HttpVersion": "http2",
"IsIPV6Enabled": true
}
}
}
DEBUG
curl -H "origin: https://supersite.com" -v "https://supersite-cnd.sfo3.digitaloceanspaces.com/assets/about/about-1-b4e60057ce55fa40b823e6403edc2b3cd1d1b2703fbebb4090eef64e3c09a64b.png"
OUTPUT :
* Trying ...
* TCP_NODELAY set
* Connected to supersite-cnd.sfo3.digitaloceanspaces.com (5.101.109.44) 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.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.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=New York; L=New York; O=DigitalOcean, LLC; CN=*.sfo3.digitaloceanspaces.com
* start date: Mar 17 00:00:00 2021 GMT
* expire date: Apr 17 23:59:59 2022 GMT
* subjectAltName: host "supersite-cnd.sfo3.digitaloceanspaces.com" matched cert's "*.sfo3.digitaloceanspaces.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
> GET /assets/about/about-1-b4e60057ce55fa40b823e6403edc2b3cd1d1b2703fbebb4090eef64e3c09a64b.png HTTP/1.1
> Host: supersite-cnd.sfo3.digitaloceanspaces.com
> User-Agent: curl/7.68.0
> Accept: */*
> origin: https://supersite.com
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< content-length: 230
< x-amz-request-id: tx0000000000000a3cdaece-0061be2b23-25a411a1-sfo3b
< access-control-allow-origin: https://supersite.com
< vary: Origin
< access-control-allow-methods: GET
< access-control-max-age: 31536000
< accept-ranges: bytes
< content-type: application/xml
< date: Sat, 18 Dec 2021 18:40:35 GMT
< strict-transport-security: max-age=15552000; includeSubDomains; preload
< vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
< cache-control: max-age=60
<
* Connection #0 to host supersite-cnd.sfo3.digitaloceanspaces.com left intact
<?xml version="1.0" encoding="UTF-8"?><Error><Code>AccessDenied</Code><BucketName>supersite-cnd</BucketName><RequestId>tx0000000000000a3cdaece-0061be2b23-25a411a1-sfo3b</RequestId><HostId>25a411a1-sfo3b-sfo3-zg02</HostId></Error>
successful attempt on Cloudfront :
* Trying ...
* TCP_NODELAY set
* Connected to supersite-cnd.cloudfront.net (52.85.216.96) 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.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.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.cloudfront.net
* start date: Mar 19 00:00:00 2021 GMT
* expire date: Mar 17 23:59:59 2022 GMT
* subjectAltName: host "supersite-cnd.cloudfront.net" matched cert's "*.cloudfront.net"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* 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 0x56506ff23e30)
> GET /assets/about/about-1-b4e60057ce55fa40b823e6403edc2b3cd1d1b2703fbebb4090eef64e3c09a64b.png HTTP/2
> Host: supersite-cnd.cloudfront.net
> user-agent: curl/7.68.0
> accept: */*
> origin: https://supersite.com
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< content-type: image/png
< content-length: 46219
< server: nginx/1.18.0 (Ubuntu)
< date: Sat, 18 Dec 2021 19:18:19 GMT
< last-modified: Thu, 16 Dec 2021 08:28:28 GMT
< etag: "61baf8ac-b48b"
< expires: Thu, 31 Dec 2037 23:55:55 GMT
< cache-control: max-age=315360000
< cache-control: public
< accept-ranges: bytes
< x-cache: Miss from cloudfront
< via: 1.1 d51c589e5c767f633277e1c42d3e5c0a.cloudfront.net (CloudFront)
< x-amz-cf-pop: JNB50-C1
< x-amz-cf-id: sznV_e7hZKxQ-fWggvY5LsFDlFCNQDMGOIlIELoL5hWN0ABdLpluUw==
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 8595)
* stopped the pause stream!
* Connection #0 to host supersite-cnd.cloudfront.net left intact
Since the same file exists and works for Cloudfront ... it is not a configuration problem (on Nginx or Puma). I presume a CORS issue on DigitalOcean but I have no idea how to find it ...
Any idea? Help.

After days, speaking with the support, the answer is simple : Spaces is not a CDN, it is a Storage Service (as S3) with a CDN free feature. So don't except any fancy feature with it.

Related

shopify is not accepting image src when the downloadable image content type (image/jpeg;charset=UTF-8)

Here is the source URL of the image -
https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg
curl result for the image file -
curl -v 'https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg'
* Trying 62.245.203.125:443...
* Connected to erp.guu-portal.de (62.245.203.125) 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-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=*.guu-portal.de
* start date: Jan 5 00:00:00 2021 GMT
* expire date: Feb 5 23:59:59 2022 GMT
* subjectAltName: host "erp.guu-portal.de" matched cert's "*.guu-portal.de"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
* SSL certificate verify ok.
> GET /erp/dokumente/download/759927?filename=9783835408241.jpg HTTP/1.1
> Host: erp.guu-portal.de
> User-Agent: curl/7.77.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 14 Jan 2022 17:55:16 GMT
< Server: Apache-Coyote/1.1
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: SAMEORIGIN
< Last-Modified: Thu, 18 Oct 2018 20:32:21 GMT
< Content-Disposition: attachment; filename=9783835408241.jpg
< Content-Type: image/jpeg;charset=UTF-8
< Content-Length: 182163
< Set-Cookie: JSESSIONID=30BDB73806080AEF778934ABEBADFFCE.worker1; Path=/erp; HttpOnly
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
I was sending payload in post request -
payload = {'image': {'src': 'https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg', 'filename': '399_1.jpg'}}
Posting images to rest API URL -
requests.session.put(base_url + f"products/{product_id}.json",payload))
Response:
Status Code 422 with Message: {"errors":{"image":["Could not process image: [\"\/erp\/dokumente\/download\/759927 (image\/jpeg;charset=UTF-8) is not a recognized format\"]"]}}
I have tried other public images and they work... however, they had content-type image/jpeg only

How to specify a payee with paypal orders api?

Here is the tutorial that I am following: What is the best way to enable a website users send money to each other?
The problem is with my post request.
Let's break it down into pieces.
Headers
headers: {
"Authorization": `Bearer ${accessToken}`,
"Content-Type": "application/json"
}
I get the access token also via paypal api namely https://api.sandbox.paypal.com/v1/oauth2/token.
Body
body: {
intent: 'CAPTURE',
purchase_units: [{
amount: {
currency_code: 'USD',
value: '2.00'
},
payee: {
email_address: "myanothersandboxaccount#gmail.com"
}
}]
}
But, it doesn't work, as I get an error
{
name: 'INVALID_REQUEST',
message: 'Request is not well-formed, syntactically incorrect, or violates schema.',
debug_id: '2884e1b5eccee',
details: [
{
field: '/',
location: 'body',
issue: 'INVALID_SYNTAX',
description: 'MALFORMED_REQUEST_JSON'
}
],
links: [
{
href: 'https://developer.paypal.com/docs/api/orders/v2/#error-INVALID_SYNTAX',
rel: 'information_link',
encType: 'application/json'
}
]
}
curl request
curl -v -X POST https://api.sandbox.paypal.com/v2/checkout/orders \
-H "Content-Type: application/json" \
-H "Authorization: Bearer A23AALAej8Yg-4iKJBcWckiv5-ZlhYWlkmBsPuWaVngJcMigU7P-6f8P02vnOpIo8QlOJ-P3hd3K86vKo_lpSlu0-bZBj98eg" \
-d '{
"intent": "CAPTURE",
"purchase_units": [
{
"amount": {
"currency_code": "USD",
"value": "100.00"
},
"payee": {
"email": "myanothersandboxaccount#gmail.com"
}
}
]
}'
curl response
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 173.0.82.78...
* TCP_NODELAY set
* Connected to api.sandbox.paypal.com (173.0.82.78) 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, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* 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-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com
* start date: Jul 27 00:00:00 2020 GMT
* expire date: Aug 1 12:00:00 2022 GMT
* subjectAltName: host "api.sandbox.paypal.com" matched cert's "api.sandbox.paypal.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
> POST /v2/checkout/orders HTTP/1.1
> Host: api.sandbox.paypal.com
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: application/json
> Authorization: Bearer A23AALAej8Yg-4iKJBcWckiv5-ZlhYWlkmBsPuWaVngJcMigU7P-6f8P02vnOpIo8QlOJ-P3hd3K86vKo_lpSlu0-bZBj98eg
> Content-Length: 212
>
* upload completely sent off: 212 out of 212 bytes
< HTTP/1.1 201 Created
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Content-Length: 501
< Content-Type: application/json
< Date: Sat, 05 Dec 2020 10:30:13 GMT
< Paypal-Debug-Id: 6bd069526af1c
<
* Connection #0 to host api.sandbox.paypal.com left intact
{"id":"674004650C383744Y","status":"CREATED","links":[{"href":"https://api.sandbox.paypal.com/v2/checkout/orders/674004650C383744Y","rel":"self","method":"GET"},{"href":"https://www.sandbox.paypal.com/checkoutnow?token=674004650C383744Y","rel":"approve","method":"GET"},{"href":"https://api.sandbox.paypal.com/v2/checkout/orders/674004650C383744Y","rel":"update","method":"PATCH"},{"href":"https://api.sandbox.paypal.com/v2/checkout/orders/674004650C383744Y/capture","rel":"capture","method":"POST"}]}* Closing connection 0
And, with curl I get a successful response. I can see that all went well from my paypal sandbox dashboard.
What could it be?
I was using node-fetch to call the paypal api to create an order. Tried with axios, worked just fine.
The error basically means PayPal isn't able to parse the body object it received as JSON, so it appears something is being transmitted/received incorrectly.
You should first test with command-line curl to verify functionality and your JSON's correctness, which should work.
Then to get more details about what's actually going wrong in what you are sending, you will need to log the actual data being sent (not your code, the actual data the code sends when executed)
One way to do this is to instead of sending your request to https://api-m.paypal.com , instead send it to a request bin service like offered via https://requestbin.com/

Istio throwing 404 for URL mapped in Virtual Service

Cloud Provider: Azure
Istio Version: 1.19
Kubernetes Version: 1.12.8
Below is my Virtual Service and Gateway yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: app-ingress-rules
namespace: istio-system
# Define the routes less restrictive first to more restrictive. this file gets read from bottom to top.
spec:
# https://istio.io/docs/reference/config/istio.networking.v1alpha3/#VirtualService
gateways: # The default `mesh` value for when left blank is doesn't seem to propigate the rule properly. For now, always use a list of FQDN gateways
- tls-gateway
hosts:
- "dev.myapp.westus.cld.something.com" # This host is part of installed HTTPS cert
- "nonprod.westus.cloudapp.azure.com" # This host is NOT part of installed HTTPS cert
http:
# Routes
- match:
- uri:
prefix: /myapp/status
rewrite:
uri: /status
route:
- destination:
host: myapp.myapp-ns.svc.cluster.local
--------------------------------------------
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: tls-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
name: https
number: 443
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
hosts:
- "*"
If I do
curl -Iv https://dev.myapp.westus.cld.something.com/myapp/status
I get HTTP 404 as below
* Trying 123.12.123.12...
* TCP_NODELAY set
* Connected to dev.myapp.westus.cld.something.com (123.12.123.12.) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* 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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=***; L=*****; O=******, Inc.; CN=*********
* start date: Jul 26 20:32:59 2019 GMT
* expire date: Jul 26 20:32:59 2021 GM
* subjectAltName: host "dev.myapp.westus.cld.something.com" matched cert's "dev.myapp.westus.cld.something.com"
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* 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 0x7f995e006600)
> HEAD /myapp/status HTTP/2
> Host: dev.myapp.westus.cld.something.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 404
HTTP/2 404
< location: https://dev.myapp.westus.cld.something.com/myapp/status
location: https://dev.myapp.westus.cld.something.com /myapp/status
< date: Wed, 31 Jul 2019 19:10:13 GMT
date: Wed, 31 Jul 2019 19:10:13 GMT
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host dev.myapp.westus.cld.something.com left intact
However when I try with
curl -Iv --insecure https://nonprod.westus.cloudapp.azure.com/myapp/status
I get HTTP 200. see below
* Trying 123.12.123.12...
* TCP_NODELAY set
* Connected to nonprod.westus.cloudapp.azure.com (123.12.123.12) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* 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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=****; L=*****; O=******, Inc.; CN=*********
* start date: Jul 26 20:32:59 2019 GMT
* expire date: Jul 26 20:32:59 2021 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* 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 0x7fb4b7003c00)
> HEAD /myapp/status HTTP/2
> Host: nonprod.westus.cloudapp.azure.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
HTTP/2 200
< request-context: appId=cid-v1:39296fe8-1dc6-4049-bb31-e7816e83b9ec
request-context: appId=cid-v1:39296fe8-1dc6-4049-bb31-e7816e83b9ec
< access-control-allow-origin: *
access-control-allow-origin: *
< access-control-expose-headers: Content-Disposition
access-control-expose-headers: Content-Disposition
< content-type: text/plain;charset=ISO-8859-1
content-type: text/plain;charset=ISO-8859-1
< content-length: 69
content-length: 69
< date: Wed, 31 Jul 2019 19:07:54 GMT
date: Wed, 31 Jul 2019 19:07:54 GMT
< x-envoy-upstream-service-time: 7
x-envoy-upstream-service-time: 7
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host nonprod.westus.cloudapp.azure.com left intact
Is my VS configuration wrong with regards to accepting HTTPS traffic? I am unable to look at envoy logs to see if there is any error.
How can I pinpoint where the issue is?
Update
dev.myapp.westus.cld.something.com is a CName record which ultimately points to nonprod.westus.cloudapp.azure.com
nonprod.westus.cloudapp.azure.com is a actual DNS which is mapped to a public IP.
Note sure if that makes any difference.

Docusign, cant create simple envelope

Good day!
I am trying to create envelope and send , but occurs an error
UNABLE_TO_LOAD_DOCUMENT
The document is a simple html
<!doctype html><html><head></head><body>test</body></html>
converted to base64.
Here is a request and response to docusign REST api. How can I resolve this issue?
curl -v --header "Authorization: Bearer eyJ0eXAiOiJNVCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiNjgxODVmZjEtNGU1MS00Y2U5LWFmMWMtNjg5ODEyMjAzMzE3In0.AQkAAAABAAUABwAACRsipsvVSAgAAEk-MOnL1UgCAN1TkZsZHQBNmEVScLwqs5wVAAEAAAAYAAEAAAAFAAAADQAkAAAANzVmYmZkZGUtNTBkOC00NTU0LTg0NGEtOTBhMmNlNDc1YWU4EgABAAAACwAAAGludGVyYWN0aXZlMAAA3OkgpsvVSA.2hzUVkqJjMOlL9UviE-oCeGyvIG84bBH0czLFwK6M4sO1NnzstvE8__6lmdyRqoZTIk879xQmm6e1YEzlDVxI5iKL7lE1b4I63BhHHPhtAk5gD6pWch3blPhM5rrGlJnf9DAZ6zAsR5Ku6IuFXaGwm7ZxvTe30qd76RJEReJoqwed_f-hT9VTFmipBZt5336ewkGgGHJp2fKNpyg-ImYCkuNGpnhiMGwDT2z92-YFQ7h26laKZGwE_4pFO3ihH9I4y7-R2pBsF2vWXq7yQeS6497oQftdjFEaUdcZvciN8Gen-EeGo1HG8kD2xPEtrlDWcrhXE3dlcuS5YyQu21TzQ" \
> --header "Content-Type: application/json" \
> --data '{"status": "sent","emailSubject": "test subject","documents": [{"documentId": "1","name": "test.html","documentBase64": "PCFkb2N0eXBlIGh0bWw+PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PnRlc3Q8L2JvZHk+PC9odG1sPg=="}],"recipients": {"signers": [{"name": "Test Name","email": "test#perlito.ru","recipientId": "1","routingOrder": "1"}]}}' \
> --request POST https://demo.docusign.net/restapi/v2/accounts/8392ced0-e907-4569-802f-73a31cf08696/envelopes
* Hostname was NOT found in DNS cache
* Trying 162.248.186.25...
* Connected to demo.docusign.net (162.248.186.25) 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 key exchange (12):
* 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 ECDHE-RSA-AES256-GCM-SHA384
* 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=5711317; C=US; postalCode=98101; ST=Washington; L=Seattle; street=1301 2nd Ave, Suite 2000; O=DocuSign, Inc.; OU=Technical Operations; CN=demo.docusign.net
* start date: 2017-01-09 00:00:00 GMT
* expire date: 2019-02-23 23:59:59 GMT
* subjectAltName: demo.docusign.net matched
* issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 EV SSL CA - G3
* SSL certificate verify ok.
> POST /restapi/v2/accounts/8392ced0-e907-4569-802f-73a31cf08696/envelopes HTTP/1.1
> User-Agent: curl/7.35.0
> Host: demo.docusign.net
> Accept: */*
> Authorization: Bearer eyJ0eXAiOiJNVCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiNjgxODVmZjEtNGU1MS00Y2U5LWFmMWMtNjg5ODEyMjAzMzE3In0.AQkAAAABAAUABwAACRsipsvVSAgAAEk-MOnL1UgCAN1TkZsZHQBNmEVScLwqs5wVAAEAAAAYAAEAAAAFAAAADQAkAAAANzVmYmZkZGUtNTBkOC00NTU0LTg0NGEtOTBhMmNlNDc1YWU4EgABAAAACwAAAGludGVyYWN0aXZlMAAA3OkgpsvVSA.2hzUVkqJjMOlL9UviE-oCeGyvIG84bBH0czLFwK6M4sO1NnzstvE8__6lmdyRqoZTIk879xQmm6e1YEzlDVxI5iKL7lE1b4I63BhHHPhtAk5gD6pWch3blPhM5rrGlJnf9DAZ6zAsR5Ku6IuFXaGwm7ZxvTe30qd76RJEReJoqwed_f-hT9VTFmipBZt5336ewkGgGHJp2fKNpyg-ImYCkuNGpnhiMGwDT2z92-YFQ7h26laKZGwE_4pFO3ihH9I4y7-R2pBsF2vWXq7yQeS6497oQftdjFEaUdcZvciN8Gen-EeGo1HG8kD2xPEtrlDWcrhXE3dlcuS5YyQu21TzQ
> Content-Type: application/json
> Content-Length: 322
>
* upload completely sent off: 322 out of 322 bytes
< HTTP/1.1 400 Bad Request
< Cache-Control: no-cache
< Content-Length: 180
< Content-Type: application/json; charset=utf-8
< X-RateLimit-Reset: 1528290000
< X-RateLimit-Limit: 1000
< X-RateLimit-Remaining: 995
< X-DocuSign-TraceToken: 81b52b47-4b2a-4b56-b1fe-9ec3dfb90b5a
< Date: Wed, 06 Jun 2018 12:59:10 GMT
< Strict-Transport-Security: max-age=31536000; includeSubDomains
<
{
"errorCode": "UNABLE_TO_LOAD_DOCUMENT",
"message": "Unable to load the document. Unable to load Document(1;test.html). Error: the document is corrupt, rebuilding failed"
* Connection #0 to host demo.docusign.net left intact
}
There are two issues in your request, the document which you are sending is an HTML type so you need to specify fileExtension attribute inside documents node. fileExtension is not required if you are sending any pdf document type, for all other document types you need to specify the document type or extension in fileExtension attribute. Second issue is you are not defining any DocuSign tabs for the recipient. On a document where you want signers to do something on the document either to Sign or enter any data, for that you need to add any DS Tabs on the document either by X/Y position or Anchor String or using DS Server Templates.
You correct sample example would like below, and it should run perfectly:
{
"status": "sent",
"emailSubject": "test subject",
"documents": [{
"documentId": "1",
"name": "test.html",
"documentBase64": "PCFkb2N0eXBlIGh0bWw+PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5PnRlc3Q8L2JvZHk+PC9odG1sPg==",
"fileExtension": "html"
}],
"recipients": {
"signers": [{
"name": "Test Name",
"email": "test#perlito.ru",
"recipientId": "1",
"routingOrder": "1",
"tabs": {
"signHereTabs": [{
"documentId": "1",
"pageNumber": "1",
"recipientId": "1",
"xPosition": "500",
"yPosition": "500"
}]
}
}]
}
}

Linux curl not working

I am trying to access a remote server which responds properly in one network but not in another. I can access it on my local machine(In some networks) but not on aws:
Working Curl:
curl -vvv https://abc.example.com -H 'Content-Type:text/xml' --user ******:***** -d '<XML></XML>'
Output:
* Hostname was NOT found in DNS cache
* Trying xx.xx.xx.xx...
* Connected to abc.example.com (xx.xx.xx.xx) 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 key exchange (12):
* 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 TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
* subject: C=**; ST=***; L=***; x.x.x.x.x.x.x.x.x.x=**; x.x.x.x.x.x.x.x.x.x=ABCD; x.x.x.x.x.x.x.x.x.x.x=def; O=abc def ghi; businessCategory=abc def; serialNumber=123456; CN=abc.example.com
* start date: 2016-04-04 07:19:41 GMT
* expire date: 2018-04-04 07:49:39 GMT
* subjectAltName: abc.example.com matched
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2014 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1M
* SSL certificate verify ok.
* Server auth using Basic with user '******'
> POST /abc/def HTTP/1.1
> Authorization: Basic *********************
> User-Agent: curl/7.38.0
> Host: abc.example.com
> Accept: */*
> Content-Type:text/xml
> Content-Length: 16783
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Date: Sat, 23 Apr 2016 07:31:25 GMT
* Server Oracle-Application-Server-11g is not blacklisted
< Server: Oracle-Application-Server-11g
< X-ORACLE-DMS-ECID: *************************
< SOAPAction: "http://ghi.services//abc"
< X-Powered-By: Servlet/2.5 JSP/2.1
< Vary: Accept-Encoding,User-Agent
< Content-Type: text/xml; charset=utf-8
< Content-Language: en
< Transfer-Encoding: chunked
<
<XML>SUCCESSFUL OUTPUT</XML>
Not working CURL:
curl -vvv https://abc.example.com -H 'Content-Type:text/xml' --user ******:***** -d '<XML></XML>'
Output:
* Hostname was NOT found in DNS cache
* Trying xx.xx.xx.xx...
* Connected to abc.example.com (xx.xx.xx.xx) 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 key exchange (12):
* 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 ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
* subject: C=XX; ST=XXXXXXX; L=XXXXXXX; x.x.x.x.x.x.x=XX; x.x.x.x.x.x.x=XXXXXXX; x.x.x.x.x.x.x.x.x.x.x.x=XXXXX; O=Some company name; businessCategory=My unit; serialNumber=12345; CN=abc.example.com
* start date: 2016-04-04 07:19:41 GMT
* expire date: 2018-04-04 07:49:39 GMT
* subjectAltName: abc.example.com matched
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2014 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1M
* SSL certificate verify ok.
* Server auth using Basic with user '**********'
> POST /abc/def HTTP/1.1
> Authorization: Basic ******************
> User-Agent: curl/7.35.0
> Host: abc.example.com
> Accept: */*
> Content-Type:text/xml
> Content-Length: 16783
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 400 Bad Request
< Date: Sat, 23 Apr 2016 07:37:47 GMT
* Server Apache is not blacklisted
< Server: Apache
< Content-Length: 226
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
I don't have any idea what's going on. Please help

Resources