Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse Server option masterKeyIps not working #8512

Closed
3 tasks done
magnacartatron opened this issue Apr 15, 2023 · 11 comments
Closed
3 tasks done

Parse Server option masterKeyIps not working #8512

magnacartatron opened this issue Apr 15, 2023 · 11 comments
Labels
type:bug Impaired feature or lacking behavior that is likely assumed

Comments

@magnacartatron
Copy link

New Issue Checklist

Issue Description

Parse Server Option masterKeyIps not working as intended.

We've set the field as where x and y are real ips redacted for security
masterKeyIps: ['x.x.x.x','y.y.y.y']

Using a query like

const result = new Parse.Query("ClassName").find({useMasterKey: true});

from an external server with said ip address 'x.x.x.x' or 'y.y.y.y' doesn't perform operation using masterKey.

Errors returned are e.g. Permission denied for action find on class ClassName.

This code works perfectly fine in Parse Version 4. We haven't tested on 5, but we're getting these results on 6.

Which indicates the useMasterKey option is not being passed through.

Steps to reproduce

  1. Create a parse server
  2. Create a separate server
  3. Create a class and place security permissions to make it as tight as possible
  4. Set the ip of the second server in the masterKeyIps parse server option
  5. Initialise parse/node on the second server and provide the appId and valid masterKey of the parse server
  6. Attempt to execute a query on the class using {useMasterKey: true}

Actual Outcome

Permission denied for action find on class ClassName.

Expected Outcome

Actual result of the query

Environment

Server

  • Parse Server version: 6.1.0-alpha.2
  • Operating system: Ubuntu20
  • Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): AWS

Database

  • System (MongoDB or Postgres): MongoDB
  • Database version: `5.0.10
  • Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): MongoDB Atlas

Client

  • SDK (iOS, Android, JavaScript, PHP, Unity, etc): Javascript
  • SDK version: 4.0.1

Logs

@parse-github-assistant
Copy link

Thanks for opening this issue!

  • 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

@mtrezza
Copy link
Member

mtrezza commented Apr 15, 2023

Is there any server log message? May be related to #8421.

@mtrezza mtrezza added the type:bug Impaired feature or lacking behavior that is likely assumed label Apr 15, 2023
@magnacartatron
Copy link
Author

magnacartatron commented Apr 15, 2023

As soon as we enable all ips its it works fine. Localhost also obviously works fine.

It's only when we specify. I thought it might be because server was behind proxy or load balancers but we created multiple server instances with fixed ips. Tried in multiple environments and are experiencing the same issue.

Unless we're doing something completely wrong but I think the documentation is fairly self explanatory.

We dug deep into the parse-server code. The ips definitely get validated not sure at what point it all falls over.

We run on dokku and there's no output logs.

Bootstrapping on top of express '4.17.3'

The only middleware we use is Sentry to trap all errors

app.use(Sentry.Handlers.requestHandler() as express.RequestHandler);

As soon as we turn on the tap we start to get thousands of errors and most of them are in the following format

'Error: Permission denied for action find on class'

Regarding permissions they're tied down but currently not via the ParseOptionsSchema, will be raising a few bugs there.

Again on version 4 everything runs fine, so currently we have two production servers running simultaneously until we can kill version 4 because of this issue.

Edit: To answer your questions @mtrezza yes we looked in depth at that issue because it's really the only one that exists out there but I don't think it applies. We're not using ip ranges, and it's no ipv6 and were we to use local host we can replicate that just fine. Normally we wouldn't run a separate server and access via masterkey but we have some brutal long queries that affect performance on the parse server and link to other external services so we've decoupled the two. We could probably setup another full parse server there but we didn't think the masterIp list would become an issue.

@mtrezza
Copy link
Member

mtrezza commented Apr 15, 2023

Parse Server should output the IP address that has been blocked in the logs (not sure from which version though). Adding exactly that IP address should work. Is there no way for you to access the logs?

@magnacartatron
Copy link
Author

I had a chance to and the output seems empty

parse-server.err.2023-04-15 parse-server.info.2023-04-15
root@0d69cc501484:/app/logs# more parse-server.err.2023-04-15
root@0d69cc501484:/app/logs# more parse-server.info.2023-04-15
root@0d69cc501484:/app/logs#

@Moumouls
Copy link
Member

With some luck @magnacartatron my pr will fix your issue: #8510

@magnacartatron

This comment was marked as off-topic.

@Moumouls

This comment was marked as off-topic.

@magnacartatron

This comment was marked as off-topic.

@mtrezza
Copy link
Member

mtrezza commented Apr 20, 2023

@magnacartatron Were you able to try out the PR suggested in #8512 (comment) to fix this issue? For off-topic discussions we recommend our community forum or community chat.

Regarding the logs, they should not be empty, at least a start-up log entry should be written by Parse Server. And if you set the appropriate log level and/or the env var VERBOSE=1, you should see much more. In any case, a block due to masterKeyIps should be logged, depending on the Parse Server version. Without any logs we may as well close this issue because we'd just be guessing in the dark.

@mtrezza
Copy link
Member

mtrezza commented Oct 9, 2024

Closing, as this seems to be have been fixed and no further update provided.

@mtrezza mtrezza closed this as completed Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Impaired feature or lacking behavior that is likely assumed
Projects
None yet
Development

No branches or pull requests

3 participants