Admin URLs in magic-removal branch

[Adrian Holovaty]

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

[Afternoon]

On 15 Dec 2005, at 3:15, Adrian Holovaty wrote:

> /admin/myproject/blog/entry/add/

+1, most readable, most compact, most guessable.

> 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"?

obj.__module__ + "." + obj.__class__.__name__

> 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.

As Django matures and more apps arrive, namespace clashes are going
to becoming more likely, I think it's important to build namespace
scope in now. I fully support making everything namespaced to the
project and the app.

________________________________
Afternoon, man about the Internet -- http://aftnn.org/

[Ian Holsman]

my 2c's
add the model name as a parameter to the view so that the developer
can stick the admin screens directly into their application

ie
/forum/ calls my view
/forum/add would call the admin add view with myproject.model.forum as
a parmeter

and so on.

but to answer your specific question I would like to see
/admin/<application>/<model>/add
where application is the 'short' version.. ie 'forum' would be short
for zilbo.apps.forum
and that shorthand could live in the content-type table perhaps?

--
I...@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909

If everything seems under control, you're not going fast enough. -
Mario Andretti

[Ian Holsman]

On 12/15/05, Afternoon <afte...@uk2.net> wrote:
>
>
> On 15 Dec 2005, at 3:15, Adrian Holovaty wrote:
>
> > /admin/myproject/blog/entry/add/
>
> +1, most readable, most compact, most guessable.
>
> > 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"?
>

my other concern with putting the python path into the URL is would it
allow nasty thing
like
admin/init.me.and.i.format.your.hard_disk/
?
and other weird easter eggs which a unsuspecting admin doesn't realize
is on his machine?

[Adrian Holovaty]

On 12/14/05, Ian Holsman <kry...@gmail.com> wrote:
> my other concern with putting the python path into the URL is would it
> allow nasty thing
> like
> admin/init.me.and.i.format.your.hard_disk/
> ?
> and other weird easter eggs which a unsuspecting admin doesn't realize
> is on his machine?

Clearly we would want to avoid that. Before importing, it could check
that the module is in INSTALLED_APPS.

[Afternoon]

On 15 Dec 2005, at 3:59, Adrian Holovaty wrote:

> Clearly we would want to avoid that. Before importing, it could check
> that the module is in INSTALLED_APPS.

By going with /admin/project/app/model/add/ stick with more normal
looking urls, you can do the checking at quite a fine-grained level,
plus you get a few nice things such as the ability to add pages at
intermediate points. You could stick a handy status page at /admin/
project/ for example. /admin/project/app/ would look like the current
admin home page, but with only models defined in the specified app.
Useful for bigger sites, actual admins go to /admin/ and can control
a bunch of stuff. Lesser admins, e.g. content editors, could just be
pointed at /admin/mycmsproject/cms/.

[Jeroen Ruigrok van der Werven]

On 12/15/05, Adrian Holovaty <holo...@gmail.com> wrote:

> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/

+1 for being the most readable and less cumbersome.

--
Jeroen Ruigrok van der Werven

[Robert Wittams]

I don't really get this - the module would not be imported by this. The
lookup would trigger the normal model loading. Then the path to it would
be resolved against the loaded models, and that resolution could only
result in a valid, loaded model class.

> 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.

Also, the model namespace is only one deep, eg if you had a nested set
of model modules in your app, they would be flattened. Granted, it would
probably be pretty stupid to have conflicting class names in one app
anyway...

I think I'll try to do this last one for now as it is closest to the old
system and we can always change it later if we reach a consensus. Also,
it is the easiest to understand for the template overriding stuff in the
admin imo.

[Jacob Kaplan-Moss]

On Dec 14, 2005, at 9:15 PM, Adrian Holovaty wrote:
> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/
>

This one's my favorite.

Double points if /admin/myproject/ shows a list of models under
myproject (and /myproject/blog/ shows all the ones under
myproject.blog); triple points if there's a quick and easy way to
provide my own custom template and/or view for any of those levels.

Jacob

[ToddG]

I don't know if there's a mathematical formula for this, but it's
looking like all ideas are approaching an object traversal/resolution
scenario like in: Zope, Quixote, CherryPy, etc. Perhaps one of those
can offer some direction.

[Robert Wittams]

I think most of those work on an instance heirarchy, this is more
slanted towards the package/type heirarchy. Or not?

Also, it elides the 'models' package, which would I think be kind of odd
with a full blown object traversal thing. And this really is just for
one (important) application, so I doubt at this point we need that level
of sophistication/flexibility.

[ToddG]

I think Cherry is more instance-y, Quixote was more package-based but
with v.2 is now more explicit with "Directory" classes that define
traversals. I think. I don't use either in real life.

Just thought I'd mention them as references that might be applicable --
even if they're too much for this specific case, they may have some
ideas... at the moment I'm not up to speed on Django internal
admin-magic to cite anything specific I'm afraid.

[Eugene Lazutkin]

"Adrian Holovaty" <holo...@gmail.com> wrote
in message
news:6464bab0512141915k4d9...@mail.gmail.com...

>Or substitute slashes for dots:
>
> /admin/myproject/blog/models/entry/add/

I like this better. Slashes are better than dots.

Thanks,

Eugene

[James Bennett]

On 12/14/05, Adrian Holovaty <holo...@gmail.com> wrote:
> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/

+1

--
"May the forces of evil become confused on the way to your house."
-- George Carlin

[oggie rob]

Would it be possible to override the url location within the
modules/classes? My only concern is that sometimes the project, module
and/or class name are not an appropriate part of a URL, and would be
nice to easily override. (This of course assumes that URLs are part of
the UI, which I feel is true.)

-rob

[Robert Wittams]

I'm not sure what you mean by this, could you expand on it a bit?

[oggie rob]

Sure. There may not be a need for a "project" dir when you have only
one project running. It is cleaner to simply have /admin/blog/entry/add
or even /admin/entry/add. Also, you may want your model to technically
describe the object accurately, but present it to the user in a more
readable way, or for the sake of programming ease use shortened names
for the model e.g. UserPrefs which might turn into '/preferences'.
Of course, this should all be optional as usual.

I figure you could pretty simply use a reserved property or method in
the module or class, something like __adminurl__.

-rob