1. Fred T-H
  2. chut


Fred T-H  committed 9c71bea

Javascript escaping of messages done - removed from todo list

  • Participants
  • Parent commits 274c998
  • Branches default

Comments (0)

Files changed (1)

File Home.wiki

View file
 == What's left to be done ==
 * Authentication for users
-* Escaping javascript in messages
 * Adding logging to messages sent and received
 * Notifying the user when someone he's talking to disconnects
 * Specifying functions to deal with netsplits and user registration (impossible right now with the supervision tree)
 Because Chut is meant to be plugged into an existing system, the maximum that will be done about authentication will be to do callbacks to a server that will care about all the authentication-related stuff. Chut will require a session ID (to be set in the user's cookies by the other site) and a session token (to be set in the page itself). On each call coming from the site, Chut's JS system will need to send the session token to the server with the cookie. The server will then act only after validating these. This will help protect against CSRF and identity theft, but will leave the burden of user authentication and storage on the main site, where it belongs. A cache with values for session-id and username could be added to avoid repeated calls to the main site.
-Escaping will then be needed to protect users against XSS once there is important data on the page (authentication data //is// important data). This will need to be done server-side in the mochiweb part of Chut.
 For the logging system, a simple event handler listening to every message sent and logging them on disk somewhere (or in a database) is trivial to add. That's all that needs to be done, given we have a database table already open.
 To notify a user someone he's talking to has disconnected, two options are possible. The first one is to add a lookup on each message sent (from the dispatch handler), which would then report that event to all connected clients. The second option is that when a discussion starts between two users, the FSM starts monitoring the other user. Whenever the FSM receives a message mentioning the death of a monitored user, the clients are made aware of it. This last option would require the potential addition of new functions to usr.erl, but would reduce the amount of lookups made within the global module and would let the status of the other user be known in real time rather than the sending of a message.