Python Django名称空间污染？

我对Django的名称空间有一个问题。首先，我实现了自己的身份验证系统，这样就可以为经过身份验证的用户提供在线站点编辑等功能。坦率地说，我只是不喜欢默认的管理员设置

因此，我有意识地没有包括任何身份验证中间件或管理功能

无论如何，我在

vxd.auth.models

中有一个名为

User

的模型，我在

vxd.auth.control

中使用它来读取系统的数据库。当我运行身份验证检查时，出现以下错误：

DatabaseError at /
column auth_user.first_name does not exist
LINE 1: SELECT "auth_user"."id", "auth_user"."username", "auth_user"...

当然不是，我的

用户

模型没有实现名字字段。然而，Django's确实如此

这不是一个问题，直到我升级Django并被

settings.py的相关部分：

TEMPLATE_LOADERS = ( 'django.template.loaders.filesystem.Loader',
    'django.template.loaders.app_directories.Loader',
)
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
)

AUTHENTICATION_BACKENDS = ('')

TEMPLATE_CONTEXT_PROCESSORS = ( "vxd.auth.contexts.Authentication", )

INSTALLED_APPS = (
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'reversetag',
    'markitup',
    'vxd.auth',
    'Testbed.authadmin',
    'Testbed.testapp',
)

如果相关，请在Fedora上运行Django 1.2.3

正如我所说的，这在以前工作得很好。我强烈怀疑django用户模型默认包含在某个地方

发生了什么事，有人知道吗？一个解决方案是重命名

vxd.auth

，我怀疑这会解决问题

更新各种人的调试建议（顺便说一句，谢谢！）： *是的，我试过放下桌子。我甚至可以通过外壳操纵我的对象，如下所示：

$ python manage.py shell
>>> from vxd.auth.models import *
>>> u = User.objects.get(username="admin")
>>> print u
User object
>>> u.blue
u'baa26f39c47dd222a04aa8123b141e62ef5e0cffa658207b0754f811e6444ab9'
>>>

所以很明显有什么东西潜入了某个地方

编辑：身份验证上下文处理器：

def Authentication(request):
    if AuthenticationCheck(sess=request.session, timeofaction=datetime.datetime.now(), ipaddress=request.META['REMOTE_ADDR']) == True:
        return dict({'username': request.session["username"]})
    else:
        return dict()

身份验证检查代码：

def AuthenticationCheck(sess, timeofaction, ipaddress): 

    try:
        user = sess.get("username", None)
        if user is None:
            return False
        else:
            pass
    except MultiValueDictKeyError:
        # not a session object
        # or no such key exists.
        return False

    # some computations based on sess variables which are set when login happens 
    # these are non-conflicting keys unless sess["vxd-blue"] is used elsewhere...

    # Find "User" from DB.
    print "User is " + user

    #try: # don't catch so I can see the error
    usr = User.objects.get(username=user)    # this throws the exception shown.

导入（contexts.py）：

导入（control.py）：

---

在创建

vxd.auth

之前，是否安装了

contrib.auth

的

syncdb

？看起来您的表结构可能已过时。如果可行，请尝试删除

auth_user

表，然后重新同步，看看这是否解决了问题。

在创建

vxd.auth

之前是否安装了

contrib.auth

？看起来您的表结构可能已过时。如果可行，请尝试删除

auth\u user

表，然后重新同步，看看这是否解决了问题。

我通过将

vxd.auth

重构为

vxd.myauth

来解决问题。django的任何部分在请求

auth_user

时出错，现在都不是了。对名称空间污染没有太大印象，但没关系。

我通过将

vxd.auth

重构为

vxd.myauth

修复了它。django的任何部分在请求

auth_user

时出错，现在都不是了。对名称空间污染没有太大印象，但没关系。

您可以编辑

django

源代码，并在导入

django.contrib.auth.models

时进入

pdb

会话，然后跟踪跟踪，直到找到罪犯。在该文件的顶部弹出以下内容

import pdb; pdb.set_trace()

---

然后，在出现的提示下，键入

tb

。（或者

bt

，我永远记不清是哪个）。

您可以编辑

django

源代码，并在导入

django.contrib.auth.models

时进入

pdb

会话，然后跟踪追踪，直到找到罪犯。在该文件的顶部弹出以下内容

import pdb; pdb.set_trace()

---

然后，在出现的提示下，键入

tb

。（或者，

bt

，我永远记不清是哪个）。

是的，我想这可能是个问题。我有一个脚本，可以删除所有表并用默认数据重新加载它们。愚蠢的是，这种代码实际上是有效的。但是，在我的项目中的某个地方，出现了一些问题……您能粘贴

身份验证

上下文处理器的内容吗？您能粘贴

上下文处理器.py的导入语句吗？似乎它可能在某处导入了错误的
用户
模型。是的，我认为这可能是个问题。我有一个脚本，可以删除所有表并用默认数据重新加载它们。愚蠢的是，这种代码实际上是有效的。但是，在我的项目中的某个地方，出现了一些问题……您能粘贴
身份验证
上下文处理器的内容吗？您能粘贴
上下文处理器.py的导入语句吗？看起来它可能正在导入错误的<代码>用户< /C>模式。显然，我必须等待2天才能接受这一点，所以考虑到Q仍然打开。抱歉，我不能帮助更多——我通过Django源插入您正在导入的模块，而且他们中的任何一个似乎都没有导入<代码>用户< /代码>。显然我必须等待2天才接受这个，所以考虑Q仍然打开。抱歉我不能帮助更多-我拨通了Django源，为您导入的模块，也没有一个似乎是导入<代码>用户< /代码>。我可以给一个去，非常感谢。无论如何，我现在已经重构了，但我会在某个时候还原并尝试一下。我可能会尝试一下，非常感谢。无论如何，我现在已经重构了，但我会在某个时候恢复并尝试。
import pdb; pdb.set_trace()