{"id":2072,"date":"2011-10-04T13:15:07","date_gmt":"2011-10-04T21:15:07","guid":{"rendered":"http:\/\/blog.mozilla.org\/webdev\/?p=2072"},"modified":"2011-10-04T13:43:13","modified_gmt":"2011-10-04T21:43:13","slug":"meet-the-larpers","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webdev\/2011\/10\/04\/meet-the-larpers\/","title":{"rendered":"Meet the LARPERs"},"content":{"rendered":"

With the launch of our Mozillians.org community phonebook<\/a>, I wanted to talk about it\u2019s unusual data access model.<\/p>\n

Typical Web Apps<\/h3>\n

Most web applications use a single shared authentication<\/strong> account to access data.<\/p>\n

Users authenticate to the site as themselves, but the web app has business logic to control who sees what from the database. The code has a shared username, say web-rw<\/code> and a shared password to connect to a MySQL database.<\/p>\n

With the phonebook, we want to eventually support fine-grained privacy controls, much like G+ Circles or Facebook Profile settings. Profile information is sensitive, as we will eventually add t-shirt size, home address, etc. These details should be given out only to trusted groups within the phonebook; not every phonebook user, nor the public.<\/p>\n

Gerv chose OpenLDAP<\/a> as the backend data store, for its ability to provide fine-grained permissions through it\u2019s Access Control List (ACL) feature. Instead of a shared credential<\/strong>, we connect<\/strong> to the LDAP directory as the user on every request<\/strong>.<\/p>\n

Enter LARPER<\/h3>\n

\"LARP<\/a><\/p>\n

So what does this have to do with my favorite Saturday pastime – LARPing<\/a>?<\/p><\/blockquote>\n


<\/p>\n

To make this all work, we had to roll our own data access model: L<\/strong>DAP A<\/strong>uthentication for R<\/strong>esources P<\/strong>er E<\/strong>ach R<\/strong>equest aka LARPER.<\/p>\n

A typical usage looks something like this:<\/p>\n

\r\nfrom larper import UserSession\r\n\r\ndef search(request):\r\n   ...\r\n   directory = UserSession.connect(request)\r\n   results = directory.search(query)\r\n   return jingo.render(request, 'search.html', dict(people=results))\r\n<\/code><\/pre>\n
Under the covers, LARPER manages LDAP connections, binding, marshaling results into person objects etc.<\/p>\n
Breaking Modern Frameworks<\/h4>\n
Django and many modern web app frameworks assume a shared authentication model to the database. They totally break when we want to do per user per request access<\/strong>. Connection pooling, API design, etc are hosed. At best these frameworks support a limited set of connection credentials, but they do not support a per-user database connection model.<\/p>\n
So why would we go against the grain and inflict so much pain onto ourselves?<\/p>\n
Defense in Depth<\/h5>\n
If there is a bug in our web application code, we are less likely to leak data since the database itself is handling ACL. This responsibility lies in the data store, instead of the middleware.<\/p>\n
Modularity<\/h5>\n
Our OpenLDAP server \u201cslapd\u201d has a single config file for managing the Access Control List<\/a>. This ACL config file is a clean, single, clear place to capture static authorization rules.<\/p>\n
ORM DoesNotWant<\/h5>\n
A last reason we need a new layer is that Django has an object\/relational mapping model. We don\u2019t need this since LDAP directories are already object oriented and not relational data.<\/p>\n
Okay, LARPing is not all rainbows and unicorns…<\/p>\n
Leaky Abstractions<\/h4>\n
There are some cracks in LARPER, which may be ironed out over time.<\/p>\n
Shared Authentication Credentials<\/h5>\n
Okay, I lied. There are several non-user accounts:
\n* LDAPAdmin – Can delete an account
\n* regAgent – Can create a new account
\n* replicationAgent – Read only access to everything in the directory for replication
\n* monitor – Useful for operations agents to monitor server health<\/p>\n
We\u2019ve tried hard to keep \u201cadmin\u201d type accounts to a minimum. Actions like vouching, inviting others, etc are done via LARPER as the current user, but this does break down in terms of some tasks. Do you give these capabilities to a set of users? Whom? How do you get that first user into the system? Who vouches this first user? etc.<\/p>\n
Metrics<\/h5>\n
We have web analytics, but to get deep community metrics, we\u2019ll need access to some aggregate information. For now we\u2019re keeping a copy of some data in MySQL to be aggregated and analyzed.<\/p>\n
Code Paths without a Request<\/h5>\n
There are places in the code where Django\u2019s framework doesn\u2019t make the current request available, so we don\u2019t use the LARPER abstraction. We can patch these cracks in the future.<\/p>\n
Performance and Scalability<\/h5>\n
A LARPER style architecture is inherently harder to optimize. Breaking Django\u2019s assumptions, we don\u2019t get its optimizations for free either.<\/p>\n
Examples:<\/p>\n