嘿，伙计们！想象一下，你辛辛苦苦开发了一个超酷的API，比如一个“全球珍稀猫咪图片库”，你希望只有注册用户才能看，VIP用户还能上传新猫片。这时候，你就像一个派对的主人，不能随便让陌生人混进来把蛋糕都吃光吧？
这时候，你就需要一套强大的认证（Authentication） 和权限（Authorization） 系统。别被这两个词吓到，咱们说人话：
- 认证： 是回答“你是谁？” 这个问题。就像进小区，保安大哥看你一眼，你刷个脸或者出示门禁卡，证明你是业主。在API里，这就是用户提供用户名密码或者其他凭证（比如一个令牌）的过程。
- 权限： 是回答“你能干什么？” 这个问题。你虽然是业主，但你能随便进别人家吗？不能！你可能只能进自己家（访问自己的数据），而物业经理（管理员）则能进所有公共区域。在API里，这就是判断一个已经认证的用户是否有权执行某个操作（查看、修改、删除）的规则。
今天，咱们就深度扒一扒Django，特别是它的黄金搭档——Django REST Framework（后文简称DRF），是怎么通过API来实现这套酷炫的“安保系统”的。
第一幕：Django自带的“安保大队”
Django本身自带了一套非常成熟的认证系统，就在 django.contrib.auth 这个包里。它默认用的是 Session（会话） 认证。
这玩意儿是怎么工作的呢？打个比方：
- 你第一次去一家高级俱乐部（访问网站），前台（服务器）不认识你。
- 你出示身份证和会员卡（输入用户名密码登录），前台核实后，给你一个独一无二的手环（Session ID）。
- 接下来你在俱乐部里的所有消费（发送请求），只需要亮出这个手环，服务员就知道你是已经验证过的客人，无需反复出示身份证。
- 这个手环在你离开俱乐部（关闭浏览器）后就失效了。
在Web页面里，这个“手环”是通过Cookie自动携带的，非常方便。但当我们搞API，尤其是给手机APP或者前后端分离的架构用时，这套机制就有点“水土不服”了。因为APP可不会像浏览器那样乖巧地管理Cookie。
第二幕：API时代的“接头暗号”——Token认证
为了让各种客户端（iOS, Android, 小程序等）都能方便地和我们的Django后端“对话”，我们需要一种更通用、更简单的“暗号”。这就是 Token（令牌） 认证。
Token认证的工作流程，像极了特工接头：
- 首次接头（登录）： 特工（客户端）来到秘密据点，说出暗语“天王盖地虎”（用户名和密码）。
- 核发令牌（服务器响应）： 总部（服务器）核实暗语正确后，交给他一个一次性的、有时效的密令令牌（Token），并说：“拿好这个，下次亮出它就行。”
- 执行任务（访问API）： 特工去执行下一个任务（访问需要认证的API），他不再需要说复杂的暗语，只需要在请求头里亮出这个令牌。
- 验明正身（服务器验证）： 每个关卡的守卫（服务器）看到这个有效的令牌，就知道是“自己人”，放行通过。
这种方式无状态
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
