SSRing sites that make requests to external domains where cookies are needed

Starting here @web-mech brings up a use case where SSR didn’t work.

Essentially, his app made requests to firebase. This requests won’t have the right cookie/auth privileges.

This issue is to discuss possible solutions, work arounds, or warnings we could add to make this situation better.

A few ideas off the top of my head:

Allow some type of mapping from cookie to domain to cookie.

I don’t think would really work practically, but perhaps if we had something like:

{
  "ABC": { "firebase.com": "DEF"}
}

We would be able to know session “ABC” should use “DEF” cookie if any requests get made to firebase.

I don’t think this is practical or really possible. A browser won’t send its cookies for firebase to a different server. I’d have to learn more about firebase’s auth strategy to know if there’s any other work around.

Zone.ignore

We should be able to ignore this piece of code. @matthewp what does that look like?

Warning if XHR to other domains

If the XHR request being made doesn’t match the origin of the SSR request, we should let people know that the XHR request might not be made with the right cookies.

[marshallswain]

@matthewp and I also enabled the auth configuration as CLI params, so @web-mech should be able to enable authenticated SSR by adding the --auth-cookie and --auth-domains flags to the develop script in the package.json of a DoneJS app. The done-serve module will probably have to be updated for it to work.

[marshallswain]

The auth config setting of done-ssr is a step in this direction will already allow this. It currently only works with JWTs in Authorization headers, but I think it could be lightly tweaked to work with session ids placed into new cookies. It basically works like this:

❶ The client authenticates directly with the API server, which is Firebase in this case. ❷ The API server responds with a token or a cookie. If it’s a cookie, it can’t be an http-only cookie. It has to be readable by the client. ❸ The client reads the contents of that cookie and creates a cookie named firebase-jwt for the SSR server’s domain. ❹ Upon refresh or page load, the cookie gets sent to the SSR server. ❺ The SSR server copies the auth data from the firebase-jwt cookie into requests destined for the API server. The destination is specified in DoneSSR’s auth config, which needs both a cookie name and a domains array. (Since the current version was setup for JWT auth on the Authorization header of requests, we couldn’t take advantage of cookies automatically going out on requests to specific domains) This is the part that could be tweaked so that the server just adds a cookie on the fly. The current version is also limited to a single API server only due to the auth config syntax. ❻ The API server, having received an authenticated request, responds with data. ❼ The SSR server assembles the page with the authenticated data and sends it to the client.

This whole process is already working for any server that allows auth using the Authorization header. Feathers does this, and I believe Firebase does, too, so this should already work for Firebase, but not for cookie/session based API servers.