I have an AWS API Gateway endpoint that uses lambda proxy integration to retrieve data from an AWS RDS instance.
I use a yaml file to re-deploy the api, Once the API is re-deployed, The endpoint, illustrated above, throws an "Internal Server Error" every time I re-deploy the api.
The error goes off if I uncheck and then check the lambda proxy integration option/tick-box on the endpoint. This manual step is cumbersome and extremely unintuitive and can raise serious production issues.
Anyone facing similar issue know how to solve it without the additional "unchecking and checking" (manual) step?
What change in YAML can solve this problem ?
Under your AWS::ApiGateway::Method resource, make your Integration.Type as AWS_PROXY
https://docs.aws.amazon.com/apigateway/api-reference/resource/integration/#type
Related
I have a function app which is hosted in my GCP project with authentication turned on.
This app will be triggered from Jfrog container registry webhook based on events.
The issue I face here is to authenticate/authorize the HTTP request. I tried using "Authorization: bearer " header, which works good. But that token seems to expire after 60 minutes.
Q: Is there a permanent way(with no expiration) to authorize/authenticate cloud function HTTP requests ? Jfrog webhooks cannot programmatically create tokens since it's a simple HTTP POST trigger which can accept additional headers.
I am finding it hard to get a solution from GCP documentation. I do have the service account created with "roles/cloudfunctions.invoker" role.
Reference about Jfrog artifactory webhooks: https://www.jfrog.com/confluence/display/JFROG/Webhooks
It's for that reason I wrote that article. It's based on ESPv2 and Cloud Run, but API Gateway is the managed version of that technical stack. The principle and the OpenAPI spec is the same.
The solution downgrade the security level from a short lived token (1h) to long lived token (no limit). But you can use API Gateway to ensure the API Key check and query forward.
A much more simpler pattern is to remove the authentication check on Cloud Functions (and make it public) and to perform that API key (in fact a random string comparison) in your functions itself.
In both case, the API is publicly accessible (API Gateway, or Cloud Functions) and, in case of DDoS attack, nothing will protect your service (and your money). Set the correct Cloud Functions Max instance to prevent any bad surprise.
Recently I've started to use Secrets Manager to read credentials from Lambda, and I noticed that reading a secret from SM takes several seconds. Introducing VPC interface endpoint as described here: https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html#vpc-endpoint didn't help, I see the same response time.
In CloudTrail I see that created VPC endpoint is used to call Secrets Manager.
Did anyone have similar issue?
I am working in IVR team. I write SOAP web services, write java client to access those web services and set data in the session variables of the CISCO API and IVR can then able to access that data. I am very good at this.
Currently, my manager plans to move from CISCO IVR to Amazon Connect. Amazon Connect has all infrastructure and IVR can be set up in 45 minutes.
My task is to access existing legacy SOAP web services(which has access to our databases) in AWS Lambda and give that data to IVR.
I went through all the documentation, but not able to figure out where to start. Could some one give me guidance on where to start.
Here's an article about calling SOAP services from a Lambda function, with a walkthrough of the process: https://blog.codecentric.de/en/2016/12/serverless-soap-legacy-api-integration-java-aws-lambda-aws-api-gateway/
It goes further than what you may need, adding API gateway on top of the Lambda function. You may not need that if you're just planning to call those Lambda functions from Connect.
There's also an article in Connect documentation on integrating with Lambda: http://docs.aws.amazon.com/connect/latest/adminguide/connect-lambda-functions.html
GET, PUT, DELETE request work fine, but everytime i make a POST request I get an 500 status code. I have no idea where to start debuggin or what to look for. My api is depolyed on Microsoft Azure.
Any tips on what to look for or how to solve this issue would be much appriciated. I know a 500 status code, could be pretty much anything, but i find it really wierd that POST is the only request that dosn't work.
I have no idea where to start debuggin or what to look for. My api is depolyed on Microsoft Azure.
Please make sure your API application could run fine locally before you deploy it to Azure. Besides, http 500 error indicates the server encountered an unexpected condition, if you deploy your app to Azure app service, you could remote debugging web apps to troubleshoot the issue. If you publish it as cloud service Web role, you could try to use Azure compute emulator to debug your cloud service on a local machine.
When I accessed this URL http://my.domain.com:9763/services/Test_DataService.SOAP12Endpoint, I received the message bellow:
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<soapenv:Reason xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Text xml:lang="en-US">
The endpoint reference (EPR) for the Operation not found is /services/User_DataService.SOAP12Endpoint and the WSA Action = null. If this EPR was previously reachable, please contact the server administrator.
</soapenv:Text>
</soapenv:Reason>
I tested the WSO2 DSS 2.7 and 3 local and remote with Oracle RDS on Amazon (the same error on all cases).
What's happening?
It looks like you are accessing the service in a wrong way.
As you might know, WSO2 Data Services Server uses Axis2 services to expose your data service as a web service.
So, you should know how to invoke Web (Axis2) services from a client.
When you successfully create a data service, you should be able to see the relevant service in the services list. Then you can use the "Service Dashboard" to view the service's WSDL and manage QoS
Following error from Axis2 usually indicate that you are not invoking the web service properly.
The endpoint reference (EPR) for the Operation not found is /services/User_DataService.SOAP12Endpoint and the WSA Action = null. If this EPR was previously reachable, please contact the server administrator.
You should be able to test the service from in-built Try It feature from Service Dashboard. soapUI is also a great tool to test Web Services. You can just point the WSDL in soapUI and create a project. You can then manually invoke listed service operations under the soapUI project.
I hope this helps!