onReconnect currently sets x_mtok based on outdated session id

I’m having an issue:

• ostrio:files@1.14.2
• meteor@1.9.3
• client issue
• v1.9 docs but also v1.11 docs state verbatim:

wrong assumptions based on confounding server vs client code

Currently when a client reconnects to the server (such as after temporarily losing its Internet connection), it will get a new connection each time. The onConnection callbacks will be called again, and the new connection will have a new connection id.

In the future, when client reconnection is fully implemented, reconnecting from the client will reconnect to the same connection on the server: the onConnection callback won’t be called for that connection again, and the connection will still have the same connection id.

That future has not yet come. Though https://github.com/veliovgroup/Meteor-Files/blob/2035b63db313096388010d99a5ee4f56b04069f3/client.js#L120-L122 set’s the old session on the cookie: https://github.com/veliovgroup/Meteor-Files/blob/2035b63db313096388010d99a5ee4f56b04069f3/client.js#L111-L116

For reasons I don’t yet understand, the concrete application at hand seems to trigger a reconnect on each browser reload. So after the first browser reload all protected Meteor-Files (aka images) are gone (and kept loaded as blank in the corresponding page — even after navigating back and forth).

/cc @xet7

[dr-dimitru]

@blaggacao

[dr-dimitru]

On page reloads (F5), (image) assets that are served through meteor-files are fetched before the xmtok is renewed. As a direct consequence the request hits the server with the reference of an outdated (ceased to exist) session and hence authorization of protected files fail. A necesary precondition for this to unfold is that the session is cycled (on the server).

Yes, it’s architectural responsibility to make sure user properly logged in before showing the image or offering a download link.

Why does the server cycle session?

This is part of Meteor’s security measures

Why does the client not wait for the new xmtok to be established before sending any meteor-files related fetches?

I guess you fetch it over HTTP which is blind to auth-session and has no “wait” option. Again, since protected assets would require protected context and parts of UI, as well as extra-work on UI and UX. Why would you let unauthorized (yet) user to access protected pages?

---

For the rest of questions: I offer remote “pair” programming sessions explaining how things work and navigating you through solving tasks using Meteor/Node.js/JavaScript (3+ years of consulting and mentoring experience 😊)