MozillaWiki

Auto-tools/Projects/Pulse/PulseGuardian: Difference between revisions

Page Discussion

Auto-tools/Projects/Pulse/PulseGuardian (view source)

Revision as of 22:42, 30 April 2014

55 bytes removed ,  30 April 2014
Added info about getting a queue's user and such
m (PeerGuardian -> PulseGuardian, and added implementation details)
(Added info about getting a queue's user and such)
Line 18: Line 18:
= Design and Approach =
= Design and Approach =


PulseGuardian will need to know who owns a given queue in order to attempt to contact its owner. There are two good choices: the queue name and the username.  The former is simple to set up, since it is entirely defined by the client. We could just use a convention, such as appname_email, where "appname" can be anything, and "email" should be a valid email address.  However, since pulse is a public resource, this is open to abuse; anyone could provide anyone else's email, potentially deluging them with pulse messages.
PulseGuardian will need to know who owns a given queue in order to attempt to contact its owner. Since we currently use the same user for all consumers, we have no way to know which person to contact.


A more secure way is to provide email validation.  Thus we will need a simple web client that performs standard registration: accepts a username and password, emails a verification link/code, and creates the user in RabbitMQ when verified.  It should also provide a method to reset a user's password and to delete the user.  Finally, it should provide a method (REST API) to download archived messages (see below).
We need a web app that performs standard registration: accepts a username and password, emails a verification link/code, and creates the user in RabbitMQ when verified.  It should also provide a method to reset a user's password and to delete the user.  Finally, it should provide a method (REST API) to download archived messages (see below).


The second part is a process that polls RabbitMQ, looking for queues above a set length (WARN_QUEUE_SIZE).  If the queue belongs to a user with a properly formatted username (i.e. an email address), a warning email is sent containing the queue name and current queue length.  After a second threshold is reached (DEL_QUEUE_SIZE), the queue is deleted, and another email is sent.  If the username is not a proper email address (e.g. the public user), the queue is silently deleted when DEL_QUEUE_SIZE is reached (no action is performed at WARN_QUEUE_SIZE).
The second part is a process that polls RabbitMQ, looking for queues above a set length (WARN_QUEUE_SIZE).  If the queue belongs to a user with a properly formatted username (i.e. an email address), a warning email is sent containing the queue name and current queue length.  After a second threshold is reached (DEL_QUEUE_SIZE), the queue is deleted, and another email is sent.  If the username is not a proper email address (e.g. the public user), the queue is silently deleted when DEL_QUEUE_SIZE is reached (no action is performed at WARN_QUEUE_SIZE).
Line 27: Line 27:


We'll have to think through this feature a bit to determine the implications of a client trying to consume while PulseGuardian is also consuming them (or trying to).
We'll have to think through this feature a bit to determine the implications of a client trying to consume while PulseGuardian is also consuming them (or trying to).
= Notes =
As we RabbitMQ's management plugin API doesn't give us the user who created a queue, we'll probably have to poll RabbitMQ to detect queues that aren't assigned to any user and assign each of them to the user of the consumer currently consuming them (reminder: In our pattern, we should only have one consumer maximum per queue)


= Implementation =
= Implementation =
Akachkach
4

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/971723"