I setup my /oauth and /token endpoints and start account linking in the client app. The /oauth endpoint is called with the following parameters:
{"response_type":"code","client_id":"<clientid>","redirect_uri":"https://oauth-redirect.googleusercontent.com/r/<myproject>", "state":"<state>"}
After creating the authcode and responding with a redirect to:
https://oauth-redirect.googleusercontent.com/r/xxxxxx?code=<authcode>&state=<state>
I would expect a call to the /token endpoint, but instead I get a GET request for:
/r/xxxxxx?code=<authcode>&state=<state>
What is going wrong?
It turned out to be a configuration issue with my reverse proxy which was rewriting redirects. My actions are running fine now.
Related
I have an App Runner service running a NodeJS/Express server which is a REST API. App Runner has given me the following end point -
https://example_server_random_id.awsapprunner.com
The frontend is developed using React and deployed in S3 as a static website. I have created a CloudFront distribution for serving the static content from S3 and have a default behavior (*). CloudFront has given me the following URL -
https://cloud_front_ranom_id.cloudfront.net
So I have updated the backend code to support CORS and added the CloudFront URL as allowed origin. From the React app, I am using the App Runner URL as my base URL for all the API calls. This setup works perfectly.
Now, I wanted to get rid of CORS related setup by using the CloudFront distribution as a reverser proxy to my App Runner service. To do that, I have done following -
I have added a custom origin that points to my App Runner service endpoint - https://example_server_random_id.awsapprunner.com
I have created a new behavior (/api*) that has precedence 0, so it should be handling all the requests that have "/api" in its path instead of the default behavior (*). This behavior uses the custom origin that I have created in the previous step.
I have allowed all the HTTP request (GET, POST, OPTION, PUT etc.) for this new behavior.
For the new behavior, I have used "CachingDisabled" as the Cache Policy and "All Viewer" as the Origin Request Policy.
I have replaced the base URL and use /api as the new base URL instead of the App Runner endpoint.
I did not remove the CORS related settings from the backend code (access-control-allow-origin header value is the CloudFront endpoint and access-control-allow-credential header value is true).
This setup is not working as expected. I can still access the static contents but for all the requests to the backend (with /api base URL) give me the following errors -
Cannot POST /api/users/sign-in Status Code: 404
Cannot GET /api/users Status Code: 404
etc.
Can you please let me know if there is any way to debug this and what could be the problem in the setup?
I am writing down how I fixed this in case someone faced the same issue.
The following article helped me to pinpoint the issue - https://advancedweb.hu/how-to-debug-cloudfront-origin-requests/
Basically, the problem was the cache policy I was using. I used the following webhook tester to find out the header values, query parameter and cookies and modified the cache policy to use the legacy cache settings (Appropriate header, cookies and query parameters)-
https://webhook.site/
I have a custom domain name in AWS API gateway. I am using the same domain for 2 separate API stages. One API stage is REST API, and the other HTTP API.
When I test out my setup, everything works for the REST API. However, the mapping path for HTTP API is not working and I get status-code = 404 Not Found, with 0kb body.
references used:
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-mappings.html
https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mappings.html
From my testing in postman, i get the following result when calling the custom domain.
1. {{api.gateway.custom.domain.url}}/foobar - works
2. {{api.gateway.custom.domain.url}}/this-no-work/foobar - 404
3. {{api.gateway.custom.domain.url}}/this-works/foobar - works
does anyone know why (2) gives 404? api-gateway REST API with mapping works while api-gateway HTTP API will return 404 with 0kb body. Is there something I am missing?
note: the (none) path mapping has been added for a sanity check, and I was able to get the expected response.
I had the same problem.
The problem is in the configuration of routers of your application.
When you configure one API mapping in AWS API Gateway, the configured path (this-no-work) is passed to your web application as a prefix of routes.
SO ... if you have one route like this:
/api/foobar
you need configure one more route with the prefix point to the same action:
/this-no-work/api/foobar
A good one is to make one global configuration to your web app.
You can note it enabling the cloudwatch logs of your API Gateway stage and looking into the cloudwatch logs the path property passed from API Gateway to the Web application.
Thanks to answer from #gean-ribeiro, I was able to figure why my HTTP API was returning 404 Not Found.
Turns out it was not an issue with HTTP API. The error 404 Not Found with 0kb body was coming from the API integration sitting behind APIG. Specifically, it was a load balancer using rules based on HTTP path pattern.
By default, any unmatched path pattern will return 404 with text/plain body. this-no-work was a new HTTP API I added, and it did not have the necessary listener rules.
Once I added a new listener rule for HTTP Path pattern is /this-no-work/*, it worked as expected..
when default endpoin is created in my case it uses this pattern
https://{api_id}.execute-api.{region}.amazonaws.com/
an answer might be: Disable the default endpoint for an HTTP API
more details here
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-disable-default-endpoint.html
I am trying to create an integration between EC2-ALB and Lambda functions and in a part of my code I am trying to use the method:
modify_listener() documentation available here: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/elbv2.html#ElasticLoadBalancingv2.Client.modify_listener
in that part I am using the DefaultAction: FixedResponseConfig where I am trying to display a simple hello world on html. the way this gets triggered in the code is, if my target group is unhealthy display the fixed response permissions have been setup everything looks fine because when I run the function I get a successful message but when I ask for the application from my okta portal I don't get that response (hello world) I get a normal 503 service temporary unavailable.
How can I direct that fixed response to the frontend of the app when is not working? the purpose of this is to display a maintenance page when the target group is down.
Thanks for the responses please feel free to make any question.
You can't customize ALB's error messages through fixed response. Instead you should consider two options:
use CloudFront in front of your ALB to setup Custom Error Page for Specific HTTP Status Codes
use Route53 DNS failover when your ALB becomes unhealthy.
I’m using AWS API Gateway at https://console.aws.amazon.com/apigateway/home
I did all of the steps to set up a proxy for http://foo.com (example)
I deployed it and the URL is http://bar.com (example)
When I go to http://bar.com/hello, it redirects me to http://foo.com/hello
I want it to stay at http://bar.com/hello, but deliver the contents from http://foo.com/hello like a normal proxy service
Note: My primary intent is to get around CORS issues with a service
It seems to me that whatever service you're using is forcing the redirect like #Steve's comment mentioned. They might be forcing HTTP_REFERER to be a certain domain.
Since I don't know what service you're calling this is just a guess.
I've been using WSO2 API Manager 1.9.1 for the past month on a static IP and we liked it enough to put it on Azure behind a full qualified domain name. As we are still only using for internal purposes, we shut the VM down during off hours to save money. Our Azure setup does not guarantee the same IP address each time the VM restarts. The FQDN allows us to always reach https://api.mydomain.com regardless of what happens with the VM IP.
I updated the appropriate config files to the FQDN and everything seems to be working well. However! The one issue I have and cannot seem to resolve is calling APIs from the API consoloe. No matter what I do, I get a response as below
Response Body
no content
Response Code
0
Response Headers
{
"error": "no response from server"
}
Mysteriously, I can successfully make the same calls from command line or SOAPUI. So it's something unique about the API Console. I can't seem to find anything useful in the logs or googling. I do see a recurring error but it's not very clear or even complete (seems to cut off).
[2015-11-17 21:33:21,768] ERROR - AsyncDataPublisher Reconnection failed for
Happy to provide further inputs / info. Any suggestions on root cause or where to look is appreciated. Thanks in advance for your help!
Edit#1 - adding screenshots from chrome
The API Console may not be giving you response due to following issues
If you are using https, you have to type the gateway url in browser and accept it before invoke the API from the API Console (This case there is no signed certificate in the gateway)
CORS issue which may due to your domain is not in access allow origins response of Options call
If you create a API which having https backend. You have to import endpoint SSL certificate to client-trustore.jks