feat(core): support server set cookies

[MathiasCiarlo]

This fixes the issue that arises when trying to access a protected path directly(the first request to the website). The middleware tries to save the attempted, protected path to storage, so that we can redirect to the path after login. The problem was that the "auth.redirect" cookie was not set when the middleware was run server side. This PR supports cookies set server side and should fix #332, fixes #326 and fixes #134.

[karimcambridge]

I also encountered this issue!

[mhafizhasan]

+1 should be fixed

[smesterheide]

This is an elegant solution to the problem I am having with users getting logged out because the token has changed server side but is not synced with the client.

[smesterheide]

I have found some potential problems with this PR:

1. getCookie(setCookie()) is not working as expected
   Breaks the Storage class contract
2. setCookie(A) && setCookie(B) overwrites A
   Can be fixed by more careful handling of Set-Cookie headers
3. Cookie options are ignored

I need to pass several cookies back to the client, so I am thinking of setting them in nuxtServerInit instead.

[MathiasCiarlo]

I have found some potential problems with this PR:

1. getCookie(setCookie()) is not working as expected
   Breaks the Storage class contract
2. setCookie(A) && setCookie(B) overwrites A
   Can be fixed by more careful handling of Set-Cookie headers
3. Cookie options are ignored

I need to pass several cookies back to the client, so I am thinking of setting them in nuxtServerInit instead.

@sambrezo Thank you for the feedback! I have fixed the overwrite issue, and added options. What do you mean by with getCookie(setCookie()) ? The setCookie function still returns the set value?

[smesterheide]

Hey @MathiasCiarlo,
that's looking good. I'm gonna test it with the rest of my app this week and let you know if it works for me. Thanks for tackeling the cookie issue!

Regarding 1) I think the issue might still persist. The problem that I see is when you call setCookie while SSR and then read the value again with getCookie you will get the cookie information from the request header and not what you have just written to the response header. Might be an edge case but all other getters of the Storage class provide some kind of persistence which is not guaranteed when he have to deal with two sets of cookies. No 3) is somewhat related in that the cookies should stay in sync when moving server to client and vice-versa. Unfortunately the cookie.options in auth-moduledo not always map onto the values we see in the cookie string. For example expires is used differently in js-cookie.
We also have to keep in mind that we cannot use HTTP enabled cookies cookies server-side because we rely on the client being able to read and write to the cookie via js-cookie. This means we cannot really protect our tokens from XSS when we move forward with this approach.

Would be nice to have one of the other contributors comment on the decision whether to support server cookies at all.

[duyleekun]

I patch-package this to use this fix immediately. Hope this get merged soon

[MathiasCiarlo]

I've added support for unsetting ssr cookies. The only thing remaining is to think about cookie options (link to docs). In an earlier commit, I did a simple implementation, but @sambrezo told me the options used in js-cookie are a little different than my implementation. Do we have to include options ssr, and if so, please help me out in how we can serialize js-cookie options with the current implementation :)

[pi0]

Hi @MathiasCiarlo. I've proposed #360 to backport universal-storage improved storage into auth module. Would you please have a review on it?

I think the difference with this PR is that here we support multiple Set-Header calls. If you think it is a requirement we can combine these PRs and use getCookiesFromResponseHeader/setResponseHeaderCookies utils.

[MathiasCiarlo]

Great @pi0, I'll have a look tonight :)

[MathiasCiarlo]

@pi0 Have looked at your PR. Many nice changes, but we definitely need the multiple Set-Header calls. How can we combine the PRs? Can I raise a new PR, branched out from your branch? :)

[pi0]

Thanks, everyone for patientnce and helping on this issue. Sever set cookie is added in v4.6.0 via #360.