Session id null issue in onCreated () function

help
1

I have created the below method

		getSessionId: function() {
			return this.connection.id;
		  }

which I call inside the client js within the template onCreated function

Template.experiment.onCreated(function () { 
....
  Meteor.call("getSessionId", function(err, id) {
    if (err){
      console.log(err)
    }
    else {
      Session.set('sessionId',id)
      return console.log('SessionId',id);

    }
  });
})

I get the id most of the times, I notice though sometimes that it gets null, where is the right place to call that method so that to ensure that it is always filled in and not null?
Is it in Meteor.startup function? So I need to rewrite the method call like below:

Meteor.startup(function() {
  Meteor.call("getSessionId", function(err, id) {
    if (err){
      console.log(err)
    }
    else {
      Session.set('sessionId',id)
      return console.log('SessionId',id);

    }
  });
});
2

You could try reading the sessionId off the Connection module on the client with this:

Meteor.connection._lastSessionId
3

Hi,
it seems that with that

Meteor.startup(function() {
  Meteor.call("getSessionId", function(err, id) {
    if (err){
      console.log(err)
    }
    else {
      Session.set('sessionId',id)
      return console.log('SessionId',id);

    }
  });
});

I now get Session id always.
From what I have read and you also propose though I can understand that it is not the right way to do it or there is another easier way to get it since I only need it in client and could avoid calling it from a server method so I tried your recommendation inside
Meteor.startup(function()
or
Template.experiment.onCreated(function () {

but with no result I get null again, I suppose I am wrong at the place where I call it, right?Where is the right place to call
Meteor.connection._lastSessionId
?

4

If it’s returning null, it means it hasn’t finished connecting to the server by DDP and establishing a session.

The Method approach should work because the method can only run when the session is established (Which confused me that it was working intermittently for you, but sounds like you sorted that out)

If you really want a client only solution you will need a reactive data source that can track the connection status:

Tracker.autorun(function () {
  const status = Meteor.status();
  if (status.connected) {
    Session.set('sessionId',Meteor.connection._lastSessionId)
    console.log('SessionId',Meteor.connection._lastSessionId);
  }
});

This also has the advantage that if your connection gets reset and you end up with a new SessionID, it will update the Session variable

But the method version is also perfectly fine. There’s not much overhead in a small DDP request like that

1 Like
5

thank you for the response.
I don’t know why but I copied this inside my file I also included the line for “status connected” to check whether the code reaches that point, I get that line in console, but the SessionId still is null…

Tracker.autorun(function () {
  const status = Meteor.status();
  if (status.connected) {
    console.log('status connected')
    console.log('SessionId',Meteor.connection._lastSessionId);

    Session.set('SessionId',Meteor.connection._lastSessionId)
    console.log('SessionId',Meteor.connection._lastSessionId);
  }
});

anyway I have the workaround with the call of method but was just wondering of the right way.

6

I don’t think there is a “right way” to do this, since it’s not common that you need to store session IDs on the client and they’re not stable between connections (including after a network interruption).

My suggestion was based on the thought that if the client does know about the session ID, you can save a round-trip to the server to fetch it.

Having a look through the Meteor source, here’s the only place where _lastSessionId is set.
I couldn’t find anywhere else that the session ID is stored on the client, so that’s it.

Digging deeper, the Meteor.status() reactively updates here, which is immediately after the websocket is established, and before the DDP messages establishing a session are exchanged, which explains why _lastSessionId is null at that spot.

It doesn’t look like there’s any reactive source that fires when the session is established, so the method approach is the most correct

1 Like