How to write in Other User that is not the current user ?

42 views
Skip to first unread message

Maravilho Singa

unread,
May 12, 2017, 8:13:40 PM5/12/17
to back{4}app
How can I increment numbers to Other User that is not current user ?
I want to build an App like Paypal, But i'm having problem when i want to Increment values to other User

final ParseQuery<User> SendQuery = User.getUserQuery();
SendQuery.getInBackground("ObjectID",
new GetCallback<User>() {
@Override
public void done(User user, ParseException e) {


if (user != null){



mCurrentUser = (User)User.getCurrentUser();

transactions = new TransactionsClass();


transactions.setColSender((User) ParseUser.getCurrentUser());
transactions.setColReceiver(user);

// Get Money from Current Account (- 100.00)
mCurrentUser.increment("balance", -10.00);

// Determinate Money to send ( 100.00)
transactions.setColAmountSend(10.00);

// Determinate who paid Who paid fees
transactions.setColWhoPaidFees(user);

// Get fees from current sender
transactions.setColFeeExpress(1.00);
transactions.setColFeeBaxpay(1.00);


// Determinate amount received to other user
transactions.setColAmountReceived(8.00);

// Send Money to Destination account (ObjectID account) +10.00

THE PROBLEM IS HERE, WHEN IF I COMMENT THIS LINE EVERYTHING WORKS FINE. How can I increment numbers to Other User that is not current user ?
user.increment(User.COL_BALANCE, 10.00);


transactions.setColTransStatus("sent");

// transactions.setColDescription(mNote.getText().toString());

transactions.saveInBackground(new SaveCallback() {
@Override
public void done(ParseException e) {
if (e == null) {

// Money Send with success

/*ParseQuery<User> FeesQuery = User.getUserQuery();
FeesQuery.getInBackground("hfjkjdjk", new GetCallback<User>() {
@Override
public void done(User BaxPay, ParseException e) {

if (BaxPay != null){

// Fees Send with success

BaxPay.increment("balance", 100.00);

} else {

// Fees not sent with especial error.
}
}
});*/


} else {

// Money not send with especial error.

}
}
});


}
else {

// Money not send with especial error.
}
}
});

casag...@back4app.com

unread,
May 15, 2017, 8:11:58 AM5/15/17
to back{4}app
Hello!

You'll need to setup the ACL in order to be able to edit other users than the current one. 

Please take a look on the documentation: http://docs.parseplatform.org/android/guide/#users

Best!

Alexis L.

unread,
May 16, 2017, 3:06:30 AM5/16/17
to back{4}app
In my view, that's a very bad idea to allow changes of another user's profile, from an otherwise different user, and to do that on the terminal side. With MBaaS like parse, security is entirely determined by your ACL, which means that if your ACL allow this, anyone will be allowed to do that. This is especially dangerous, since there's really no way to practically secure your API keys, especially for Android.


Best is to do the following:
- Implement a cloud function to make the changes, using the master key & the necessary data sanitisation.
- Refetch the user's data whose properties you just modified.
- Notify the other user that his profile has changed (using APNS or GG push service) so his profile is fetched afresh.

Maravilho Singa

unread,
May 18, 2017, 10:48:23 AM5/18/17
to back{4}app
Thanks you for quick responses.

I processed with the following way.

1. The User class, wasn't touched, the preserve the default ACL

2. The number that i nedded tô increment in User class, I created a new class "Accounts" with pointers to User (Sender and Receiver) and balance to be incremental.

It's now working exactly the way I wanted.

So, Since the Accounts Class, is writeble, how can i proceed to ensure segurity ?

I have an ideia to:

1. Disable client class creation (In production)
2. Send push using master key 🔑 with cloud code

What else can i do ?

casag...@back4app.com

unread,
May 18, 2017, 10:52:36 AM5/18/17
to back{4}app
Hello Maravilho,

Glad to know it worked as you needed.

Also, I couldn't understand why disabling client class creation would improve your security in that Account Class that can edit the user Class.

Plus, to send pushes you will need the Master Key anyway, so on that point you don't need to be worry.

Best!

Alexis L.

unread,
May 19, 2017, 7:55:53 AM5/19/17
to back{4}app

The _User class is the wrong place to implement this kind of stuff anyway, because it has to be readable by everyone.  Therefore, you expose everyone's data, including emails & phone numbers. Apparently, you're using Android which seems easy to decompile. Once an attacker gets his hands on the API Keys, he can then fetch all of your users data.

Interestingly, an attacker can also use those keys to increment his own wallet. What's your app name ? :)

More seriously, you're doing it all wrong.

The only safe way to do this sort of thing is in cloud code, on a class with global ACL-write = MasterKey only, user readable = owner only, adequate data sanitisation, and most of all, signed transaction receipts (and obviously, stored somewhere else)

Anything below that, you're heading towards very serious legal and financial troubles.

casag...@back4app.com

unread,
May 24, 2017, 2:41:24 PM5/24/17
to back{4}app
Hello guys,

Maravilho, it would be more secure to use the Master Key only in Cloud Functions, altering User related information and, as our friend Alexis stated, update those data changes to the User Class. That will make sure that the only way possible to edit the User data is through the cloud function and not through another unprotected Class. That should fit your idea of project as well.

Alexis, thanks for your contribution. I'd suggest though a lesser harsh approach to your fellow developers. :)

Best! 

Alexis L.

unread,
May 25, 2017, 2:17:13 AM5/25/17
to back{4}app

@b4a Admittedly, you do have a point, I wasn't answering with the necessary professionalism.  

Maravilho, apologies if this can help.

The technical comments do stand however. In a nutshell, assume your API keys will be disclosed on a 4chan thread, therefore, make sure your ACLs are adequate (at a minimum this means when money is involved, what isn't absolutely necessary ought to be disabled).

Other than that, from a design perspective, Google Play in-app billing recommendations apply to your own code https://developer.android.com/google/play/billing/billing_best_practices.html for both the architecture, and tips and tricks (code obfuscation, server side receipt validation etc...).

If you are not ready to implement such architecture, I would recommend you to use in-app billing instead, and come back to it if/when your app is successful enough to warrant custom development. In the mean time, google will take a cut, but that's the price to pay for basic security (and I really mean *basic*).

cheers.
Reply all
Reply to author
Forward
0 new messages