[PROPOSAL] Change X-Parse-Application-Id header

[tomcooperandco]

Is it / would it easily be possible to change the description of X-Parse-Application-Id to something more generic such as "app-id", or remove the requirement for it all together?

[flovilmart]

why would be the benefit?

[bohemima]

(Removing it completely) Less bytes to send over the pipes!

Since it was already stated that you would (probably) not going to be able to run multiple instances of ParseServer within the same app there is no real benefit to have appId at all. It's checked for but does not give any extra security or anything really.

[flovilmart]

That would require somewhat of a refactoring, but that's feasible on the server.

On the client SDKs, they will probably keep setting the headers, the refactoring is more important there.

And regarding the multiple apps support, as long as you don't have any cloud code, that'a already architectured to support it. If you're using HTTP hooks, you should see no issue running multiple apps.

So to sum up:

• feasible on parse-server, but we need to keep it for supporting multiple apps
• needs update on all the clients, to remove sending all the headers to be really effective
• supporting multiple apps on the same server could work by spawning short lived subprocesses for each trigger, that would impact the performance but guarantee isolation, i Just haven't had the time to move further in that implementation.

My personal stance:

I won't work on it as of right now as I need the clients to send those information (all the requests are proxied through nginx that route to the right backend given the application ID header)

All that being said, if someone want to work on it, feel free to do so, and open a PR.

[tomcooperandco]

Agree with @bohemima however my reasoning is commercial. If you have a public facing API, you don't necessarily want "X-Parse-Application-Id".

[flovilmart]

@pantri X-Parse-Application-Id is far from being the only header sent to the server. So on that stance, and it it's to run commercial operations and hide that Parse-server is powering what you sell, I pretty much will disavow any change in that direction on the master code base.

[tomcooperandco]

@flovilmart more from a point of view of in my instance I'm looking for users to make API calls into a service (& will write a manual how to do so). When it comes to the X-Parse-Application-Id the issue becomes theres no point in my instance having it present. As @bohemima said, its just not necessary in some instances.

I'm not trying to hide the use of Parse & on the contrary want to promote it, in the same way as you say I'm using an Angular front-end, but from my point of view its just a really unnecessary piece of work for my users to input - a bit like asking for gender on a signup form when I don't need it, just extra unnecessary workload.

Perhaps some form of bypass switch is all thats needed, so that it can be turned on & off as necessary?

I really do think that this is a plus for Parse Server, rather than a detraction.

[flovilmart]

@pantri maybe there is no point for you, but there's a need for me to have them.

Removing it from parse-server would be somewhat trivial, but you'd have to update all the client SDKs to make sure it's effective, and provide backward compatible support as I'm still working on solutions for multiple apps on the same server.
If this is really important for all of you, you should start working on it.

On another note, if you wish to contribute, there's a 100+ open isssues that beg to be resolved and that are probably more important than than reducting from a few bytes the requests IMHO.

[tomcooperandco]

@flovilmart agree, some people do & some people don't. I just think that it would be a positive feature to have the option to turn it on or off as the individual use case sees fit. My competency doesn't stretch far enough unfortunately, otherwise I would be more active than making suggestions.

That being said, I have a few pennies in my pocket & would happily fund the development of this if someone is interested.

[sunshineo]

Hello, I'd like to provide a case I encountered that supports removing the x-parse-application-id header.

We need a 3rd party service to post back some data to us. Their service is limited and only supports specify an url. Without the ability to specify the x-parse-application-id header, the post would fail.

Our solution is to use a proxy to add the header before hand it to our parse server.

const proxy = require('express-http-proxy');
...
app.use('/proxy', proxy('localhost:1337', {
  proxyReqOptDecorator: function(proxyReqOpts, srcReq) {
    // you can update headers
    proxyReqOpts.headers['x-parse-application-id'] = 'myAppId';
    return proxyReqOpts;
  }
}));

This increases latency and complexity for us. If we do not see x-parse-application-id has any real value in the future, we should remove it. Can we re-open this proposal?

[omairvaiyani]

Depending on your node.js/express setup, you could just host a public route that takes requests without any headers, and forward them to your business layer, skipping out this proxy approach. There shouldn't be any measurable latency with this method. You can have non-parse-server routes on the same express app.

[sunshineo]

Thank you @omairvaiyani . How do you do that exactly? Our business logic is already in a parse cloud function (and has to be in a parse cloud function). Can the express code call parse functions??

[omairvaiyani]

In an ideal setup, you should decouple your functions from Parse.Cloud.define, making them easier to test and execute from a non-Parse scope. Example:

// function file
const doThing = async function(params, saveOptions) {
  await user.save({ foo: params.foo }, saveOptions);
  return { foo: user.get('foo') }
}

Parse.Cloud.define('doThing', async function (request) {
   return doThing(request.params, { sessionToken: user.getSessionToken() });
})

export { doThing }

// express route
import  { doThing } from '../path/to/function';
 
app.post('/webhook-do-thing', async (req, response) => {
   try {
      // optional - pass auth data option if needed
      const result = await doThing(req.body, { useMasterKey: true })
      // response with appropriate success message
   } catch (e) {
      // respond with appropriate error code
    }
})

[sunshineo]

That's interesting. So even not inside Parse.Cloud.define , I can use all the Parse Cloud functionalities like make query or update entity?

[omairvaiyani]

Yup, as long as you're using parse-server as an express middleware inside your application, you should have full usage of the parse javascript sdk

[sunshineo]

@omairvaiyani I tried your solution. It works but with some caveats. My function used req.params but you have to change it to req.body and install bodyparser https://www.npmjs.com/package/body-parser

I think we should re-open this proposal. Would the change be really simple or very complicated because there are other parts coupled together?

[sunshineo]

Hello everyone, I have a new solution to this problem by automatically add the header for all the requests but unfortunately breaks the dashboard

app.use('/parse', (req, res, next) => {
  headers['x-parse-application-id'] = 'yourAppId'
  next()
})
const parseApi = new ParseServer({
... your configs
})
app.use('/parse', parseApi);

The reason the dashboard breaks is that it is not using the HTTP headers but POST request to specify in the POST body all the time for efficiency reason according to this post parse-community/Parse-SDK-JS#630

For us, we have a temp workaround with

if (headers['x-parse-session-token'] || headers['x-parse-master-key']) {
    headers['x-parse-application-id'] = 'pipe17'
}

But this will not work for public facing endpoints, those still need the client to add the header. Any suggestions?