Admin
no to both questions?
Votes
0
Replies
24
Participants
Unknown
Messages
25
Admin
no to both questions?
Rank 1: Thread
I'm using appwrite, but not for OAuth
Rank 1: Thread
Just for the db
Admin
without using Appwrite's authentication, you won't be able to make use of permissions so....
Admin
well you might be able to but it would be really hard and hacky 🤷🏼♂️
Rank 1: Thread
How about not using permissions?
Admin
then you wouldn't be able to lock down the data
Rank 1: Thread
Well, the reason behind me not using Appwrite's auth is the way it provides Google auth isn't very ux friendly
Admin
How so?
Rank 1: Thread
I'm talking about Android app, and it redirects the user to browser for a simple sign in...
Admin
I see versus "native".
Anyways...what you're asking for is like me logging into my Gmail but then wanting to access my banking info securely..without logging into it
Admin
You might be able to implement some workaround....but you might need to do all the permission handling yourself manually somehow. So maybe a function or maybe an API later between your app and Appwrite
Rank 1: Thread
I get it... Can I have some insights on the permission thing which I need to take care of while creating an API... Like how exactly the permission is useful if I'm just trying to do the operations with the logged in USER ID... What are the scenarios where it can go wrong..
Rank 1: Thread
The dataflow in my mind is
User logged in (I got the user id) > the app request for every operation with the user id > API will only do operations on the documents with that user id ..
Admin
what can go wrong is if the permissions are wrong then someone can have access they shouldn't. And if you're not using auth, somone might be able to "hack" in and look at someone else's data
Admin
so if i find out someone's user id i can fetch they're data and do thing as them
Rank 1: Thread
That's one thing to think about... Any workaround for it except making it hard for anyone to know even their own user ID...?
Rank 1: Thread
🥹I hope I'm not irritating you with my stupid questions, apologies if I'm already doing so...
Admin
if you're planning on using it in the request, you can't hide it. anything used client side should be considered public
Admin
no worries! happy to help!
Rank 1: Thread
How about encoding the user id by the API and then using the encoded ID for the db document?
Rank 1: Thread
So even if the anyone knows the user id, they'll not be able to mess up the data
Admin
How is the client going to get the encoded ID?
What if someone finds out the user's encoded ID especially when it's sent with every request
Rank 1: Thread
The encoding will be done by the API when communicating with the db... And it'll be just the normal user id on the client side.. so even if anyone knows the user id, they can't communicate directly with the db and if they'll try to communicate with the app's own API with the general user ID, a check will already be there to verify if the request is coming from my own app or not...
The problem is, as I've already mentioned in my first message, I'm not much aware of how to verify the requests are legitimately coming from my app or not..
Admin
As far as I know, the only thing available right now for trying to verify where a request came from is using Google's integrity API (https://developer.android.com/google/play/integrity) or Apple's app attest (https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server)