使用 django.contrib.auth 限制对 Ajax 服务的访问
在已经使用 django.contrib.auth 进行身份验证的 Web 应用程序中,我正在寻找“标准”方法来限制仅对经过身份验证的用户访问 Ajax 服务。
使用 @login_required 装饰器是行不通的,因为这只会将未经身份验证的用户重定向到登录页面。对于服务,我们可能应该发送一个有效的、格式良好的错误响应——而不是某种登录表单。
这是我想到的第一个方法:
from django.http import HttpResponse
def some_json_service_view(request):
if not request.user.is_authenticated():
return HttpResponse('{success: false}')
return HttpResponse('{success: true}')
更进一步,如果我可以标准化所有“未经身份验证”错误的单个响应,那么装饰器会很好:
from django.http import HttpResponse
def login_required_json(f):
def new_f(request):
if not request.user.is_authenticated():
return HttpResponse('{success: false}')
return f(request)
return new_f
@login_required_json
def some_json_service_view(request):
return HttpResponse('{success: true}')
其他人都是这样做的吗?更容易被接受的方式?理想情况下,有人可以向我指出为此目的制作的 django.contrib 包。
In a web application already using django.contrib.auth
for authentication, I'm looking for the "standard" approach for restricting access to Ajax services to authenticated users only.
Using the @login_required
decorator won't do, because that just redirects unauthenticated users to a login page. For a service, we should probably be sending a valid, well-formed error response back -- not some login form.
This is the first approach that comes to mind:
from django.http import HttpResponse
def some_json_service_view(request):
if not request.user.is_authenticated():
return HttpResponse('{success: false}')
return HttpResponse('{success: true}')
Taking it one step farther, if I could standardize on a single response for all "not authenticated" errors, then a decorator would be nice:
from django.http import HttpResponse
def login_required_json(f):
def new_f(request):
if not request.user.is_authenticated():
return HttpResponse('{success: false}')
return f(request)
return new_f
@login_required_json
def some_json_service_view(request):
return HttpResponse('{success: true}')
Is this how everybody else does it, or is there a more accepted way it's done? Ideally, someone could point me to the django.contrib
package made for this purpose.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果 AJAX 服务仅由前端客户端使用,那么这个示例将非常有效。我一直这样做,因为相同的设计用于通过响应将所有其他类型的数据推送到客户端,客户端需要执行其他操作或以其他方式向用户提供一些反馈。当您的网站有混合用户时(即您同时支持匿名用户和注册用户),它会非常有效。
如果您为第三方供应商构建服务,则必须使用 OAuth、基本 HTTP 访问身份验证或摘要 HTTP 访问身份验证。当您知道/假设执行请求的用户都具有注册凭据时,您可以执行此操作。因此,如果身份验证系统向用户询问凭据,这些身份验证方案允许用户对自己进行身份验证,他们可以立即提供手头的凭据,而无需在重定向的登录页面上手动输入这些凭据。
因此,如果您的服务有混合用户,我会坚持使用您所拥有的服务。否则,您将不得不采取更复杂的措施,即假设未经身份验证的用户已经并且可以立即提供其凭据。
无论哪种情况,我建议您查看 django-piston。它就像一个非常简单的控制器,用于解析 AJAX 请求和序列化 AJAX 响应。根据提供的模型和 HTTP 动词,在向用户代理公开模型访问权限时,它可以自动为您完成许多繁重的工作,此外,它还包含 OAuth 和 HTTP 访问身份验证。
That's an example that will work great if the AJAX services are consumed by your front-end clients only. I do that all the time, because the same design gets used for pushing all other kinds of data to the client through the response for which the client needs to perform additional actions or otherwise provide some feedback to the user. It works great when your site has mixed users, i.e. you support both anonymous and registered users.
If your building services for 3rd party vendors though, you'll either have to use OAuth, basic HTTP access authentication or digest HTTP access authentication. You do this when you know/assume that users who are performing the requests all have registered credentials. Hence, these authentication schemes allow a user to authenticate themselves if the authentication system challenges them for credentials, which they can immediately supply at hand, without manually having to enter them at a redirected login page.
So if your services have mixed users, I'd stick with what you have. Otherwise, you'll have to take up on something more elaborate, something that assumes that unauthenticated users have and can immediately supply their credentials.
In either case, I suggest you take a look at django-piston. It's like a pretty straightforward controller for parsing AJAX requests and serializing AJAX responses. Based on the supplied model and HTTP verb, it can automatically do a lot of the heavy lifting for you when exposing model access to user agents, plus it also comes packed with OAuth and HTTP access authentication.