关于移动应用程序的Django会话 [英] Django session on mobile applications

问题描述

我们目前正在为使用Django构建的网站开发一个移动应用程序(使用离子).每次用户登录时，我们都会在站点上使用django会话.据我了解，django会话会在客户端中设置会话ID，该ID会存储在浏览器的Cookie中.如果移动应用程序与django分开，我们如何在移动应用程序中设置此会话ID?

We are currently developing a mobile application(using ionic) for our site that was built using Django. We used django sessions on the site everytime a user logs in. From what I understand, django session sets the session id in the client that is stored in the cookie of the browser. How can we set this session id in the mobile app, if the mobile app is separate from django?

推荐答案

我至少可以看到三种方法:

I see at least three ways you can approach this:

1. 找到一种方法来使您的离子应用程序与django的cookie(会话和CSRF)配合使用.
2. 通过三种方式更改django应用程序:1)具有向移动应用程序提供身份验证令牌的登录/注销视图，2)扩展SessionMiddleware以从通过身份验证" HTTP标头发送的身份验证令牌中提取会话ID移动应用程序的请求； 3)扩展django的CSRF中间件，以使非来自Web浏览器的请求免于CSRF检查.
3. 尝试使用现有的解决方案向Django添加JWT(Json Web令牌)身份验证.

让基于WebView的混合移动应用程序与android和ios上的cookie一起正常工作似乎并不简单(例如

Getting WebView-based hybrid mobile apps to work properly with cookies on both android and ios seems to be non-trivial (e.g. Handling cookies in PhoneGap/Cordova).

到目前为止，我发现的现有JWT-auth解决方案似乎并未使用Django的会话(为了找到一个统一的解决方案来杀死手机或计算机被盗或被盗的用户会话，我发现它很方便.他们的帐户被黑了).如果有人知道可插拔解决方案在django的常规会话基础上进行令牌认证，请发表评论.

The existing solutions for JWT-auth I found thus far don't seem to use Django's sessions (which I find rather convenient for the sake of having a uniform solution for killing the sessions of users who get their phones/computers stolen or their accounts hacked). If someone knows of a pluggable solution that does token-authentication on top of django's regular sessions, please comment.

详细介绍方法2:

• 当您的移动应用程序不处理Cookie时，由于Django的CSRF检查，它甚至无法登录.这就是为什么来自您的移动应用的请求需要免于CSRF保护的原因.

注意:不不要只是简单地禁用CSRF保护.尽管移动应用程序不容易受到CSRF攻击，但是访问现有网站的人的浏览器仍然可以.

Note: Do NOT simply disable CSRF protection. While the mobile application isn't vulnerable to CSRF attacks, the browsers of people who are visiting the existing website still are.

• 要扩展CSRF机制以免除非浏览器请求，您需要一种有效的方法来确定请求是否来自Web浏览器.我们可以看一堆HTTP标头(例如Referer，Cookie，X-Requested-With，Origin)来了解一个想法.现在，让我们假设您的合法网站用户没有欺骗其标头.

• To extend the CSRF mechanism to exempt non-browser requests, you need an effective way to determine whether a request is coming from a web browser. There's a bunch of HTTP headers (E.g. Referer, Cookie, X-Requested-With, Origin) we can look at to get an idea. Let's assume for now that your legitimate website users don't spoof their headers.

使用与用于CSRF免除的相同"is-web-browser"检查，以保护移动应用程序的登录/注销视图.

Use the same "is-web-browser"-check you used for CSRF-exemption to protect the mobile app's login/logout views.

示例代码(对于Android移动应用程序，来自移动应用程序的iOS标头可能有所不同):

Example Code (for an Android mobile app, iOS headers coming from the mobile app are likely different):

def is_mobile_app_access(request):
    return request.META.get('HTTP_REFERER', None) is None 
        and request.META.get('HTTP_COOKIE', None) is None 
        and request.META.get('HTTP_X_REQUESTED_WITH', None) == 'your.app.name.here' 
        and request.META.get('HTTP_ORIGIN', None) == 'file://'

class CustomCsrfViewMiddleware(CsrfViewMiddleware):
    def process_view(self, request, callback, callback_args, callback_kwargs):
        if is_mobile_app_access(request):
            return None
        else:
            return super(CustomCsrfViewMiddleware, self).process_view(request, callback, callback_args, callback_kwargs)

    def process_response(self, request, response):
        if is_mobile_app_access(request):
            return response
        else:
            return super(CustomCsrfViewMiddleware, self).process_response(request, response)


class CustomSessionMiddleware(SessionMiddleware):
    def process_request(self, request):
        if is_mobile_app_access(request):
            session_key = request.META.get("HTTP_AUTHORIZATION", None)
        else:
            session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME)
        request.session = self.SessionStore(session_key)

如果有人认为这种方法有根本性的错误，请告诉我.我想这种方法中最薄弱的环节是 is_mobile_app_access 检查的可靠性.

If anyone sees something fundamentally wrong with this approach, please let me know. I suppose the weakest link in this approach is how reliable the is_mobile_app_access check is.

您最终做了什么?

这篇关于关于移动应用程序的Django会话的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！