In the magic-removal branch (see
http://code.djangoproject.com/wiki/RemovingTheMagic), we're removing
the magic model modules, which means the concept of "module_name" goes
away. This creates a bunch of interesting new issues, because some
parts in Django use module_name -- namely, the admin URLs.

Old (current) admin URLs look like this:

    /admin/blog/entries/add/

Where the "blog" is the name of the model module and "entries" is the
name of the magic module created for Entry. (Whew! Hard to explain.
Aren't you glad we're changing this?)

But in magic-removal, module_name ("entries") goes away. Plus, models
are no longer imported from "django.models.", which means they can
live anywhere (e.g. from myproject.blog.models import Entry).

With that in mind, what's the best way to specify admin URLs from now on?

One solution would be to do this:

    /admin/myproject.blog.models.entry/add/

Or substitute slashes for dots:

    /admin/myproject/blog/models/entry/add/

Or maybe get rid of the "models" cruft:

    /admin/myproject/blog/entry/add/

The problem with "/admin/myproject.blog.models.entry/", though, is I'm
not sure it's possible to get the Python path *to* an object. For
example, given a model Entry, how do we get the string
"myproject.blog.models.entry"? A model needs to know how to calculate
its admin URL. And it's a bit of a security risk, if whatever's in the
URL is directly imported. We couldn't stop somebody from going to
/admin/path.to.nasty.module/ -- if an attacker has access to putting
objects on the Python path somehow, he could run arbitrary code.

Another solution could be "/admin/blog/entry/", where "blog" is the
app name (blog/models.py) and "entry" is a lowercased version of the
model class name. The disadvantage of this is (obviously) the app
namespace is only one-level deep. Granted, these disadvantages have
been present in the old system and haven't bitten us.

Thoughts?

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

Reply via email to