我用Python创建了一个Flask-Webservice,该服务在docker容器内独立运行。然后,我将Docker映像上传到Azure容器注册表。从那里,我可以在运行该容器的Azure门户中单击几下创建一个WebService(用于容器)。到目前为止,一切都很好。它的行为就像我想要的那样。
但是,我当然不希望任何人访问该服务。所以我需要某种身份验证。幸运的是(或者我认为)有一个内置的身份验证机制(我认为它是基于OAuth的……我对安全性问题并不精通)。它的documentation对实际发生的情况有点稀疏,并且还专注于C#中的解决方案。
我首先按照here的说明与Google创建了一个项目,然后为WebApp-Authentication配置了Client-Id和Secret。我当然也给Google提供了Java脚本源和callback-url。
当我现在注销我的Google帐户并在浏览器中尝试对Web服务的GET请求(GET应该只返回一个“ hello world” -String)时,我会看到一个登录屏幕...我预料到了。
当我现在再次登录Google时,在参数中包含某些信息后,我将重定向到浏览器中的callback-url。
也许是令牌?看起来像这样:
这里出现了问题,因为出现了错误。
发生错误。
对不起,您要查找的页面当前不可用。 请稍后再试。
如果您是此资源的系统管理员,则应检查错误日志以获取详细信息。
相信你,nginx。
就我现在而言,nginx是托管我的代码的服务器软件。我可以想象它也应该处理身份验证过程。显然,在关闭身份验证后,它可以使所有请求都通过我的代码,但以其他方式阻止未经身份验证的访问,并重定向到google登录名。然后,Google检查您的帐户是否已获得该应用程序的授权,并将您连同访问令牌一起重定向到回调。然后返回一个cookie,该cookie应该授予我的浏览器对该应用程序的访问权限。 (我只是在这里复制文档)。
所以我的问题是:出了什么问题。我的浏览器是否接受cookie。在Google Apps或WebApp中配置身份验证时,我是否出错了?我是否必须使用某个开发堆栈才能使用身份验证。我使用的任何技术(Python,Flask ...)都不支持它。
编辑
@miknik:
在Microsoft的身份验证/授权文档中,
身份验证和授权模块在同一沙箱中运行 作为您的应用程序代码。启用后,每个传入的HTTP 请求通过它,然后由您的应用程序处理 代码。
...
该模块与您的应用程序代码分开运行,并且 使用应用设置进行配置。没有SDK,特定语言或更改 您的应用程序代码是必需的。
因此,虽然您可能对,回调重定向中的信息就是授权授予/代码,并且在此之后现在应该使用此代码来从Google获取访问令牌,但我不太了解在我的情况下工作。
据我所知,Microsoft在Azure上用于容器资源的WebApp应负责自动获取令牌,并将其作为对回调请求的响应的一部分返回。该文档说明了4个步骤:
- 登录用户:将客户端重定向到/.auth/login/。
- 身份验证后:提供程序将客户端重定向到/.auth/login//回调。
- 建立经过身份验证的会话:App Service将经过身份验证的cookie添加到响应中。
- 提供经过身份验证的内容:客户端在后续请求中包含身份验证cookie(由浏览器自动处理)。
在我看来,第2步失败了,而这正是您所写的:授权许可将由服务器用来获取访问令牌,但不是。
但是我对此也没有任何控制权。也许有人可以通过纠正其他一些事情来弄清事情:
首先,我不太清楚问题的哪些部分代表了OAuth方案中的哪个角色。
在OAuth的说明中,我读到有问题的步骤归结为:资源服务器从授权服务器获取访问令牌,并将其传递给客户端。通过使用callback-url进行调用,Azures WebApps资源被提示(并启用)。我在这个地方对吗?
A,我同意我不太了解整个协议。但是我发现网上的大多数描述都没有帮助,因为它们不是特定于Azure的。如果有人知道很好的解释,一般性的或特定于Azure的,请发表评论。
答案 0 :(得分:0)
我找到了一种使之起作用的方法,我尽力尽力解释出了什么问题。如果我输入错误或使用错误的单词,请纠正我。
我怀疑问题不是因为我不了解OAuth(或者至少不是Azure如何管理),而是因为Azure WebApp Service的内部工作原理(加上我的一些不良编程)。 Azure运行自己的服务器,并且未使用flask的内置服务器。实际的问题是我的烧瓶程序没有实现WSGI接口。据我所知,这是python脚本与任何服务器交互的另一个标准。因此,尽管可以从服务器进行基本的调用(我认为Azure使用nginx),但更复杂的调用(如重定向到回调URL的重定向到dev / null)。
我在this tutorial之后构建了一个新应用,然后通过在authentication/authorization-tutorial中进行了保护,一切正常。本教程中的代码实现WSGI,并且可能更符合Azure的期望。我的Docker解决方案太简单了。
我的结论:阅读烧瓶总是警告我的WSGI标准,我没有在开发过程中费心思索的任何代码中监听和实现它。