Adrian Holovaty wrote: > 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. 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.
