Storing all connections/sessions in a db - too crazy idea?

1

I am building a functionality similar to leesangwon:connections package to be able to monitor all the connected visitors or users to the website/app.

In the connections package @leesangwon firstly adds a connection to the db but then deletes it from it… I thought about storing it there either forever or for a specific amount of time (to be able to solve any account related issues, if there are any).

The questions are:

  1. How big the db will be eventually, if, say, during the day a user can have up to 100-150 connections… (as every browser reload or opening a new tab is technically a ‘connection’)? Won’t it be ‘unreasonably big’ eventually?
  2. Is it a ‘normal’ practice from legal point of view? Isn’t it considered a spying on users?

Asking here just in case you might ever faced such issues…

2

I think most people store data like that in the database basically forever, since storage is cheap these days. I don’t think there’s any legal issue about it. In fact many apps use a deleted: true flag instead of actually deleting objects, just to make sure something old that relies on the data being there doesn’t break in weird ways.

3

thanks, will proceed so then…

4

Yes we store all audit data and haven’t seen any issues. You can also send this data to another server for processing, or call this.unblock, or Meteor.defer() etc to make sure it goes into the background for processing. We also store all change/interaction events with hooks etc.

1 Like
5

So far I am amazed by DDP - all works as intended, real-time data of list of all connections, turn-off iphone - see connection closed immediately… magic! :slight_smile: (as perceived by the guy from PHP world… ;-))

One related question though - how reliable are all connection-related meteor functions? I assume that under certain circumstances the onClose function might not fire, right? At least for example if something happens with the server, there might be some fake-active connections (that I am creating during connection start) left in the database, right?

I just wanted to set up a sort of batch process to clean all such ‘fake-active’ connection records…

6

Cleaning these ‘fake-active’ connections records at the server startup… but what about DDP in general? Can there be any other issues prevent onClose function to not actually fire?

8

So found an issue with onReconnect function which I wanted to use: https://github.com/meteor/meteor/issues/5665
still open…

9

One can overcome the issue with observing changes in Meteor.status()

// on client
Meteor.autorun(function(){
  if (Meteor.status().connected) {
    console.log('test');
  }
});

this will always trigger on every reconnect