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) {
}
Related
I have a http route /checkout which initiates a workflow process in Zeebe. The checkout route will return 200 response straight-away to calling client. Now, workflow will run for a while. So to push the response back to client after completion, I have a /sse separate route for server-sent events. Here, I will store all the client connection in a global map.
My doubt is how do I find the exact client to send the response back through sse once?
Example: Client A listening to /sse and calls /checkout endpoint which will return 200. The /sse has to return the response to client A after completion.
Currently, I thought of using cookie to identify the client. Is there a better way?
If you are already using cookies in your app than that's the way to go since the very purpose of cookies is identifying the client, so if you already have that, you should use it.
But if you rely on another authentication mechanism (like JWT), what you could do is using the url as a query.
So in the client instead of
let eventSource = new EventSource("/sse");
Do
let eventSource = new EventSource("/sse?authorization=jwt_token");
In the backend, you would validate that token, extract the Client ID and hit that global map with it to retrieve the corresponding connection.
(PS: instead of a global map, you should use a proper store, like redis, or an embedded key/value store like bbolt)
I'm having a CORS related issue with google cloud run on a service that
requires authentication.
If I try to execute a curl command through the cli, with a Bearer token,
everything works fine.
Unfortunately if I try to execute the same call through ajax in javascript,
I receive a 403.
const http = new XMLHttpRequest();
const url = 'https://my-app.run.app';
http.open("GET", url);
http.withCredentials = true;
http.setRequestHeader("authorization", 'Bearer ' + id_token);
http.send();
http.onreadystatechange = (e) => {
console.log(http.responseText)
}
The error in the cloud run logs is this :
The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header. Read more at https://cloud.google.com/run/docs/securing/authenticating
The container is never hit.
The issue I'm seeing is that, as I'm making the call using ajax, in a web
browser. The web browser is making a pre flight request ( OPTIONS on the
url ) without sending the Authorization header ( which is an expected
behavior )
The problem seems to be that cloud run tries to authenticate the OPTIONS
request and never makes it to my container, which, as far as I understand,
shouldn't be done. (
https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 )
Is that a known issue with cloud run ?
How could I make an ajax request to an authenticated cloud run service ?
(Cloud Run PM)
This is a known issue. There are a few options:
Allow unauthenticated requests and do CORS/auth yourself
There is a variation of this that uses Cloud Endpoints running on Cloud Run in front of your compute. Have Endpoints do your end-user auth, then forward the request to your backend.
Serve from the same domain (e.g. use the Firebase Hosting proxy)
We've considered implementing Istio CORSPolicy, which would return CORS headers before the auth check, though we're not committed to this as of now.
Is it possible to trigger a file download in a browser from the GraphQL endpoint on an apollo-server-express application?
I have the endpoint written in a standard express app.get function (see below) but I would like to make use of the GraphQL context for file download and so I'm wondering if it's possible to cause a download from a GraphQL endpoint.
Here's a bare-bones example of what I have on the express end in the app.get function:
app.get('/download-batch/:batchId', async (req, res) => {
res.send(new Buffer('test'));
});
Any help would me much appreciated. Thanks!
Yes, but you would be required to create a custom endpoint for that. You can't use the existing endpoint which you are using for making requests.
Using the custom endpoint, you have to add a middleware and process the data into a buffer or whatever format you need. But it would not be recommended. That would again become one more endpoint instead which you can write an API to serve that.(After all graphql is built mainly on the focus of single endpoint).
Boštjan Cigan mentions here some solutions and gives details about using GraphQL as a proxy with Minio. The backend would ask Mino to generate a temporary link that can be sent back to the browser for direct access.
This is a valid solution for many use cases.
This might be opinion based, but I still wonder is there a best practice since I'm almost clueless about websocket practices
I have a SPA that gets a JWT token from my own OP. It then uses that JWT to connect to other services I own using both REST and WebSockets.
As far as it goes for REST, it's pretty straightforward:
The REST API validates the JWT (sent in Authorization: Bearer ...) and provides access to the protected resource or responds with a 401, letting the SPA know it needs to request a new token.
Now with websockets :
During the load of the SPA, once I got a token, I'm opening a WS to my webservice. First message I send is a login_message with my JWT, which then I keep on server's websocket instance to know who's sending the messages.
Each subsequent message I receive, I validate the JWT to see if it's expired.
Once it has expired as far as I understand, I'm facing two options :
Drop the websocket with a token_expired error of some kind and force the browser to establish a new websocket connection once the token get refreshed.
Keep the websocket open, return an error message and send a new login message (once token is refreshed)
Don't use a login message but just send the JWT in each request.
Question : Which method would you recommend and why? In terms of security, and performance. Are there any other common practice I did not listed?
Quite an old question I've asked, so I'd be happy to share our chosen practice:
Once the client gets his JWT for the first time (when the application starts), a WebSocket is opened.
To authenticate the channel, we send a message that we define as part of our protocol, called authMessage which contains that JWT.
The server stores this data on the socket's instance and verifies it's validity/expiry before sending data down the wire or receiving from the client.
The token gets refreshed silently in web application minutes before it is expired and another authMessage is issued to the server (repeat from step 2).
If for whatever reason it gets expired before getting renewed, the server closes that socket.
This is roughly what we have implemented in our application (without optimization) and worked really well for us.
Oauth2 flow has two options to renew the token. As you said on of these options is prompt a message to the use to enforce a new login process.
The other option is to use the refresh_token in which you will avoid this login process to your user, every time the session expires and renew the token in a silent way.
In both case, you need to store the jwt in the client (commonly after login) and update it (after interactive login or silent regeneration). Localstorage, store or just a simple global variable are alternatives to handle the store and update the jwt in he client.
As we can see, jwt regeneration is solved following oauth2 spec and is performed at client side, SPA in your case.
So the next question is: How can I pass this jwt (new or renewed) to the external resources (classic rest api or your websocket)?
Classic Rest Api
In this case as probably you know, send the jwt is easy using http headers. In each http invocation we can send the old/valid jwt or the renewed jwt as header, commonly Authorization: Bearer ...
Websocket
In this case it's not so easy because according to a quickly review, there are not a clear way to update headers or any other "metadata" once the connection was established:
how to pass Authorization Bearer access token in websocket javascript client
HTTP headers in Websockets client API
What's more, there is no concept of headers, so you need to send this information (jwt in your case) to your websocket using:
protocols
var ws = new WebSocket("ws://example.com/path", ["protocol1", "protocol2"]);
cookies
document.cookie = 'MyJwt=' + jwt + ';'
var ws = new WebSocket(
'wss://localhost:9000/wss/'
);
simple get parameters
var ws = new WebSocket("ws://example.com/service?key1=value1&key2=value2");
Websocket only receive text
And according to the following links, websocket can extract header, get parameters and protocol just at the stabilization stage:
https://medium.com/hackernoon/implementing-a-websocket-server-with-node-js-d9b78ec5ffa8
https://www.pubnub.com/blog/nodejs-websocket-programming-examples/
https://medium.com/#martin.sikora/node-js-websocket-simple-chat-tutorial-2def3a841b61
After that, websocket server only receive text:
const http = require('http');
const WebSocketServer = require('websocket').server;
const server = http.createServer();
server.listen(9898);
const wsServer = new WebSocketServer({
httpServer: server
});
wsServer.on('request', function(request) {
const connection = request.accept(null, request.origin);
connection.on('message', function(message) {
//I can receive just text
console.log('Received Message:', message.utf8Data);
connection.sendUTF('Hi this is WebSocket server!');
});
connection.on('close', function(reasonCode, description) {
console.log('Client has disconnected.');
});
});
Send jwt in each request
Having analyzed the previous topics, the only way to send the new o renew token to your websocker backend is sending it in each request:
const ws = new WebSocket('ws://localhost:3210', ['json', 'xml']);
ws.addEventListener('open', () => {
const data = {
jwt: '2994630d-0620-47fe-8720-7287036926cd',
message: 'Hello from the client!'
}
const json = JSON.stringify(data);
ws.send(json);
});
Not covered topics
how perform a jwt regeneration using refresh_token
how handle silent regeneration
Let me know if you need this not covered topics.
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.