Cookies and keeping client side data

[peterw8102]

As you could probably tell I wasn't sure that Cookies would solve our link copying problem in a reliable way that would also protect use when we move the underlying comms transport to something like web streams.

I was thinking about this on the way home and I think using local storage on the browser would be a better solution.

This would allow the first page (the 'chat' page) to store some information on in the local store. I think this would be the end point ID. This could then be read by the AV pop-up window rather than passing it in the query string.

[njsfield]

Agreed! I think all three users browser's (Student, Moderator, Mentor) could store their endpoint ID's in local storage so that they can uniquely identify themselves when sending messages

If a student's endpoint ID had its permissions upgraded from text only to text and AV (to become moderator), the AV pop-up window would only need to concern itself with having unique JS to send messages back and forth to establish RTC, and would use its endpoint ID in local storage to name itself in the messages.

Would this implementation work?:

1. Privileged endpoint ID is stored in local storage for the student (now a moderator)
2. A new pop up window is opened, that navigates to a unique route (e.g. 'livepeers.com/stream')
3. The serves serves some html with a
4. The pop up window then fires messages (using its endpoint ID as the 'from' attribute) to establish RTC...
5. The server checks the endpoint ID to allow messages to be sent to the Mentor

etc etc

[peterw8102]

You'd store the session ID (might need a better name for that) in the local storage as well - that's also needed to send messages I think.

I think this is only needed when one page needs to pass control to another so student pages would not need to use local storage except when upgrading to moderator.

[njsfield]

Ah good shout!

Instead of storing the session ID and EP_ID in the Moderators browser, would it be better to store the Mentors EP_ID and Moderators EP_ID in the Moderators browser, to send messages in the 'from' and 'to' format? This would assume that the Mentor (person who originally sets up the session) has their own EP_ID stored on the server with all privileges

[peterw8102]

Probably. You still need to store the session ID. That's needed for all messages. EP_ID searches are always in the context of a session. Did the response to the "I want to upgrade to AV" include the Mentors EP_ID though? Might need that if not.

[njsfield]

Ah okay, so the session ID should always be referenced when users browsers send messages, in that case the data structure on the server could look something like this...?

sessions = [{
  SID: 23,
  endpoints: [{
    EP_ID: 1,
    Messages: [],
    permissions: 'Chat'
}, {
    EP_ID: 2,
    Messages: [],
    permissions: 'AV'
}]
}]

[peterw8102]

Your want session IDs and EP_IDs to be non predictable so it's more likely to be:

session = {
 a34dastg44: {
    sessionName='blah',
    endPoints: {
       'sdf88werwe': {messages:[], name:'Pete', permissions:{'chat':1}},
       '234rqadsf35': {messages:[], name:'Pete', permissions:{'av':1}},
       'asre2324e12': {messages:[], name:'Jen',permissions:{'chat':1}},
       '34rfw65sdfg': {messages:[], name:'Nick',permissions:{'chat'}},
   }
}

[njsfield]

Nice, thanks for your input Pete!

[njsfield]

Our data structure so far (for a mentor originally creating a session);

session = {
 'a34dastg44': {
    sessionName='blah',
    sessionPin='3456'
    endPoints: {
       'sdf88werwe': {
           messages:[],
           name:'Pete',
           permissions: ['chat','av'],
     }
}

[jsms90]

A bit of renaming:

• session = room, endpoints = users (because 'sdf88werwe' is considered the userId now, rather than endpointId)
• "roomPin" to "pin"? - is this more helpful or less helpful?
• "name" to "username"? to make sure its sufficiently distinct from "sessionName", when we're referring to stuff

(I know this is all just semantics, but it helps to be clear, since our team is connected remotely :+1: )

So:

room = {
 'a34dastg44': {
    roomName='blah',
    pin='3456'
    users: {
       'sdf88werwe': {
           messages:[],
           username:'Pete',
           permissions: ['chat','av'],
     }
}

[peterw8102]

Bear in mind though that each 'person' or computer will potentially be multiple 'users' - unless you've changed the model. The moderator would have two entries in the users table.