Project URL-prefix

[Dmitry Azhichakov]

Hello, everyone.

A little background for a problem first. I'm trying to write a tiny
Django project for our corporate usage (my first one using Django).
Every team has an account on a Linux box where we can host our web
applications with URLs like: http:://server/~project/bin/app and every
application is running with premissions of a corresponding "project"
account.

I've tried to deploy a Django project with FastCGI and faced a problem
with apps using absolute URL in their templates. In particular, login
page to admin interface has an URL:
http:://server/~project/bin/app/admin/ but the form on the page has
action="/admin/". I've explored django.contrib.admin sources a bit and
found that it uses request.path to retreive an absolute URL of the app.

I've also tried to find a solution in the official documentation and this
list archives, but all I found is about an URL of app relative to the
root of the project but not an URL of the project itself.

So, I've made a three-liner hack (wich actually breakes some rules
mentioned in the official documentation). I've created a middleware
class:

class AbsolutePath :
def process_request( self, request ) :
request.path = request.META["SCRIPT_NAME"] + request.META["PATH_INFO"]

and inserted it before all others. Fortunately, it even works :), though
I don't completely understand why it do ;). I've expected to be required
to prepend the project prefix to every urlpattern, but they should be
left alone to work properly. It also produces not a very nice URL in my
case, replacing "~" with "%7E" after a login, though it's looking Ok in
the login page source.

At last, the question: is there a less hacky solution to this problem,
or my solution is Ok?

--
Dmitry

[David Sissitka]

I ran in to a similar problem when deploying a Django project under a
sub directory. The project could be accessed at /django, and the
administrative log in at /django/admin. The form is supposed to submit
to itself, but it was submitting to /admin. I did a bit of digging,
and it turns out that the variable that holds the value of the form's
action attribute, app_path, wasn't being set correctly. At the time I
didn't have the time to figure out exactly what the problem was, but
placing a modified version of login.html in one of the project's
template directories did the trick. My host said that this was a bug
in Django, and that Andy from ReportLab planned on writing about the
issue in more detail.

-David Sissitka

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD4DBQFFPcpCJ/Gp8hRRFgURAvsWAJ9ZAMp4e7AuRNUOIGQKT9BToVwWGQCUCZv3
> bRtn8uGgxtLQyrnSLQJWhQ==
> =UM1a
> -----END PGP SIGNATURE-----
>
>
>

[Dmitry Azhichakov]

On Tue, Oct 24, 2006 at 04:49:59AM -0400, David Sissitka wrote:
> At the time I
> didn't have the time to figure out exactly what the problem was, but
> placing a modified version of login.html in one of the project's
> template directories did the trick.

It was my first solution too, but there are other places in the admin
interface that need to be fixed (e.g., "Send and add another" when editing an
object). I don't want a copy of all admin templates in my project.
I'm completely fine with the default ones. So I came to this solution.

I've found some other minor side effects of the solution above, so it
should properly be called a "dirty workaround" :)

--
Dmitry

[David Sissitka]

Hrm, just double checking now and I cannot replicate the problems you've listed. Anyways, it looks like ticket #285 mentions a very similar problem, but they've determined that the cause is CGI related and I'm using mod_python.

-David Sissitka

On 10/24/06, Dmitry Azhichakov <dazhi...@gmail.com> wrote:

It was my first solution too, but there are other places in the admin
interface that need to be fixed (e.g., "Send and add another" when editing an
object). I don't want a copy of all admin templates in my project.
I'm completely fine with the default ones. So I came to this solution.

I've found some other minor side effects of the solution above, so it
should properly be called a "dirty workaround" :)

--
Dmitry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFPdyzJ/Gp8hRRFgURAqfPAJ4l4qjGygiSG5OWUZFOSD9h1EvO4ACeI4eU
9icAUhdEQqOr/Jno0WNx9e8=
=M36U
-----END PGP SIGNATURE-----