dcki / web_socket_tennis Goto Github PK

For some reason if I have the app open in one or two web browser windows (with one incognito, so separate sessions) and I reset the database and start up sidekiq and rails server, and refresh the app in the browser, I'll often get a game created with user id 1 sent to perform, but somehow User with id 1 has been deleted, and when I refresh that user's window it asks me to log in again. Then I seem to need to get rid of that old game to get things working, which I do with redis-cli flushall (but if needed would use a more targeted method).

The app treats all sessions as valid. There is no mechanism to expire a session (that does not depend on client-side cooperation or regenerating the Rails app secret.)

If this becomes an issue for any practical purpose, then it is time to implement real authentication (Devise or OmniAuth, maybe also Pundit).

Given user A is logged in
When the database is wiped
And user B creates a new account
Then user A may be able to access user B's account

Instead, user A should be redirected to the new account page.

Technical explanation:

Given user A is logged in with a cookies.encrypted[:user_id] of 1
When the users table is truncated
And the Rails secret_key_base is not regenerated
And user B creates an account with a users.id of 1
And user A visits the game page
Then user A will be able to make requests and ActionCable requests as user B because a cookies.encrypted[:user_id] of 1 grants access to the User with id 1.

Errors with not being able to find GameChannel subscription for paddle action, and not being able to find Game with id 1 (or 2 or whatever) in sidekiq worker.

The way users log in and create accounts does not allow them to prove, as a human, at a later date, that they control the account. This could become an issue if, for example, a score board system is later introduced, and a human wants to prove they were the one playing the game when they got a very high score.

If their game account were associated with their email address or at least a password that they know, then that would be convincing evidence they own the account and got the high score. But the user model doesn't record that information now. Instead, a user controls a User record until their session is lost, at which point they must create a new User record (which can have the same name attribute as the old one) and can never log in as the old User again.

This could be fixed with Devise or Omniauth, for example.