alright then I let you know after I test this
but the question is how can the postman handle the user cookies?
Been a while since I used Postman (since they implemented that whole cloud sync thing), but Iโve created Appwrite sessions direct with curl, and with other, similar tools. The /account/sessions/email endpoint will return Set-Cookie headers. You can just copy these into the request (I think Postman can handle the cookies automatically, too?)
I don't understand at all the context. JWT is generated server sided and sent client side to perform operations during 15 minutes. You can use it server sided to work as the user with the same permissions the user has rather than performing your own checks with a function for example.
If the main doubt is generating it server sided to use it server sided, then I don't understand what's the main use case for this ๐ค
JWTs (in Appwrite, at least) are generally generated on the client side, then passed to the server side.
In this post, JWTs are just the original assumption of a method to reach the desired outcome - which was to make calls to Appwrite (as a User) from Postman.
Okay, I understand now
Basically it's possible to do the cookies approach as you said, main advantage is that they will not need to be renewed every 15 min
thank you for explaining my desired outcome <:appwritepeepo:1156975874852270110>
Well, also, you can actually replicate whatโs really happening with your regular SDK requests (which I would expect is generally the point of creating requests in Postman)
[SOLVED] Auth login in server side
I'm double checking this. JWT generally needs to have some kind of authorisation from the server before being generated or being generated directly in the server ๐ค
Well, what makes something client side vs server side? In the case of Appwrite, it literally just means are you sending a cookie, an API key or a JWT as authorisation
Server side is harder to be manipulated
That's the main difference
Why? What makes the server API any different from the client API? Itโs really even the same API, just with different auth credentials!
Yes, I mean, server side SDK is basically limitless, it doesn't have rate limits since it's supposedly in a secure/controlled environment, meanwhile client side have rate limits to prevent abuse and needs authentication to access a specific resource meanwhile server side bypasses security checks with the API key scopes
Main issue on using client server sided is that it can hit rate limits since it will probably use the same IP address to perform the requests
But thereโs nothing stopping you from using a Server SDK client-side, or a Client SDK server-side
Yes, the IP rate limits might be an issue
Well, using server side on untrusted client I think it will not be a good idea
But yes, you can
Oh, absolutely - most of the time. Do remember that API keys can be scoped
But it will give you access to for example the entire database
But my point here was simply that yes, you can call all the REST APIs you like in Postman
Only if you give the key database.read permissions. And that may be absolutely fine, in some use cases.
Yes, depends on the use case
Recommended threads
- Cant get realtime working
Hey I nned some help with realtime a gain. I was using client.subscribe(...), and i found out that its depricated then i believe realtime.subscribe(...) is the ...
- Firebase app import
I'm **very** new to appwrite and I just set up appwrite with docker and I'm trying to import a Firebase app I have set up but it's erroring and I don't really k...
- Hi Folks, Database Writing Issue
Hey Folks im trying to get logging setup on my website but im getting an error, i dont have any document id and i think this is the issue but i havent got the f...