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

authData.anonymous === null strikes again #2321

Closed
yuzeh opened this issue Jul 19, 2016 · 4 comments
Closed

authData.anonymous === null strikes again #2321

yuzeh opened this issue Jul 19, 2016 · 4 comments
Labels
type:bug Impaired feature or lacking behavior that is likely assumed

Comments

@yuzeh
Copy link
Contributor

yuzeh commented Jul 19, 2016

We've been having issues with null authData values since migrating our customers to our own parse-server.

Things that we thought would have fixed the issue:

There may be a couple more but I'm beginning to realize that the core of this issue is that we're allowing null authData values to be written to the database.

That, along with the fact that there's no filtering on the query side, leads to clients getting null values in user.authData.

(Probably Android should deal with this, because it doesn't seem like a big deal in iOS-land, but that's the topic of another discussion?)

In any case, #2320 should fix this (partially) by not letting the nulls leak out of the parse-server. We may want to stop writing nulls as well.

@flovilmart
Copy link
Contributor

 we're allowing null authData values to be written to the database.

Why don't we don't allow that?

@yuzeh
Copy link
Contributor Author

yuzeh commented Jul 19, 2016

Why don't we don't allow that?

If your question is asking about the current state of affairs, I think the current protocol (or at least the Android implementation of it) is part of it: https://github.com/ParsePlatform/Parse-SDK-Android/blob/7d908f3d1cbed3c89addfac49419c6c2f1859d62/Parse/src/main/java/com/parse/ParseUser.java#L432

If your question is a suggestion, I totally agree!

@hramos
Copy link
Contributor

hramos commented Sep 6, 2016

@yuzeh should we close this now that #2320 was merged in?

@hramos hramos added the type:bug Impaired feature or lacking behavior that is likely assumed label Sep 6, 2016
@yuzeh
Copy link
Contributor Author

yuzeh commented Sep 6, 2016

That's fine with me.

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