User Reward System

Hey developers!

I hope you are doing great.

I am working on an AI powered app.
This app has user credit system.

One credit mean user can run an AI based task/query or chat for one time.

And users can get these credits using two methods

1. Watching a rewarded ad
2. Buying credits using Play/App store in app purchase functions

But I m stuck with its implementation
I don't want to hold this logic (that increments user credits) in client side.

How should I handle this in my server side.
Can Appwrite handle this?
And how?

And here is why I don't wanna handle this logic in cleint side

If someone manages to alter this request that is incrementing he easily can get unlimited points/credits..

Is there any safe side in appwrite to control this?

Can someone be able to login and manage their data outside(i.e postman or related services to call an api) app if they steal my project id, database id etc?

Kindly share your thoughts about the implementation of such a system using flutter and appwrite.

What can be the best way to manage this?

you are better off using a function side logic that uses server sdk to safely store a user's reward in a collection x document.

for Ads side reward, i think you will need to execute a function client side, maybe do some internal rate limiting to avoid fake and too many requests. although how to figure out if the user actually watched the ad fully is something you might need to think about.

for buying credits via play/apple store, you could validate the purchase from functions too, given the successful purchase returns some sort of token for validation.

these are just rough ideas and can be fine grained more.

You may be able to get a callback/webhook request from the ad network one an ad is watched by the user. Not sure whether this is supported by your ad network.

that is on device actually. client would still need to communicate with appwrite somehow

Nice idea

We can detect when a user has watched the full ad and got an award but still we have to invoke increment from client side that can be misused.

Also we can't rate limit this functionality because a user may need to watch ads at any time.

This is the main problem that is irritating me.

For ads we don't have webhook support.

i meant rate limit via functions. no need to increment via client side, as I said earlier, use server sdk in a function, so there's good security on who can increment a document. disable update access to everyone for that collection.

Still this function can be involved for misuse like if someone manges to get function ID he can invoke it as many times as he want.

And obviously this function will have api to update his credits.

If m not wrong in this concept.

1. use rate limit to allow a user only trigger a function xyz times in a period of time. keep a track of last execution etc. I agree that this is still prone to an attack. atm you might need to figure something out on that.

2. no, api keys in functions are pretty much secure when passed as an ENV Variables. you can always disable/delete the keys.