Protected fields fix #5463
Protected fields fix #5463
Conversation
Add start of some more tests for protectedFields which i need to do to document the feature.
|
@awgeorge review please? |
Codecov Report
@@ Coverage Diff @@
## master #5463 +/- ##
==========================================
+ Coverage 93.91% 93.92% +0.01%
==========================================
Files 123 123
Lines 9024 9025 +1
==========================================
+ Hits 8475 8477 +2
+ Misses 549 548 -1
Continue to review full report at Codecov.
|
swallow errors.
|
ok.
when I dug into it, I discovered that it was a false fail because some of the tests were running before the @awgeorge I think we're good now to push this to clean up leaking userSensitiveFields (but not email) for users like me who use the cli to launch. |
| url: 'http://localhost:8378/1/classes/_User', | ||
| headers: { | ||
| 'X-Parse-Application-Id': 'test', | ||
| 'X-Parse-Javascript-Key': 'test', | ||
| }, | ||
| }) | ||
| .then( |
There was a problem hiding this comment.
an error with the request gets swallowed here.
| expect(fetchedUser.zip).toBe(ZIP); | ||
| expect(fetchedUser.email).toBe(undefined); | ||
| }, | ||
| e => console.error('error', e.message) |
There was a problem hiding this comment.
cause this resolves the error and we go into the then.
|
AH! forgot to run build locally. I see the failing test. |
is set without a _User permission.
|
third times a charm? I think I fully reasoned through the various states that options.protectedFields will be. when we take out sensitiveFields in the next minor release, we can get rid of all this logic.... |
|
Cheers for the patch - good to know about the CLI mode. |
* fix minor spelling mistake * Always process userSensitiveFields if they exist * Cover change to protectedFields Add start of some more tests for protectedFields which i need to do to document the feature. * re-arrange promise deck chairs to not swallow errors. * remove noop code * protect agains the case where options.protectedFields is set without a _User permission.
We launch the parse server using the cli.
I discovered after releasing parse-server@3.2.1 last night that our userSensitiveFields were leaking.
I tracked it down to the fact that the cli merges in the defaults before instantiating ParseServer.
My fix is to always process and merge userSensitiveFields if they exist.
I'd like to get this in and publish 3.2.2.