meteor / meteor-feature-requests

A tracker for Meteor issues that are requests for new functionality, not bugs.
Other
89 stars 3 forks source link

Add additional details to the server-render sink object #174

Open lhz516 opened 7 years ago

lhz516 commented 7 years ago

@benjamn I like your work about server-render package, and there's something can be improved.

When doing SSR, we need login token to get current user. One way to achieve is to set login token to document.cookies when logging in. Then next time entering the page, cookie will be sent to server with request.

It would be great if server render sink object can provide cookies, something like this:

onPageLoad((sink) => {
    const loginToken = sink.cookies.meteor_login_token
    // more code ....
  });

There is some more discussion in this issue https://github.com/meteor/meteor/issues/8977

Maybe there can be more stuff in sink object, like request header, etc.

joncursi commented 7 years ago

Is it possible to also return the width of the browser making the request? In react, I am doing a lot of layout using the width of the viewport, but this is undefined on the server because Meteor can't determine what it is currently. Therefore, the markup being generated on the server is different than the markup being generated on the client because width is undefined on the server, but has some number value on the client.

joncursi commented 7 years ago

@abernix ^ would you happen to have any suggestions for me?

abernix commented 7 years ago

I don't have a suggestion for that situation, @joncursi. I'd try to avoid the need to have the width of the client viewport for actual markup generation, but instead rely on CSS to change the dynamics of the page at client render time. While the browser does identify itself with a user-agent (i.e. "I'm Chrome, Safari, etc."), it simply doesn't send viewport information to the server at the time of the initial HTTP request.

eric-burel commented 5 years ago

Hi,

I am trying to set up cookies + SSR, for an Apollo 2 app (the Vulcan.js framework). I rely on meteor/webapp and meteor/server-render.

I've setup universal-cookies-express middleware to parse the cookies and populate request.universalCookies. The field is correctly set (I've added another middlware to log the value).

However the field is not defined in the sink.request. I can access cookies so I definitely have a workaround, but it would be cleaner to rely on an Express middleware. I've tried with dummy middlewares that add a field to the request, but it does not work.

Logs tells me that the order is correct, the express middleware is called before the pageLoad callback, as expected. However I a guess that the sink.request object haven't been processed using the registered middleware. I don't know whether it's the expected behaviour or not Part of the server setup:

...
  // parse cookies and assign req.universalCookies object
  WebApp.connectHandlers.use(universalCookiesMiddleware())
// just to check that the field is correctly defined, it works
  WebApp.connectHandlers.use((req,res,next) => { console.log(req.universalCookies); next()}) 

  apolloServer.applyMiddleware({
    app: WebApp.connectHandlers,
    path: config.path
  });
...

and then the onPageLoad callback:

const renderPage = async sink => {
        const req = sink.request
        // will print undefined
        console.log(req.universalCookies)
...

Related to https://github.com/VulcanJS/Vulcan/issues/2081

CaptainN commented 5 years ago

Setting a cookie (instead of storing auth token in LocalStorage) is the most obvious way to do this, but can we use a Service Worker to add the extant token directly from LocalStorage to HTML requests instead? Could that provide greater protection against cookie hijacking and other similar attacks?

eugle commented 3 years ago

Can I get the hostname of the client in the sink