An infinite loop was fixed in the notification system. A number of minor CSS integration details were implemented. The architecture of a django based authentication was discussed.
bug fixes
When the game stayed more than 5 minutes (the time for a poll request to timeout) in a given state, email notifications were sent to all players every 5 minutes. This came from a bug that fixed in the notification system. When a plugin (such as mail) registered to be notified about each game event, it indirectly called the poll method of pollable. However, this method timesout after 5 minutes. The game_notify function is unprepared to receive a timeout and assumes it is an event.
The poll function was split in two (wait and poll) and the game_notify now relies on wait which will never timeout. The timeout only has meaning in the context of the JavaScript client that may be disconnected. It does not do anything useful for a plugin that resides in core.
A few minor bug were fixed:
- do nothing if the result is None. Otherwise it would fail because has_key is not a method of None
- do not consume errors, otherwise a plugin that tracebacks goes unoticed
- do not send email notifications on pick and vote
- /etc/cardstories must belong to cardstories so that plugins are allowed to create files in it at startup time
- add missing python-twisted-conch dependency (needed for manhole)
- IssueID #102. When a user is discarded because he did not vote, the card must be shown but the player name is not available. Handle this case instead of raising an exception
CSS integration
Tartaruga Feliz reviewed the aspect of the pages and filled a number of bugs. Some of them were fixed.
- Comment out fb display because it does not work yet. Use padding and div to position elements instead of absolute positioning for all, which get confusing when there are so many elements that could be positionned using the normal flow.
- lobby and welcome
- Add temporary placeholder for voter view of the sentence.
- Fixes #78. Button for the solo player mode.
- IssueID #30. Add monster.
- Fixes #136. it should be players instead of player
- Fixes #134. outline: none; prevents a blue border around textarea.
- Fixes #129. outline: none; prevents a blue border around textarea.
- Fixes #131. The card is missing the border
- Fixes #128. The text that is displayed on the white box (a sentence related to the card) should be Helvetica 12pt #000000
- IssueID #102. Show a card that has no player when reviewing the complete page.
authentication
The auth plugin is a minimal placeholder designed for tests. For production cardstories would be integrated as part of a framework (such as symfony or django) and the auth plugin adapted to rely on it. The integration of cardstories in django was discussed on IRC.
(02:03:25 PM) arbrandes: Hey dachary, we'd like to discuss how you envision framework authentication working with cardstories
(02:04:10 PM) arbrandes: So, basically, I'm looking at the current auth plugin in cardstories
(02:04:24 PM) arbrandes: The first question is: am I looking at the right place? :)
(02:04:40 PM) dachary: yes :-)
(02:04:43 PM) dachary: arbrandes: cardstories is a webservice that has no notion of authentication. It assumes this will be handled by something else.
(02:04:54 PM) dachary: the auth plugin really is a placeholder
(02:05:27 PM) dachary: and I think it would be replaced by a django specific authentication module that provides the same kind of mapping between user names and unique ids
(02:06:50 PM) dachary: arbrandes: I don't know django. Here is a possible scenario I have in mind.
(02:06:54 PM) arbrandes: Ok, before we get into the specifics of authentication, how do you see Django itself (or any framework for that matter), coexisting with the cardstories webservice?
(02:07:07 PM) dachary: ok
(02:07:41 PM) dachary: I assume the JS client would be in a django page.
(02:07:50 PM) arbrandes: Django is in python, but as any framework, it makes several assumptions about code structure that basically don't have anything to do with how cardstories does it currently.
(02:08:19 PM) dachary: arbrandes: I understand that. cardstories would be an independant daemon.
(02:08:26 PM) dachary: the client is served by django
(02:08:27 PM) arbrandes: Ok, so we're talking about it running elsewhere (different port, different domain, what have you)
(02:09:22 PM) arbrandes: dachary, are we talking soap, json, or just setting a cookie?
(02:09:29 PM) dachary: I'm thinking more reserving specific path to cardstories that would be ignored by django
(02:09:46 PM) dachary: no soap at all
(02:10:12 PM) dachary: cardstories daemon do not rely on cookies at all
(02:10:36 PM) dachary: it's pure json
(02:12:09 PM) dachary: arbrandes: let say /resource is transparently proxied by django (or a reverse proxy sitting in front of django) to the cardstories daemon
(02:12:19 PM) dachary: the js client could be served by django
(02:12:21 PM) arbrandes: Ok, that makes sense
(02:12:27 PM) dachary: and issue ajax requests to cardstories
(02:12:38 PM) dachary: without having "same domain" troubles
(02:12:48 PM) arbrandes: So "client" is the browser, server is cardstories, and django would run transparently on a proxy. Alright.
(02:12:52 PM) dachary: (it actually is the current http://cardstori.es/ setup)
(02:13:09 PM) dachary: arbrandes: yes
(02:13:19 PM) dachary: regarding authentication, it could go like this:
(02:13:39 PM) arbrandes: (Yeah, cross domain stuff is a pain)
(02:13:56 PM) dachary: a) when the cardstories server receives a request, it catches a session cookie (presumably set by django) that contains a session hash
(02:15:02 PM) dachary: b) the cardstories server queries django (database request ? dedicated URL available only internaly ?) to retrieve the user id (unique number)
(02:15:25 PM) dachary: c) the cardstories server returns the result depending on wether such a user exists, is logged in or not
(02:15:36 PM) dachary: arbrandes: does that make sense ?
(02:16:47 PM) arbrandes: Yes, it makes sense. Not sure about the specifics yet. Let's see...
(02:16:59 PM) arbrandes: Currently, the cardstories auth plugin uses an sqlite backend
(02:17:24 PM) arbrandes: One way to see it would be to have Django as the backend
(02:18:14 PM) arbrandes: I like the dedicated URL idea because it makes the whole thing more modular.
(02:18:23 PM) arbrandes: But less efficient.
(02:20:07 PM) dachary: Is there a session table in django that could be used to do something like "select user_id from session where session_hash = HASH_FROM_COOKIE "?
(02:20:30 PM) arbrandes: You guys currently have the concept of a login name. Each login would have a unique "user id", which I take it already exists in auto_increment fashion.
(02:20:57 PM) arbrandes: Yes, it's possible
(02:21:24 PM) dachary: that's what the auth module does, indeed. But there is no concept of a login name outside of the auth module.
(02:21:38 PM) dachary: Only a unique numerical identifier for each user.
(02:21:56 PM) arbrandes: (I think so, at least, most of the work I've done with django sessions was mostly mom-and-pop stuff handled automatically by the framework)
(02:22:45 PM) dachary: if it's possible then the implementation is quite straightforward. From the current auth module it would mean select on the django base after extracting the cookie and be done with it.
(02:23:19 PM) arbrandes: Ok, sounds good to me
(02:24:00 PM) dachary: If it turns out to be not so easy, there is another option.
(02:24:28 PM) arbrandes: Are we sticking with sqlite?
(02:24:39 PM) arbrandes: Go ahead, what's on your mind
(02:25:05 PM) dachary: (re sqlite : do you mean for the auth module ? or in general for the cardstories daemon ?)
(02:26:44 PM) dachary: The auth cardstories plugin could issue a http GET to django with the session hash in argument and expect the user_id in return (or nothing if the user is not logged in or the session is fabricated). That would achieve the same goal and may be easier if it turns out that the mapping session hash <=> user id is not stored in the django database.
(02:27:13 PM) dachary: These two options cover all the possible authentication cases I can think of, whatever the framework involved.
(02:27:54 PM) arbrandes: Scratch the sqlite thing. I'm not going to mess that far into the code yet. In any case, it looks as if it's possible (especially if we can get the auth module to import django stuff): http://scottbarnham.com/blog/2008/12/04/get-user-from-session-key-in-django/
(02:31:22 PM) dachary: http://scottbarnham.com/blog/2008/12/04/get-user-from-session-key-in-django/ would be a simple way to implement a django URL returning the user when given the session indeed.
(02:31:48 PM) dachary: I honestly have no preference (i.e. accessing sql tables versus querying a URL).
(02:33:08 PM) dachary: I don't even see a need to keep such a URL private because it does not reveal any sensitive information. I assume the user id number is exposed in a number of places already.
(02:34:16 PM) arbrandes: I like the external URL because it becomes possible to have the auth daemon live on a completely different server (although that would also be possible if the django session database runs on something like mysql, or maybe even memcached).