Carl Worth [Thu, 21 May 2020 16:13:11 +0000 (09:13 -0700)]
Add a simple /stats endpoint to get a count of current games in progress
This view is particularly spartan so far, (just two lines of next, not
even HTML).
Most of the work in this commit is actually setting up the
authentication mechanism, since /stats is the first page we have that
requires a user to be authenticated (and to also have the "admin"
role).
We have a nice-looking "/login" page with proper styling and clean
messages for login failure. If an unauthenticated user goes to /stats
they will be sent to /login?next=/stats and after successfully
authenticating, will be sent back to /stats (this time getting the
spartan view of the game statistics).
There is another set of pages that is more minmal than we really
want. This is all in the area of user that successfully authenticates
but doesn't have the "admin" role. I'm ignoring all of these issues
for now because I'm not going to actually configure any such
users. But here are the issues:
* If a user without the admin role hits /stats they they will get a
correct 401 status, but a very spartan page (just the word
"Unauthorized" as plain text).
* In that case, if the user wants to logout there are no links
provided to do that.
* There _is_ a page at /logout which does do a correct logout, but
again returns a very spartan, plain-text message that you are
logged out.
Carl Worth [Wed, 20 May 2020 23:56:43 +0000 (16:56 -0700)]
Add simple session tracking
By taking advantage of the express-session module.
Note that we're not actually using the session for anything yet, so we
haven't configured anything such as the expiration time or even which
backend should be used for storing the session data (meaning the
session data will just be stored in memory for now).
We do add the very beginnings of a configuration file here, which for
now simply has a "secret_session" key with the random data for the
session manager to use.
Also, we configure both the "resave" and the "saveUninitialized"
properties on the session object to avoid the warnings about the
deprecated values for these two properties.
Carl Worth [Wed, 20 May 2020 02:10:27 +0000 (19:10 -0700)]
lmno: Be forgiving in game ID values received from the user
Most significantly, we now accept a lowercase version of the ID.
But also, game ID values are intentionally chosen not to have
ambiguous character in them, (such as "M"/"N" or "S"/"F"), which might
sound similar when someone says a game ID aloud. So on the input side
we accept either form and canonicalize to the only letter which can
possibly exist in a game ID.
Carl Worth [Sun, 17 May 2020 21:45:34 +0000 (14:45 -0700)]
empires: Serve the actual game file from the root of the app
This game.html file is actually totally static, but it lives at a
dynamic path (which includes the game ID in the path), so within the
dynamic app we need to serve the static file. To arrange for this we
symlink to the static file. Note that we're not committing the symlink
to git since the destination location can differ on each system.
Carl Worth [Sun, 17 May 2020 19:40:44 +0000 (12:40 -0700)]
Incorporate empires.js as a sub-app within lmno.js
Now, instead of calling listen() the empires.js simply exports its app
object so that the higher level lmno server can mount all of its
available paths with app.use('/empires/<GAMEID>/', empires.app).
At the same time, empires.js no longer constructs a Game object, but
instead the higher-level /new API within lmno.js calls into
empires.Game to create a game for a specific ID. Then, there's also a
new middleware in lmno.js to lookup this game object by the ID from
the path and add it as a property of the request object. So all of the
empires.js entry points now fetch that game object from the request as
their first statement.
Carl Worth [Sun, 17 May 2020 19:28:35 +0000 (12:28 -0700)]
empires: Return immediately from reveal_next if we aren't in the REVEAL state
I think this fix came about after Kevin did some testing by mashing on
all of the host buttons as fast as possible.
It's definitely a correct fix as far as it's true we shouldn't be
revealing anything if we're not in the REVEAL state. But I think we're
due for a better audit of what's happening to various pieces of state
on state transitions, (such as, shouldn't the interval timer get
cleared before we _leave_ the REVEAL state).
Carl Worth [Sun, 17 May 2020 19:26:42 +0000 (12:26 -0700)]
Rename server.js to empires.js
We have multiple express-based server apps implemented here now, so
the name "server.js" is now ambiguous. We rename it "empires.js" to
make clear that its an implementation only of the empires game.
Carl Worth [Sun, 17 May 2020 19:19:53 +0000 (12:19 -0700)]
Add a new server: lmno.js
This is the new top-level server for all dynamic content and games
that we plan to host at https://lmno.games. The previous server
implementation (in server.js) will likely be subsumed as a
sub-application within this new server soon.
Carl Worth [Mon, 11 May 2020 23:03:54 +0000 (16:03 -0700)]
Implement a more correct response to /reset
Specifically, we fix things here to clear some internal state that was
previously being missed (the "characters_to_reveal" field) and we also
fix things to report to the clients the new game state and the emptty
list of players.
Carl Worth [Mon, 11 May 2020 21:52:09 +0000 (14:52 -0700)]
Send multiple game-state events (if needed) when a client connects
This implements the latest change as of version 0.6 of the API protocol.
This change fixes a bug in the current empires-html client where
reloading the browser when in the middle of the game would break the
client, (by displaying some content that's inappropriate for the
current state). By sending each step-wise transition through the game
states, the client does not get confused.
Carl Worth [Sun, 10 May 2020 22:45:46 +0000 (15:45 -0700)]
Implement the /reveal,/start endpoints as well as the "game-state" event
This brings us up to protocol version 0.5 and should be a pretty
playable server at this point. Upon receiving the "/reveal" API
request the server will transition to the "reveal" game-state and from
there will broadcast the names of each character to all clients, one
name every three seconds, (and sending an empty name at the end to
clear off the last name). The "/reveal" API request can be sent
additional times if the players want to see the names again.
Carl Worth [Sun, 10 May 2020 21:21:19 +0000 (14:21 -0700)]
Rename a variable from "player_string" to "player_data"
The name of "player_string" made me think this is just a string
representation of a player's name. But instead, this variable is
holding the JSON representation of the data block of a
"player-register" event. So a name of "player_data" is much more
clear.
Carl Worth [Sun, 10 May 2020 15:40:14 +0000 (08:40 -0700)]
Send a comment to every connected client every 15 seconds
This prevents timeouts when the client receives nothing from the
server. For example, firefox appeares to give up on the server when it
receives nothing for two minutes.
Carl Worth [Sun, 10 May 2020 15:35:21 +0000 (08:35 -0700)]
Rename broadcast() to broadcast_event() supported by broadcast_string()
The lower-level broadcast_string() simply sends a string to all clients.
The higher-level broadcast_event() sends a structured event (with both an
event type and a separate data block, as well as ending with two newlines),
exactly as clients will be expecting.
Carl Worth [Sun, 3 May 2020 22:03:56 +0000 (15:03 -0700)]
Add some linting fixes
Specifically some missing semicolons and a missing const.
It's funny that I didn't realize that emacs was doing live linting of
JavaScript all along here, (and highlighting all problems with various
colors and underlining).
Carl Worth [Sun, 3 May 2020 02:24:34 +0000 (19:24 -0700)]
Add simple testing for the entire API
This is more "exercising" than testing, (it doesn't currently verify
the results), but I've verified the server isn't hitting any syntax
errors (with fairly decent code coverage I think) and I've manually
inspected the results to ensure they look correct.
Carl Worth [Sat, 2 May 2020 23:53:13 +0000 (16:53 -0700)]
Add an ID value to each player
This is a first baby step toward implementing the more complete API
for the game which we defined today, and which can be found here:
https://git.cworth.org/git/empires-api
In this commit we also introduce a 'Game' class to encapsulate all
data necessary for the game, (so the 'players' array we had before,
but also the 'next_player_id' which we need now).