Amazon API gateway ignores set-cookie from back-end API - node.js

I am trying to set up http-proxy using amazon api gateway, but the set-cookie request from back-end api is ignored by api gateway. Also I have tried to include "integration.response.header.Set-Cookie" as mapping for "set-cookie" in gateway.
what setting I have to follow so that gateway does not filter out any header-request parameters like set-cookie & cookie

API Gateway does not filter the Cookie or Set-Cookie header on the request or response. You should be able to proxy these headers to your endpoint and back again without issue.
However, the cookie headers may be filtered out by the "test invoke" function in the API Gateway console, or the test client that you may be using.
To confirm please test against a deployed API using a supported client such as curl. i.e.
curl -v "https://h8q79qwil5.execute-api.us-east-1.amazonaws.com/test"
* Trying 52.84.24.209...
* Connected to h8q79qwil5.execute-api.us-east-1.amazonaws.com (52.84.24.209) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.execute-api.us-east-1.amazonaws.com
* Server certificate: Symantec Class 3 Secure Server CA - G4
* Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5
> GET /test HTTP/1.1
> Host: h8q79qwil5.execute-api.us-east-1.amazonaws.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 181
< Connection: keep-alive
< Date: Mon, 11 Jul 2016 22:36:21 GMT
< Cookie: foobar
< Set-Cookie: set-cookie!
< x-amzn-RequestId: e40c57d1-47b7-11e6-b175-2f2f5356f0d7
< X-Cache: Miss from cloudfront
< Via: 1.1 ce270f4a88edde7438864bc44406e83a.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: BRoLbquwa2ZkOwxDcEOJQ-iheYa90AM4WkT2gZr3TUgLlBIvUijZAg==
Thanks,
Ryan

Related

In Caddy, can I disable sending 304 even when If-None-Match matches?

In Express you can app.disable('etag') is there anything similar in Caddy?
I have tried :
header {
\-Etag
\-Last-Modifier
Cache-Control no-store
}
that makes Caddy not send the ETag header and it also makes browsers not send the If-None-Match: <ETagvalue> header.
But if I use curl directly to send the If-None-Match then Caddy will send 304
curl -v -H 'If-None-Match: "rl98mytb"' https://localhost.rubenlaguna.com
> GET / HTTP/2
> Host: localhost.rubenlaguna.com
> user-agent: curl/7.84.0
> accept: */*
> if-none-match: "rl98mytb"
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
\< HTTP/2 304
\< alt-svc: h3=":443"; ma=2592000
\< etag: "rl98mytb"
\< server: Caddy
\< date: Sun, 13 Nov 2022 17:08:17 GMT
My question is it possible to instruct Caddy to ignore If-None-Match and always return the 200 OK with the actual contents?

anyway to configure a URL prefix for prestosql web UI

Given prestosql cluster started and listens to localhost:8080, I found it redirects request to http://localhost:8080/ui/
> curl -v http://localhost:8080/
* Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0
> Accept: */*
> Referer:
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 303 See Other
< Date: Thu, 02 Jul 2020 14:07:10 GMT
< Location: http://localhost:8080/ui/
< Content-Length: 0
Is there anyway to support a prefix like /prestosql so that it can redirect request from /prestosql to /prestosql/ui instead of /ui/?
The scenario is about using a gateway in front of prestosql then routing requests via URL rewrite. E.g., Nginx/HAProxy or Istio virtual service.
It is not possible and would require quite some work, since Presto's UI HTML and javascript code and expects various resources available at /ui/... path.
See previous discussion at https://github.com/prestosql/presto/issues/3706

wget giving me HTTP 403 in Linux EC2

I have Linux EC2 instance when i am trying to download a file but getting 403
wget https://plugins.gradle.org/m2/org/springframework/data/spring-data-releasetrain/Moore-
SR1/spring-data-releasetrain-Moore-SR1.pom
Above giving me me HTTP 403 error.How should i trace where its blocking me to download ?
All proxies are set properly in my Ec2.
I tried traceroute but its not give me IPs. How to troubleshoot where its blocking me to download.
I have also open all outbound traffic in security group of EC2 but no luck.
Curl in debug mode give me below
$curl -v repo.jfrog.org
* About to connect() to proxy myproxy.xxx.com port 8080 (#0)
* Trying 1**.10*.**.**...
* Connected to myproxy.xxx.com (1**.10*.**.**) port 8080 (#0)
* Establish HTTP proxy tunnel to repo.jfrog.org:443
> CONNECT repo.jfrog.org:443 HTTP/1.1
> Host: repo.jfrog.org:443
> User-Agent: curl/7.29.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 403 Forbidden
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Content-Length: 913
< X-RBT-SCAR: 10.1**.5.2**:1141466989:1000
<
* Received HTTP code 403 from proxy after CONNECT
* Connection #0 to host myproxy.xxx.com left intact
curl: (56) Received HTTP code 403 from proxy after CONNECT

HTTP 406 Error While Logging In To DocuSign API

I have a prototype WinForms application that uses open-source DocuSign.Integrations.Client library. It was working correctly until a couple of days ago. Now every attempt to login results in HTTP 406 error. No code has changed on my side, and my user name and password are valid (verified on https://appdemo.docusign.com). Any help is appreciated!
Below is the raw request with masked credentials:
GET http://demo.docusign.net/restapi/v2/login_information?api_password=true&include_account_id_guid=true
HTTP/1.1 Accept: application/json
Content-Type: application/json
X-DocuSign-Authentication: <DocuSignCredentials><Username>______</Username><Password>______</Password><IntegratorKey>____-________-___-___-___-____________</IntegratorKey></DocuSignCredentials>
Host: demo.docusign.net
Connection: Keep-Alive
In response, I get a 302 redirect:
HTTP/1.1 302 Found
Cache-Control: no-cache
Content-length: 0
Location: https://demo.docusign.net
Connection: close
And then receive a 406 error:
HTTP/1.1 406 Not Acceptable
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Sat, 09 May 2015 19:16:52 GMT
Content-Length: 1346
Connection: close
This is incorrect:
http://demo.docusign.net/restapi/v2/login_information?
api_password=true&include_account_id_guid=true
It should use HTTPS, not HTTP in your GET URL call:
https://demo.docusign.net/restapi/v2/login_information?
api_password=true&include_account_id_guid=true
Also your error is actually describes what is wrong
HTTP/1.1 406 Not Acceptable
Your request headers should be this:
Accept: application/json
Content-Type: application/json
X-DocuSign-Authentication: <DocuSignCredentials><Username>______</Username><Password>______</Password><IntegratorKey>____-________-___-___-___-____________</IntegratorKey></DocuSignCredentials>

Question on authentication in curl command

When I run the below curl command with --negotiate option I get the following error. Any idea why?
[Aug05 5:03am] pradeep#localhost:/tmp/pradeep> curl --negotiate -u : -k --verbose --head "http://something.domain.com/something/soething.action"
About to connect() to something.domain.com port 80 (#0)
Trying ip-address ... connected
Connected to something.domain.com (ip-address) port 80 (#0)
HEAD /something.action HTTP/1.1
User-Agent: curl/7.21.6 (i386-pc-solaris2.10) libcurl/7.21.6 OpenSSL/0.9.8j zlib/1.2.3
Host: something.domain.com
Accept: */*
< HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
< Date: Fri, 05 Aug 2011 09:04:45 GMT
Date: Fri, 05 Aug 2011 09:04:45 GMT
< Server: Apache-Coyote/1.1
Server: Apache-Coyote/1.1
* gss_init_sec_context() failed: : KDC policy rejects requestWWW-Authenticate: Negotiate
WWW-Authenticate: Negotiate
< Set-Cookie: JSESSIONID=0E94E134D7401632EBB4D042B8934DCD; Path=/
Set-Cookie: JSESSIONID=0E94E134D7401632EBB4D042B8934DCD; Path=/
< Content-Type: text/plain
Content-Type: text/plain
* no chunk, no close, no size. Assume close to signal end
I am able to open the site normally from the browser etc. Why I am I not able to authenticate here? Can someone help me understand
Two things you can try:
Remove --head. You seem to want to send a GET request, not a HEAD request.
Don't forget to provide the credentials as with this example: -u pierre:secret

Resources