Django-guardian: ANONYMOUS_USER_NAME无值

创建于 2016-03-09  ·  10评论  ·  资料来源: django-guardian/django-guardian

我错过了什么还是在guardian.conf.settings有这

if ANONYMOUS_USER_NAME is None:
    ANONYMOUS_USER_NAME = 'AnonymousUser'

ANONYMOUS_USER_NAME永远不能等于“无”,从而消除了它应该是可选的事实。 在我看来,这是不希望的。

干杯

最有用的评论

如果我将代码更改为以下内容怎么办? 好点? 如果未指定任何内容,则应设置默认值,并允许将其显式设置为None。

try:
    ANONYMOUS_USER_NAME = settings.ANONYMOUS_USER_NAME
except AttributeError:
    try:
        ANONYMOUS_USER_NAME = settings.ANONYMOUS_DEFAULT_USERNAME_VALUE
        warnings.warn("The ANONYMOUS_DEFAULT_USERNAME_VALUE setting has been renamed to ANONYMOUS_USER_NAME.", DeprecationWarning)
    except AttributeError:
        ANONYMOUS_USER_NAME = "AnonymousUser"

所有10条评论

是的,您是对的,看上去确实很狡猾。 需要一种能够默认为“ AnonymousUser”而又不会阻止将其显式设置为None的方法。

如果我将代码更改为以下内容怎么办? 好点? 如果未指定任何内容,则应设置默认值,并允许将其显式设置为None。

try:
    ANONYMOUS_USER_NAME = settings.ANONYMOUS_USER_NAME
except AttributeError:
    try:
        ANONYMOUS_USER_NAME = settings.ANONYMOUS_DEFAULT_USERNAME_VALUE
        warnings.warn("The ANONYMOUS_DEFAULT_USERNAME_VALUE setting has been renamed to ANONYMOUS_USER_NAME.", DeprecationWarning)
    except AttributeError:
        ANONYMOUS_USER_NAME = "AnonymousUser"

我想说的只是删除我评论的两行。

由于ANONYMOUS_USER_NAME实际上是USERNAME_FIELD ,因此ANONYMOUS_USER_NAME可以是电子邮件,也可以是其他任何值。 因此,默认为"AnonymousUser"具有误导性。 此外, ANONYMOUS_USER_ID正在触发功能, ANONYMOUS_DEFAULT_USERNAME_VALUE作为用户名。 但是现在,它们已经合并为一种设置,可以作为触发条件和价值。 因此,提供默认值毫无意义。

所以我会坚持:

ANONYMOUS_USER_NAME = getattr(settings, 'ANONYMOUS_USER_NAME', None)

if ANONYMOUS_USER_NAME is None:
    ANONYMOUS_USER_NAME = getattr(settings, 'ANONYMOUS_DEFAULT_USERNAME_VALUE', None)
    if ANONYMOUS_USER_NAME is not None:
        warnings.warn("[...]", DeprecationWarning)

并删除上述两行。

我对try...except语法有不同的感觉,因为即使事实不是数字问题,我也从未见过它用于设置。 经典的<SETTING_NAME> = getattr(settings, "<SETTING_NAME>", <default_value>)通常效果很好。

如果我们不提供ANONYMOUS_USER_NAME的默认值,这将破坏现有的应用程序(假定将提供默认值)。 即,我们已更改了未提供ANONYMOUS_USER_NAME设置时的行为。

那么,为什么不提高到1.5.0,删除ANONYMOUS_DEFAULT_USERNAME_VALUE和默认值,并警告有关更改的更改呢?

我相信这样做的目的是允许运行Django Guardian,而无需自动创建匿名用户。 您有一个用例吗? 如果您不想匿名用户,为什么不忽略它呢?

我认为默认情况下创建一个匿名用户是一件好事,我看不出我们为什么要更改此名称的任何原因。 但是,我们确实需要默认值ANONYMOUS_USER_NAME才能起作用。 如果默认值不适合您的应用程序,则可以随时对其进行更改。

try ... except语法很好,因为它可以区分“是否提供此设置?”的情况。 和“此设置是否为空值?” -您也许可以为此使用getattr,但是我发现这可能会很快变得很复杂,特别是如果您想保留DeprecationWarning。 我不确定你的意思是“即使事实不是数字问题”。

我的意思是不是因为每个人都做一件事才是正确/更好的方式。

强制创建匿名用户可能是一种方法,但随后应更新文档。

关于我的情况,我使用电子邮件字段作为默认的USERNAME_FIELD,因此我最初不愿创建匿名用户实例。 但是我可以管理。

干杯。 感谢您让我破产。

伙计们,我真的不认为要求创建匿名用户是个好主意。 我已经使用django-guardian很长时间了,从来不需要匿名用户,所以为什么现在要更改它?

因此,我的涉及try ... except解决方案获得了2个大拇指,但是在证明该解决方案合理的地方,我给出了2个大拇指。 令人困惑。 由于我确实看不到任何缺点,并且我相信这是解决回归问题而不添加新回归问题的最简单方法,因此我将应用此解决方案。

@brianmay抱歉让您感到困惑。 :+1:不过,修复!

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

Dzejkob picture Dzejkob  ·  28评论

johnthagen picture johnthagen  ·  9评论

xuhcc picture xuhcc  ·  10评论

ad-m picture ad-m  ·  13评论

lukaszb picture lukaszb  ·  14评论