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

Unexpected behavior on the exists method #8117

Open
codeKonami opened this issue Apr 6, 2020 · 8 comments
Open

Unexpected behavior on the exists method #8117

codeKonami opened this issue Apr 6, 2020 · 8 comments
Labels
type:bug Impaired feature or lacking behavior that is likely assumed

Comments

@codeKonami
Copy link

Issue Description

An object exists in the database. You need a sessionToken to access it.

If you use the Parse.Object exists method without sessionToken instead of throwing an error, it resolves with the value false. I think it's quite an unexpected behavior. It's caused by theses lines of code

https:/parse-community/Parse-SDK-JS/blob/f2d76805000488fefce2b0c2e73d8953007f2b1c/src/ParseObject.js#L972-L974

And comes from this discussion : parse-community/Parse-SDK-JS#898 (comment)

Steps to reproduce

  • Create an object in database with limited access
  • Try Catch the exits method without any sessionToken

Expected Results

It should throw an error

Actual Outcome

It does not throw, it returns false as if the object do not exist

Test Case

To accurately reproduce your issue. Add your test cases here and read the Contributing Guide to run the tests.

Environment Setup

  • Server

    • parse-server version (Be specific! Don't say 'latest'.) : 4.1.0
    • Operating System: MacOS
    • Localhost or remote server? localhost
  • JS SDK

    • JS SDK version: [FILL THIS OUT]
    • Application? (Browser, Node, React-Native, etc): [FILL THIS OUT]

Logs/Trace

@davimacedo
Copy link
Member

In my opinion, that's the right behavior. If the user does not have access to this object, they should not be able to know if it exists and receiving always false (no matter it exists or not) looks a good solution for me. If we throw an error, the user will know that the object exists. It also looks to me compliant with the other features, such as the count, which does not count the objects to which the user doesn't have access. @dplewis @acinader thoughts?

@dplewis
Copy link
Member

dplewis commented Apr 6, 2020

@davimacedo I agree that this is expected behavior.

@codeKonami
Copy link
Author

I see what you mean. But if you have CLP that requiresAuthentication your approach would not allow to trigger the "authentication error".

@davimacedo
Copy link
Member

davimacedo commented Apr 8, 2020

I guess that's not true. If you check the code here, you will see it throws any error that not ParseError.OBJECT_NOT_FOUND. In the case there is no CLP, a 119 error should come from the server and it should be thrown to the client. If that's not the case that you are observing, do you mind to write a test case?

@davimacedo
Copy link
Member

@codeKonami thanks for the PR with the test case. I pulled your branch and played around. I could reproduce the problem, but only with the requiresAuthentication. I mean, if we set no CLP for get or even some role, it works properly, and error code 119 is received. The problem is on Parse Server, though.

Parse.Error.OBJECT_NOT_FOUND,
and
Parse.Error.OBJECT_NOT_FOUND,
look wrong for me. We should throw Parse.Error.OPERATION_FORBIDDEN, like in
throw new Parse.Error(

@dplewis agree?

@mtrezza
Copy link
Member

mtrezza commented Jul 28, 2022

I'll transfer this to Parse Server

@parse-github-assistant
Copy link

Thanks for opening this issue!

  • ❌ Please edit your post and use the provided template when creating a new issue. This helps everyone to understand your post better and asks for essential information to quicker review the issue.

@mtrezza mtrezza transferred this issue from parse-community/Parse-SDK-JS Jul 28, 2022
@parse-github-assistant
Copy link

Thanks for opening this issue!

  • ❌ Please edit your post and use the provided template when creating a new issue. This helps everyone to understand your post better and asks for essential information to quicker review the issue.

@mtrezza mtrezza added the type:bug Impaired feature or lacking behavior that is likely assumed label Jul 28, 2022
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

4 participants