Initially when a route loads from a browser refresh I see _lastSessionID as null. (instead of a new one you see on the next navigation).
How can I see the current session of a freshly refreshed page’s session?
I would also like to know what it (the client’s sessionID) is from the server side (to validate it).
null seems wrong except for this confusing wording (aka notion) of “_last*”?
It can be logged in at that time but no session ID?
Session is reactive global variable.
In meteor we have connection.
And it is mentioned in documentation.
For know I’ve had to use the userId as a temporary and switch my internal server side storage of info. when a sessionId is available and there is already a valid userId also stored.
Okay, so every Meteor.call has to pass both a sessionId and the userId, with this solution.
Obviously not ideal, so I’m still interested in how that’s done properly, or it being made available and not null.
I’m calling it a bug. Could be a feature.
Otherwise there should be a _nextSessionId right?
Yes I’m aware of that. It’s what I’m talking about.
Meteor.connection._lastSessionId Client only unless passed (not trustworthy) through Meteor.call
I still dont know for what you would need that sessionId.
But u never has to pass userId from client, you can get it in server side secure way.
Right good point on the userId in server side, thanks for the reminder.
My use-case is odd, and better as another thread I will start maybe later about packages and loading files only when needed (admin user control panel or in a modular role styled app). calling api.use from the server after deployment during runtime (it’s really only a package building call) would be nice and then it could also hot-reload etc.
Still a session should have an ID and not be null at anytime in my thinking.
well, there are some packages which provide anonymous accounts, so in that case you will always have kinda connection ID.
really? which ones? what does that look like? Meteor.connection._id or something?
Thanks for the link. I am testing logged in already and that holds or initializes in time fine, (maybe it’s in “Session”).
It’s funny because if I console log Meteor.connection and Meteor.connection._lastSessionId
I see null logged for the id but I guess after the call it’s already updated in the Chrome when you see it (as if it’s posted before the null but it’s interactive after the fact).
It’s currently triggered in an autorun via Meteor.call. Maybe if I move that to the Accounts.onLogin or something it may be different result (not missing). Still it seems like a bug to me.
_lastSessionId it’s alway been mis-named imho, as this is the current id for the session (it’s only the ‘last’ session after a hotload iirc)
However, right at the startup is there is no session, and you’re still waiting for the client to establish a connection.
Here, Meteor.status() is your friend. It is a reactive data source and when the status changes from ‘connecting’ to ‘connected’ the _lastSessionId is assigned
here’s a little test…
Meteor.startup(function () {
var cnt = 0;
var pulse = 10; // some milliseconds for testing
// every pulse lets see what the new session is up to - connecting
var interval = Meteor.setInterval(function () {
cnt++;
console.log(cnt,Meteor.default_connection._lastSessionId,Meteor.status())
},pulse)
Tracker.autorun(function () {
// lets watch Meteor.status().connected becoming true
if (Meteor.status().connected) {
// clear the interval
Meteor.clearInterval(interval);
// there will still be a few milliseconds while the connection process completes
// so use anothet interval
var readyInterval = Meteor.setTimeout(function () {
if (Meteor.default_connection._lastSessionId) {
Meteor.clearInterval(readyInterval);
console.log('session ready', Meteor.default_connection._lastSessionId);
}
},pulse)
}
})
})
it returns to console, something like…
1 null Object {status: “connecting”, connected: false, retryCount: 0}
2 null Object {status: “connecting”, connected: false, retryCount: 0}
session ready nAPhCTKusCrrjRnab
It’s totally awesome! I’ve been watching it evolve.
Great way to look at the problem, which I fear might be a Synchronous one. Any thoughts on that?
it’s definately async - you’re waiting for the client DDP connect sequence to initialise and complete.
The very state I hoped foolishly it would be available by (magically=impossible), as that’s where the problem presented itself. I’m sure I can delay something somewhere.
It’s only a few millisconds before it becomes available - a few cpus cycles at either end + network latency
It seems after trying the terrific status check idea it is waiting for that request to end before it assigns it the session id. So in this context it was not possible. Various alternative always exist. Like the userId place holder.
I no longer think it’s a bug, since it can’t be assigned to the client yet even though they are auto logged in from the previous Session.
Could you be a bit clearer about your use case. I’m not quite certain what your context is.
The other project looks interesting I didn’t dig too deeply there yet though.
Anyway in the end I’ve recognized that I should just use the server side this.userId and store in it the session id (when available) and act when that changes from anything other then null it’s a new session and store that one. [Otherwise one gets an extra mess of Session ideas stored without easier garbage collection.]
The context is challenging in many ways as it’s from inside a package. In general the admin user activates the plugin when they trigger an admin login, then hidden files load (to save on preloading & resources as it’s not needed for all but 1 or 2 admin users), but I don’t want to reload the file unless they are refreshing the session (or a watchFile says otherwise). So unfortunately simply browser refreshing triggers all that before the session id exists. It would have been the logical choice but apparently not.
I mentioned that when I hinted earlier that it was too bad you can’t just dynamically call api.useFiles from a Meteor method triggered onLogon and/or a route change etc., which I might elaborate more clearly on later in a separate post, but I recognize that is a build file only feature and likely never going to be available. Anyway I have this “hoop-juggling” experiment working now, so moving on.
Thanks for everybody’s help exploring this.