add guest users

[rizen]

We need to add a way that guests can join the chat, and then be converted to real users after the fact.

[rizen]

The more I think about it the more concerned I am with requiring server-side code for guest users. This is more of a random thought to see what you're feelings are than it is a direction. Does it bother you?

[perlDreamer]

If you mean assigning a tracer, even client side code can create a pseudo-user-id and set a cookie. If you don't mean assigning a tracer, you'll have to clue me in as to what you're talking about.

[rizen]

What I mean is that we are actually using Firebase auth for this. The user has to be authenticated. And my concern is just that it seems weird that we have to call back to the server for a visitor. Right now it's not going to be a big deal at all, other than that it's just weird. Later, if we productize this it will become a real problem.

[perlDreamer]

Can we even write security rules without using Firebase auth? Are you thinking we should go with Firebase Simple Login instead?

[rizen]

Yes we can write security rules without Firebase auth. And no, Simple Login is only useful if the user will be logged in via Facebook or Google or whatever.

Basically we just write security rule such that things guests have access to would not require auth. So anybody could post a message for example, which is essentially what we're doing anyway by allowing guest users.

[rizen]

I was wrong, you were right. There is an anonymous method for simple login: https://www.firebase.com/docs/web/guide/simple-login/anonymous.html

[perlDreamer]

Debug notes on Guest Users:

There's something odd going on in line 305 of chiselchat.js. If a user is not logged in to TGC, then this error pops up:

Uncaught Error: Firebase.child failed: First argument was an invalid path: "". Paths must be non-empty strings and can't contain ".", "#", "$", "[", or "]"

If you don't pass a userId or userName into chat.setUser, then you don't get the General Chat tab and you get the error above. If you pass a userId, but not a userName, then you get the General Chat tab, and you get the error message, too. Logged in or not, the id and chat_admin fields are both sent into Firebase::Auth to create the token.

line 305: self._firebase.root().child('.info/authenticated').on('value', function(snapshot)

Note that this does not touch userId, or userName. I need to watch the websocket traffic and see what's being sent back and forth to see if somehow it's pulling that information in anyway.

[perlDreamer]

The websocket traffic is pretty incomprehensible:

{"d":{"t":"a","d":null},"t":"c"}

Need a new plan for guest users, where they're assigned an id.

[perlDreamer]

If we use tracers as guestId's then the guest's rooms will persist for 5 years.

In order to transfer the room data from the guest to the normal user, the security rules need to be extended to allow someone with the right guestId to read the guest's list of rooms, and then adds the user to all the same rooms via authorizedUsers.

And, it can only do this once. This could be handled by deleting the guest user, or marking the guest user as converted, except that writing to other users is supposed to only work for moderators. The idea that you could assign yourself some ID and then delete any other user is not good. That can be mitigated a little bit by marking the user as a guest when it's created. That way only guest users could be deleted by someone persistent enough to do it.

[rizen]

I'm not sure why their rooms would persist for 5 years. Rooms only persist if there is someone actually in them. After that my offline program will clean them up.

One way we could get past the whole transferring room data thing would simply be to not allow guests to enter private and public rooms. They can only enter official rooms. No need to transfer data then because everyone is not only allowed in official rooms but they are automatically added to them.