Use Cookies instead of LocalStorage for JWT token store.

[chpapa]

Reported by Clients, to make isomorphic JS app, it needs to be in Cookies. (Plus briefly search online, it seems Cookies is the recommend way?)

Either we make cookies default (if it make sense) or have an options to use Cookies?

• Skygear SDK Date/Version: v1.1
• JS runtime:
• Skygear Server Date/Version: v1.1
• Is this a regression?
• Attached logs, screenshots

[malyon]

I wouldn't mind taking a look into this.

[chpapa]

@malyon cool, let me or @rickmak know if you run into any trouble or need some help

[cheungpat]

reference: https://github.com/zeit/next.js/

[cheungpat]

So we are considering this use case for server side rendering which requires cookie to pass user session state:

• The client fetches a page from a nodejs process. The HTTP request contains a previously nodejs-supplied cookie.
• The nodejs process use the cookie to obtain client user session state, the nodejs process then calls skygear api to obtain skydb data.
• The nodejs process use the skydb data to render the page (aka server-side rendering), the nodejs generates/forwards user session state in the form of a cookie.

It has yet to know:

• whether the cookie is generated from the skygear server or from the nodejs process
• whether the nodejs process is part of skygear handler plugin

[IniZio]

• In SSR the server needs to grab data from skygear db to prerender the page, so the token generated from skygear is needed. Currrently it is stored in session storage or cookie if session is unsupported.

The login process is still done in client, so the cookie is actually produced in client and then sent to server. This should be done by developers who are using skygear, since different SSR frameworks have different flags to distinguish server-side and client-side.

Problem is that skygear does not allow passing in token as parameter from server due to its current auth implementation.

• the nodejs process is the SSR framework, so I do not think it is related to skygear handler

[rickmak]

whether the cookie is generated from the skygear server or from the nodejs process

The cookie should be set by skygear-server.

Problem is that skygear does not allow passing in token as parameter from server due to its current auth implementation.

We plan to make skygear set the cookie properly, all user request will have the skygear auth token in cookie. Including request to skygear-server or node-SSR server. In the way, it will solved @IniZio problem, right?

whether the nodejs process is part of skygear handler plugin

The framework should affect more than the runtime. Let me providing some info on how react works.

One approach used by https://github.com/nfl/react-helmet . The developer will required to call renderStatic after ReactDOMServer.renderToString.
related discussion: nfl/react-helmet#216
This approach is not thread-safe and not working with streamed SSR. But it requires no change in the client side code.

For supporting SSR stream, we may refer how https://github.com/tizmagik/react-head do. But this is probably another approach and may require users to change how they currently use skygear within react component.

We may want to take a look on vue and angular too.

[chpapa]

@rickmak @cheungpat @carmenlau I was told firebase use both cookies and localstorage a hybrid approach. Maybe worth checkout to see how it was done too.

[louischan-oursky]

Skygear server should support rotating session. For example, if the skygear server is configured with AUTH_COOKIE_MAX_AGE=86400, then every response (including non-auth related) must have the HTTP header Set-Cookie: a=b; Max-Age=86400 set.

Alternatively if the skygear server is configured with AUTH_COOKIE_EXPIRES=, then the header will be Set-Cookie: a=b;, meaning that the cookie is a session cookie.

The default value of AUTH_COOKIE_EXPIRES should be the same as the token store's.