I'm trying to use a parse.com cloud function in a mailgun route action (forward).
My action is like this (with my app id and JS key included of course):
forward("https://myAppId:javascript-key:myJSkey#api.parse.com/1/functions/hello")
In the mailgun logs, I see it call, but I get the following error:
HTTP Error 401: Unauthorized Server response: 401 HTTP Error 401: Unauthorized
My function is just a simple response.send("OK");
Obviously I'm missing something.
Greg
The issue I think is that the Cloud Code calling convention requires you use special Parse headers, not just keys: it may be different if its being called from a browser with sets the referer headers. I'm not sure you'll be able to call it this way directly from Mailgun: you may need a proxy of some sort.
EDIT: I think you'll need to use the Express Webhook implementation instead, and then you can use standard basic authentication. Cloud Code is really for cases where you have control over the HTTP client you're using.
Related
I am trying to get an access token via RestTemplate.postForEntity().
myRestTemplate.postForEntity(authBaseUrl, request, Object.class);
I have a specific class for it, but let's use now a simple Object as type. It contains an access_token field.
It works, because I can get response, but the length if the access tokens (which is a string)
is 1196 character long. And I can get the same length in Postman too.
But if I use the intelliJ built-in REST client, the length is 1199.
Only the token from the intelliJ rest client works (So the longer).
Because I always get a new access token, it is impossible to get the same token twice.
How can I debug it?
What could be the problem?
Is the code that generates the response available to you? if so in your response add a header content-length so you can see what the server sent and what you received. Also, debug the server side and see what is being generated. In addition take another 3d party Http client and test it with this client see if you see a difference. The Http clients that you can try are Apache Http client, OK Http client, or my favorite - a very simplistic client written by me as part of my own Open Source MgntUtils library. Here is the Javadoc for my http client Here is a link to a similar question where you can get the references for any of above mentioned Http clients: How to check the status of POST endpoint/url in java
I made python function using AWS lambda and connected lambda with API Gateway
After then, I tested API. It worked well.
Testing in API Gateway was Successful
Now I tried to using this API with AJAX.
Javascript AJAX Code was like this
How ever result was
"jquery-3.4.1.js:9837 GET https://9i1jhuewmj.execute-api.ap-northeast-2.amazonaws.com/test/transaction?jpgname=image.jpg net::ERR_FAILED"
How can i solve this problem??
Hope for your wisdom!
Thank you
I think there are a few things. The content-type header being returned is application/json but the response is not JSON.
But I think the main problem is that the HTTP status being returned is 301. This tells the browser that this resource has been moved and the browser typically expects the response to contain information on where things are moved to so it can redirect.
I suspect if you change your configuration so that a more normal response code (i.e. 200) is returned, this will work better.
I'm building an MVC web app that uses the openID Connect hybrid flow to authenticate with Identity Server 3. The MVC web app contains jQuery scripts to get async JSON data from een ApiController. That ApiController is part of the same MVC web app.
I don't want that everyone is able to access the data from the API, so I want to secure the API as well. I added an [authorize] attribute to the ApiController. When requesting the API with a JQuery ajax request I get the following error message:
XMLHttpRequest cannot load
https://localhost:44371/identity/connect/authorize?....etc.
Response to preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:13079' is therefore not allowed
access. The response had HTTP status code 405.
But, when I do a request to the API method directly in browser, I will be correct redirected to the Login page of Identity Server..
So, what's exactly the problem here? I read something about that requesting the /authorize endpoint is not allowed via 'back-channel', but I don't understand what's the difference between 'front-channel' and 'back-channel'. Is it possible that I mixed up the wrong OAuth flows? Is the Hybrid flow not the correct one maybe?
I also find out that the API is often a seperate app, but is it always neccessary / best-practice to build a seperate API app that for example requires a bearer token?
Please point me in the right direction about this.
The authorize method on your identity server does not allow ajax calls. Even specifying CORS headers is not going to help you in this particular case. Perhaps you could return a forbidden response instead of a redirect and manually redirect the client to the desired location via window.location
You need to allow your IdentityServer to be accessed from other domains, this is done by allowing "Cross Origin Resource Sharing" or CORS for short. In IdentityServer the simplest way to allow this is in your Client configuration for your Javascript Client, see this from the IdentityServer docs on CORS:
One approach to configuing CORS is to use the AllowedCorsOrigins collection on the client configuration. Simply add the origin of the client to the collection and the default configuration in IdentityServer will consult these values to allow cross-origin calls from the origins.
The error you're seeing is the browser telling you that when it asked IdentityServer if it allows requests from your Javscript client, it returned a response basically saying no, because the origin (http://localhost:13079) was not specified in the "Access-Control-Allow-Origin" response header. In fact that header wasn't in the response at all meaning CORS is not enabled.
If you follow the quickstart for adding a JavaScript client from the docs here all the necessary code is detailed there that you need for the Client config and to setup IdentityServer to allow CORS.
I have my own instance of Parse Server running on AWS and until now Cloud Functions have been working great, but with one caveat: they cannot be successfully called publicly, i.e. they require an authorisation key be sent in the REST request header.
I want to set up a Slack Slash Command to my server, and it has to be able to POST a payload without any headers or extra parameters. As a result, my requests are currently unauthorised (returning 403 statuses).
Is there a way to create granular control over a Parse Cloud Function's authorisation (i.e. if it requires master-key header or not), and if not — is there a way of forwarding the request but still through the Parse server?—Or even a way of manipulating the headers of a Slack request? I would rather not have to use another service just for request forwarding.
Thanks!
Two options
Pass in the master key on the client request which should bypass authorization. It's a blunt approach but might be okay in your case (without knowing more details).
Or run a new express endpoint alongside parse and from there call the parse cloud function using the masker key.
var api = new ParseServer(...)
var app = express();
app.use('/parse', api);
app.get('/api/slack', function(req, res) {
//call cloud function passing in master key
// add X-Parse-Master-Key as http header
unirest.post("http://myhost.com:1337/parse/functions/mycloudfunction")
.headers({'X-Parse-Master-Key', MASTER_KEY)
.end(function(response) {
}
I am currently trying to setup AWS Api Gateway, to proxy to another api, that has fully functional methods, response content, status codes etc. This is fairly simple to setup, but I have noticed that the Api Gateway always returns 200 OK no matter what the origin api responds with.
Fx. if there was a bad request (in the origin api) which results in a error message in JSON and a 400 Bad Request, the Api Gateway will respond with a the exact same error message, but a status code of 200 OK
If I remove all settings from the Message Response in the API Gateway web-interface, I get an internal error in the API Gateway. Can it be true that I have to map all the different status codes from the origin api manually in the Api Gateway?
I would prefer if it was possible to just let the status code (as well as the response, which currently works great) pass through, and not have the Api Gateway touch it in any way.
Proxy integration can be used to achieve this. In this case, it is HTTP Proxy. Lambda Proxy integration can also be used but will need some code logic in lambda. API GW will then return the result as-is.
You are correct that currently when using API Gateway you are required to map all response codes in your integration responses. We have heard this "pass through" request from other customers and we may consider including this in future updates to the service.