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
- Type Mismatch in AppwriteException
There is a discrepancy in the TypeScript type definitions for AppwriteException. The response property is defined as a string in the type definitions, but in pr...
- What Query's are valid for GetDocument?
Documentation shows that Queries are valid here, but doesn't explain which queries are valid. At first I presumed this to be a bug, but before creating a githu...
- Appwrite exception: user_unauthorized, t...
After refreshing the app it is working perfectly