I've set up an API gateway to a lambda function. It's a really simple POST call to a simple function that takes a string in and returns a string.
The call works but when I configured the API call's authorization to require AWS_IAM it just kept allowing calls to succeed - even calls from a simple little test app I wrote that makes no attempt to set authorization parameters. It's the same from Postman - I set it to no authorization and it still works.
I have to be missing something.
Can anyone tell me what, please?
Thanks,
Adam.
Did you remember to redeploy the API to your stage after updating the method to require AWS_IAM authorization?
Related
We are trying to set up an api interface between two web-applications. When testing the GET call, it works from PostMan while not working from soapUI. The web-apps seems to be failing like soapUI.
I am hoping that if we can identify and understand the difference, we can resolve the issue.
Some info:
Both use Basic Authentication with a username and password (they both seem to be allowed access, as authenticated POST calls work from both testing tools).
From neither of the tools do we pass any parameter explicitly. It's a static URL we are calling to. However, the URL does include a resource-id (a target report) that could be set up as a template parameter if we wanted to.
When making the call from soapUI, the log on the application that is supposed to respond to the GET says javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"reportExecution").
The call we use is something like GET [endpoint]/jasperserver-pro/rest_v2/reportExecutions/0cc3aefc-29b6-45b1-8248-ae4e1457bb87/status
Update: By now I am quite sure this has to do with cookies. The request id 0cc3aefc-29b6-45b1-8248-ae4e1457bb87 above was received in a previous call and you need to to request the status with the same access token, which you can do with Cookies, but setting that up in soapUI is no simple matter (at least not for me). In PostMan this seems to be the standard behaviour, and hence the difference in result.
Best regards
Pieka
I'm using Meteor 1.6 and Restivus v0.8.12 to define a few REST endpoints.
Restivus has only two options for authRequired:
true -> auth is required and API function isn't called otherwise
false -> authorization isn't performed even if credentials are submitted
I have an endpoint where I'd like authentication to be optional. That is, if they submit their userId and token credentials, then authenticate them as normal and define this.userId. If they don't, then leave this.userId undefined, but still call the action. Is this possible?
The alternatives I'm considering are either defining different endpoints (e.g. GET /record/:recordId/authenticated and GET /record/:recordId/public) or getting the raw Headers from the request and doing the authentication myself.
The first option makes the semantics of the API confusing and will involve duplicating the action function, while the second one re-invents the authentication process (probably poorly, since I'd be writing my own function :-)
Is there a better option available?
I would like to use an API Gateway HTTP integration towards an endpoint, where certain parts of the URL are provided by the custom authorizer (e.g., user ID or user grants).
I could definitely use a Lambda integration but that introduces quite significant response time overhead.
Unfortunately syntax that works for stageVariables does not seem to work for custom authorizer context - ${context.authorizer.variableName}.
Note: To answer some comments, yes, the warning sign is there bacause I used a dummy url string. Has nothing to do with the fact that replacement of authorizer context variables does not work for me, no matter what the URL is.
The URL needs to valid, meaning like https://example.com/foo with a protocol and hostname.
Starting with url/ is never going to be valid.
The SpringXDTemplate is the SpringXD java client. Build around the REST API it doesn't support Basic Authentication required by the same API:
the REST endpoints will require Basic authentication for access;
Furthermore the RestTemplate used undernet is not accessible cutting the possibility to implement the Basic Auth at lower level.
Perhaps i'm missing something? Advices are suggestions are appreciated!
I don't know this API but looking at javadocs, I see a constructor of template that accepts ClientHttpRequestFactory. So maybe if you try to pass your own implementation that will append HTTP Authorization header with basic authentication when createRequest is invoked, that may solve your problem. Otherwise I don't see other way how to "get into" the process of template.
I'm trying to Enable/Disable a logic app on Azure using the management APIs. I always get a 403 saying the client: with object id does not have authorization to perform 'Microsoft.Logic/workflows/disable/action' ...
I do use the authentication token in my request and so far have been able to use the API to list all workflows, get trigger histories and in/out messages using the same method.
Any suggestion?
I've seen this issue a lot before if you are calling the http:// instead of https:// - we are looking into automatically redirecting, but for now you will need to make sure you are calling the https:// endpoint with the correct method (in this case a PUT)
EDIT: We discovered the issue was the account being used to perform the enable/disable didn't have contribute permissions.