2014-06-10 54 views
2

我在我傻的练习应用程序中使用Flask-OpenID进行用户登录。如何将Flask-OpenID对象设置为全局应用程序?

做创建OpenID的对象,这就是后来被用来装饰的登录处理(和其他东西)的第一件事:

oid = flask.ext.openid.OpenID(app, '/path/to/store') 

@oid.loginhandler 
def login(): 
    ... 

@oid.after_login 
def after_login(): 
    ... 

不过,我想在我的应用程序的__init__.py文件初始化烧瓶的OpenID但在其他文件中使用OpenId对象oid,例如我的应用的views.py文件和其他文件。预期的方式是什么?烧瓶开发人员通常如何在应用程序中创建全局的oid

this similar question,在SQLAlchemy的对象移动到models模块,但应用程序的安装,这是有道理的,因为db对象被耦合到模型中初始化其他地方。 OpenID对象遵循相同的模式。但我不想把oid放在views.py;它显然不属于那里。那么你会把它放在哪里?我可以想到解决方案,但我想知道开发者通常会做什么。这里有一些想法:

  • oid__init__.py并初始化它有作为。在这个选项中,你如何在应用模块的另一部分访问oid

  • 为与Flask-OpenID和Flask-Login关联的对象和方法创建一个auth.py文件。然后auth.oid可以在应用程序的任何地方工作。然后,我是否每扩展名创建的新文件,而不是直接耦合到其他地方? 这是矫枉过正,还是放大和保持组织的正确模式?

  • 或者,为所有这些小扩展对象创建一个文件,可能是globals.pyexts.py。这看起来很尴尬和笨拙。 或者大多数瓶子应用程序最终都有一个随机存储桶,用于所有这些只需要位于某处的其他垃圾?

+0

重复使用Flask-SQLAlchemy,而不是Flask-OpenID,但模式是相同的。让我知道,如果它不回答你的问题! :-) –

+0

@SeanVieira答案似乎是将Flask-SQLAlchemy对象放在另一个模块中,幸运的是一个它开心所属的模块已经存在。在我的情况下,没有这样的模块已经存在。我已经扩展了我的问题,以清楚尚未解决的问题。 – jmilloy

回答

1

三个选项有不同的权衡(如你发现):

  1. 创建__init__.pyauth - 这会导致你的意见,你的基础的应用程序之间循环引用 - 它可以工作,但它使分化更加困难(因为移动两个不相关的进口可能导致错误)。
  2. 创建一个单独的模块来处理单独的问题 - 这避免了循环引用问题,并增加了大型项目的清晰度(“啊,这里是处理验证的代码所属的地方)”。另一方面,有几个小扩展的小项目可能会发生类似Java的模块爆炸。
  3. 创建一个单独的模块来初始化应用程序中使用的所有Flask扩展。这也避免了循环引用问题,并且使小项目不必要地乘模块。但是,在大型项目中,这样的模块会变成一大块泥巴。 (“这是配置认证,平面文件处理和错误处理的地方”)。

还有一个第四选项 - 添加auth到您的视图层,如如何进行身份验证是特定于应用程序逻辑(而不是你的域模型,例如)。

我建议完全避免#1(跳过“两个模块”阶段直接进入“三个或更多个模块阶段”的额外成本可以忽略不计)。剩下的三个选项中哪一个适合您的项目对于项目和开发人员是非常特定的。

相关问题