Open lhz516 opened 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.
@abernix ^ would you happen to have any suggestions for me?
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.
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)
...
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?
Can I get the hostname of the client in the sink
@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: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.