fix: IPv6 ranges not recognized for options masterKeyIPs, maintenanceKeyIPs

[dblythy]

Pull Request

• Report security issues confidentially.
• Any contribution is under this license.
• Link this pull request to an issue.

Issue

Currently, an ipv6 range does not seem to validate ipv4 addresses

Closes: #8421

Approach

Adds cases to allow all IPs

Tasks

• Add tests
• Add changes to documentation (guides, repository pages, code comments)

[parse-github-assistant]

I will reformat the title to use the proper commit message syntax.

[parse-github-assistant]

Thanks for opening this pull request!

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (8d3117e) 94.32% compared to head (2b284a4) 94.34%.

❗ Current head 2b284a4 differs from pull request most recent head 8ca0279. Consider uploading reports for the commit 8ca0279 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##            alpha    #8501      +/-   ##
==========================================
+ Coverage   94.32%   94.34%   +0.02%     
==========================================
  Files         186      186              
  Lines       14780    14795      +15     
==========================================
+ Hits        13941    13959      +18     
+ Misses        839      836       -3     

Files	Coverage Δ
src/middlewares.js	96.96% <100.00%> (+0.14%)	⬆️

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Moumouls]

i'll send a pr, we are not going in the right way here...

[dblythy]

?

[Moumouls]

@dblythy i'll send a pr in 1hour hold on 🙂

[Moumouls]

Here my implementation suggestion #8510

[mtrezza]

@dblythy Could you please update your PR to get it ready for merge? #8510 is stale and @Moumouls isn't responding, so let's proceed with this PR.

[mtrezza]

Does this PR contain code of #8510, or is there anything it should contain?

[mtrezza]

Looks good

[mtrezza]

@andreisucman Could you test out this PR and see if it resolves the issue you described?

[andreisucman]

@mtrezza Here is my test:

1. I deleted node modules and package-lock.json
2. I added parse server from this PR like so: "parse-server": "github:parse-community/parse-server#pull/8501", and ran npm i
3. I set fake IP addresses to the .env like so "fe80::ddc6:9db0:e1c5:6000%12,192.112.68.125"
   They get split into an array in the server config like so masterKeyIps: process.env.MASTER_KEY_IPS.split(","),
4. I tested changing user name via a cloud function, which involves saving the User object with the master key like so:

if (name.length < 4) return;
      rUser.set("name", name);
      await rUser.save(null, {
        useMasterKey: true,
 });

The operation ran with success on both localhost and production. No error logs.

[mtrezza]

Maybe that's because it's via Cloud Function, could you try again with an actual client (or via REST API) from outside of Cloud Code?

[andreisucman]

@mtrezza Ok, I tested again in live environment

--- Test 1

Firstly I tested the current version - 6.3-alpha.3. just in case.

1. I set the allowedIps to the same fake values "fe80::ddc6:9db0:e1c5:6000%12,192.112.68.125" and applied to the cluster
2. I replaced the existing pods with new to use the update config
3. Then I downloaded the config from the cluster and confirmed that allowedIps are set to the fake string
4. Then I ran this function in node js using parse node sdk.

    require("dotenv").config();
    const Parse = require("parse/node");

    Parse.initialize(process.env.APP_ID, undefined, process.env.MASTER_KEY);
    Parse.serverURL = `${process.env.SERVER_URL}/parse`;
    const toSave = [];
    ...
    await Parse.Object.saveAll(toSave, { useMasterKey: true });

It worked with success even though the allowedIps has fake values different from the ingress ip.

----- Test 2

1. I deleted node modules and package-lock.json
2. I set the server to "parse-server": "github:parse-community/parse-server#pull/8501",
3. I rebuilt the image and checked that my docker registry has only this single image (pushed a few seconds ago)
4. I deleted the pods with the existing app
5. I downloaded the cluster secret config and confirmed that the allowedIps are set to the fake Ips string "fe80::ddc6:9db0:e1c5:6000%12,192.112.68.125" (in its base64 encoded form - ZmU4MDo6ZGRjNjo5ZGIwOmUxYzU6NjAwMCUxMiwxOTIuMTEyLjY4LjEyNQ==)
6. I installed new app pods with the current secret config
7. I ran the same function from previous test using nodejs sdk and it succeeded.

Nothing is hardcoded in my app, so I'm pretty sure that the app used the provided fake allowedIps.

I recommend you to take my fake allowedIps values and test it on your end. And when you confirm that its working correctly on your dev server, I can test again in my live environment.

These 2 tests were for masterKeyIps option set to a different IP that is not in use.

And for this test masterKeyIps option set to the foreign (non-localhost) IP that you are making the request from and no ip addresses set, I can't do them as they would require dealing with pod ip addresses and rebuilding helm charts - too much work atm.

Maybe you could test it in a simplified production environment on your end.

[Moumouls]

The other pr is ready: #8510

[mtrezza]

Closing via #8510