@aj, cookies are handled transparently by react-native, i.e. they are stored in a per-app cookie jar

they persist across app restarts, so as long as you use the regular JavaScript network request libs (js/fetch), you don't need to do anything

@pesterhazy by any chance do you have an example?

@carocad of using fetch?

no, I already use fetch. In my case I call fetch on app start to get the tokens. Since that process always takes a while my guest was that nothing was being persisted. But you said that they are persisted transparently so if I call fetch with the same address as before, does it uses the known answer? i am a bit confuse sorry

it works just like on the web - RN acts like a web browser

> In my case I call fetch on app start to get the tokens I'm not sure if I got your authentication scenario right, but… If you get auth tokens back in the server response, then you have to manually save them (for example with AsyncStorage) on the devise and manually add them as headers to sub-sequent fetch calls. What @pesterhazy is talking about with automatic save is just cookies and will work if you have cookie-based authentication (not token-based).

ah you mean a token as in JWT?

yes exactly

@wojciech thanks a lot. That solved my confusion

yeah you'll have to set headers and store tokens manually then

(What's wrong with cookies? Why do people keep reinventing them?)

> What's wrong with cookies? Why do people keep reinventing them? I keep asking myself that… No idea 😞

@pesterhazy well in the case of jwt they are self-signed. So there is no need to store the token safely. Any storage will work since the server can verify it. They are also stateless so no need to keep track of current sessions on both client and servers

can't you do that with cookie too? E.g. ring.middleware.session.cookie/cookie-store https://github.com/ring-clojure/ring/wiki/Sessions#session-stores