189
.. _ref-python-console:
189
.. ref-python-console
194
194
IVLE provides a web based programming console, exposing similar features to
195
Python's command line console. It is built around the
196
:file:`services/python-console` script, which opens up a socket on a random
197
port to which `JSON`_ encoded chat requests can be made.
199
A new console is typically launched on demand by the web client to the HTTP
200
API, which in turn calls the wrapper class :class:`ivle.console.Console` to
201
start a new console in the user's jail.
203
Subsequent requests from the same in-browser console connect to the existing
204
console process. This is achieved by storing a string on the client which
205
identifies the server address and port. The client then makes requests
206
through the load balancer, sending this string through to an arbitrary slave
207
which forwards the request to the identified console.
209
This means that all slaves need access to all ports on every other slave.
195
Python's command line console. It is built around python script
196
:file:`services/python-console` which opens up a socket to which `JSON`_
197
encoded chat requests can be made. A new console is typically from launched on
198
demand by the web client to the HTTP API, which in turn calls the wrapper
199
class :class:`ivle.console.Console` to start a new console in the user's jail.
211
201
.. _JSON: http://json.org
214
.. _ref-usrmgt-server:
204
.. _ref-usermgt-server:
216
206
User Management Server
217
207
======================
225
215
* Creating group Subversion repositories.
226
216
* Rebuilding Subversion authorization files.
228
Communication with the Server is done using the :ref:`Chat Protocol
229
<ref-chat>`. To prevent unauthorized use, communication with the User
230
Management Server requires that a *shared secret* be used to communicate with
231
the server. This secret is stored in the `magic` variable in the `[usrmgt]`
232
section of :file:`/etc/ivle/ivle.conf`.
218
Communication with the Server is done using the `Chat Protocol <ref-chat>`_.
219
To prevent unauthorized use, communication with the User Management Server
220
requires that a *shared secret* be used to communicate with the server. This
221
secret is stored in the `magic` variable in the `[usrmgt]` section of
222
:file:`/etc/ivle/ivle.conf`.
234
224
The User Management Server is called almost exclusively from the
235
225
:mod:`ivle.webapp.userservice` module.
330
320
These repositories are served by Apache using ``mod_dav_svn`` allowing access
331
321
over Subversion's WebDAV HTTP or HTTPS backends. Users are authenticated using
332
322
a randomly generated key which is stored in the database and is made available
333
to each user inside their jail (``svn_pass`` property inside
323
to each user inside their Jail (``svn_pass`` property inside
334
324
:file:`/home/.ivle.conf`). This key is automatically provided when doing
335
Subversion actions, but can be manually entered when accessing a user's
325
Subversion actions, but can be manually entered when accessing a users
336
326
repository from an external Subversion client such as with :samp:`svn checkout
337
327
{svn_addr}/users/{USERNAME}/ workspace`.
339
Repository permissions for ``AuthzSVNAccessFile`` are automatically generated
340
and placed in the file specified by the ``paths/svn/conf`` config option
341
(usually ``/var/lib/ivle/svn/svn.conf``) for user repositories and the
342
``paths/svn/group_conf`` option for group repositories (usually
343
``/var/lib/ivle/svn/svn-group.conf``). User authentication keys for
344
``AuthUserFile`` are stored in the file specified by ``paths/svn/auth_ivle``,
345
usually ``/var/lib/ivle/svn/ivle.auth``. These will be regenerated each time
346
user or group repository settings change.
329
Repository permissions for ``AuthzSVNAccessFILE`` are automatically generated
330
and placed in the file located at ``[paths] [[svn]] conf`` for user
331
repositories and ``[paths] [[svn]] group_conf`` for group repositories. User
332
authentication keys for ``AuthUserFile`` are stored in the file located at
333
``[path] [[svn]] auth_ivle``. These will be regenerated each time user or
334
group repository settings change.
360
URLs are resolved with a small IVLE-specific object publishing framework --
361
that is, resolution is implemented as traversal through an object graph. The
362
framework lives in :mod:`ivle.webapp.publisher`, and has an extensive test
365
This object graph is constructed by the dispatcher. Any plugin class deriving
366
from ViewPlugin will be searched for ``forward_routes``, ``reverse_routes``
367
and ``views`` sequences. Everything is class-based -- an object's routes
368
and views are determined by its class.
370
Forward routes handle resolution of URLs to objects. Given a source object
371
and some path segments, the route must calculate the next object.
372
A forward route is a tuple of ``(source class, intermediate path segments,
373
function, number of subsequent path segments to consume)``, or simply a
374
reference to a decorated function (see :mod:`ivle.webapp.admin.publishing`
375
for decoration examples). The function must return the next object in the
378
A reverse route handles URL generation for an object. Given just an object,
379
it must return a tuple of ``(previous object, intermediate path segments)``.
380
This creates a chain of objects and path segments until the root is reached.
381
Due to IVLE's lack of a utility framework, reverse routes at the root of the
382
URL space need to refer to the root object with the magical
383
:mod:`ivle.webapp.publisher.ROOT`.
385
Views are registered with a tuple of ``(source class, intermediate path segments,
388
In all of the above, "intermediate path segments" can either be a single
389
segment string, or a sequence of multiple strings representing multiple
393
While many applications prefer a pattern matching mechanism, this did not
394
work out well for IVLE. Our deep URL structure and multitude of nested
395
objects with lots of views meant that match patterns had to be repeated
396
tediously, and views required many lines of code to turn a match into a
397
context object. It also made URL generation very difficult.
399
The simple object publishing framework allows views to be registered with
400
just one line of code, getting their context object for free. URL
401
generation now comes at a cost of approximately one line of code per class,
402
and breadcrumbs are easy too. The reduced code duplication also improves
343
.. TODO: Not yet merged
added
removed
doc/dev/architecture.rst
