~azzar1/unity/add-show-desktop-key

« back to all changes in this revision

Viewing changes to lib/fileservice_lib/__init__.py

  • Committer: mattgiuca
  • Date: 2008-02-05 01:51:26 UTC
  • Revision ID: svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:trunk:411
Renamed lib/fileservice to lib/fileservice_lib (naming conflict).
Added new app: fileservice. This app replaces the old one that was deleted -
it simply calls fileservice_lib.handle, and that's it (so it functions exactly
the same).

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
# IVLE
 
2
# Copyright (C) 2007-2008 The University of Melbourne
 
3
#
 
4
# This program is free software; you can redistribute it and/or modify
 
5
# it under the terms of the GNU General Public License as published by
 
6
# the Free Software Foundation; either version 2 of the License, or
 
7
# (at your option) any later version.
 
8
#
 
9
# This program is distributed in the hope that it will be useful,
 
10
# but WITHOUT ANY WARRANTY; without even the implied warranty of
 
11
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 
12
# GNU General Public License for more details.
 
13
#
 
14
# You should have received a copy of the GNU General Public License
 
15
# along with this program; if not, write to the Free Software
 
16
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 
17
 
 
18
# App: File Service (AJAX server)
 
19
# Author: Matt Giuca
 
20
# Date: 9/1/2008
 
21
 
 
22
# This application is an AJAX service. Receives file handling instructions as
 
23
# requests. Performs actions on the student's workspace, and returns directory
 
24
# listings in JSON.
 
25
 
 
26
# This rather large documentation explains the request and response to the
 
27
# file service app (it should probably be taken to a separate document).
 
28
 
 
29
# This is not intended to be accessed directly by the user. It is targeted by
 
30
# AJAX calls in applications such as browser and editor.
 
31
 
 
32
# Application usage: The input to the application is determined by the fields
 
33
# passed in as HTTP variables (either in the URL or message body). Also, in
 
34
# keeping with REST, actions only take effect if this is a POST request as
 
35
# opposed to a GET request (although a GET request is still allowed to just
 
36
# get a listing or file dump). Also, the "path" (the part of the URL
 
37
# after "fileservice" and before the GET variables) is taken into account.
 
38
 
 
39
# Aside from the side-effects to the server (note: side-effects are only
 
40
# possible for POST requests), the response takes two parts. The response
 
41
# header contains information about success or failure of the operation. The
 
42
# response body may contain the requested file.
 
43
 
 
44
# Fileservice has two separate roles: First, an action is performed. This may
 
45
# be a copy, write, or svn up operation. Then, a file or directory listing is
 
46
# returned. This directory listing may be completely separate from the action,
 
47
# but they are performed together because the client will usually want to
 
48
# perform some action, then update its display as a result of the action.
 
49
 
 
50
# GET requests will have all variables ignored, and the only behaviour will be
 
51
# to generate the directory or file listing. POST requests will result in an
 
52
# action if one is specified. If the action is UNSUCCESSFUL, returns the
 
53
# header "X-IVLE-Action-Error: <errormessage>". Successful actions succeed
 
54
# silently. Note that the action does not affect the HTTP response code (it
 
55
# may be 200 even upon failure).
 
56
 
 
57
# The path (req.path) controls which file or directory will be
 
58
# returned. If it is a file, returns the header "X-IVLE-Return: File" and
 
59
# status 200 OK. The response body is a verbatim dump of the file specified.
 
60
# The Content-Type will probably be text/plain but should not be relied upon.
 
61
# If it is a directory, returns the header "X-IVLE-Return: Dir" and status
 
62
# 200 OK. The response body is a JSON directory listing (see below). The
 
63
# Content-Type cannot be relied upon. If the file is not found or there is
 
64
# some other read error, returns no X-IVLE-Return header, a 400-level
 
65
# response status. (404 File Not Found, 403 Forbidden, etc), and a header
 
66
# "X-IVLE-Return-Error: <errormessage>".
 
67
 
 
68
# See action.py for a full description of the actions.
 
69
# See listing.py for a full description of the output format of the directory
 
70
# listing.
 
71
 
 
72
import os
 
73
import shutil
 
74
import stat
 
75
import time
 
76
import mimetypes
 
77
 
 
78
import cjson
 
79
import pysvn
 
80
 
 
81
from common import (util, studpath)
 
82
import conf.mimetypes
 
83
 
 
84
import action, listing
 
85
 
 
86
# Mime types
 
87
# application/json is the "best" content type but is not good for
 
88
# debugging because Firefox just tries to download it
 
89
mime_dirlisting = "text/html"
 
90
#mime_dirlisting = "application/json"
 
91
 
 
92
def handle(req):
 
93
    """Handler for the File Services application."""
 
94
    # Make sure the logged in user has permission to see this file
 
95
    # FIXME: Still need to authorize subpaths in actions
 
96
    studpath.authorize(req)
 
97
 
 
98
    # Set request attributes
 
99
    req.write_html_head_foot = False     # No HTML
 
100
 
 
101
    # Get all the arguments, if POST.
 
102
    # Ignore arguments if not POST, since we aren't allowed to cause
 
103
    # side-effects on the server.
 
104
    act = None
 
105
    fields = None
 
106
    if req.method == 'POST':
 
107
        fields = req.get_fieldstorage()
 
108
        act = fields.getfirst('action')
 
109
 
 
110
    if act is not None:
 
111
        try:
 
112
            action.handle_action(req, act, fields)
 
113
        except action.ActionError, message:
 
114
            req.headers_out['X-IVLE-Action-Error'] = str(message)
 
115
 
 
116
    listing.handle_return(req)