WordPress OAuth 1.0认证授权方式测试调研

这两天有新项目需要用到站外登录WP,操作WP网站的数据,之前在一些小项目中,通过Rest API操作网站数据,我都是通过Basic认证的。Basic认证有一个安全方面的缺点,就是每次发送请求,都需要把用户名和密码base64编码到请求的header里。这样就得在站外存储WP网站的用户名密码,如果在站外没有做好安全,不小心泄露这个登录信息,就会造成安全问题。为了规避这种漏洞,我的方式是在WP站内建一个秘密用户,只分配用得到的权限,用户在站外请求我的Rest API,如果要写数据,我用一个中转的节点,加上这个秘密用户的用户名密码组成的header去请求数据。当然,这当中还要加上识别用户的业务逻辑,比如用手机号码做用户字段,这就不另外展开了…

所以我重新考虑OAuth认证方式,谷歌了不少资料,网上大家比较公认的是这一篇:https://code.tutsplus.com/tutorials/wp-rest-api-setting-up-and-using-oauth-10a-authentication–cms-24797
如果你也研究过OAuth和Rest API,你应该也看过这篇文章或者它的翻译版本。

一开始我觉得跟着上面那篇tutsplus上的教程跑一遍就好了,也没必要特意写这篇文章去总结。然而实际操作过程还是踩坑了,所以需要自己记录一下,复盘一下跑通OAuth1.0的过程。本文无代码,都是测试截图。

1. 安装OAuth1.0插件,这是WP团队官方的插件,放心装,地址: https://github.com/WP-API/OAuth1

2. 到WP后台新建一个应用:

复制Client Key和Client Secret

3. 打开Postman,新建一个请求,地址栏填https://www.mysite.com/oauth1/request (此处隐去域名,请只留意路径,后文也是如此)
Type选OAuth1.0,把第二步的两个值复制到对应位置:“Consumer Key”和“Consumer Secret”,勾选“Add params to header”,签名方式选“HMAC-SHA1”,其他不填,自己会生成

发送请求后,获得一串令牌见截图:
oauth_token=vvpD756CGDFR14mSSdVhKBa3&oauth_token_secret=4Da4LssxtKi216n75kLOOTftwgXeNKXA7dOdft8aek2yVywh&oauth_callback_confirmed=true

4. 打开浏览器,访问 https://www.mysite.com/oauth1/authorize? + 上面的令牌值:
https://www.mysite.com/oauth1/authorize?oauth_token=vvpD756CGDFR14mSSdVhKBa3&oauth_token_secret=4Da4LssxtKi216n75kLOOTftwgXeNKXA7dOdft8aek2yVywh&oauth_callback_confirmed=true
就会进入WP的授权登录页面

点击Authorize就登录成功了,会返回一串verification token:

5. 拿着这串verification token回到Postman,再新建一个请求:
请求地址 https://www.mysite.com/oauth1/access?oauth_verifier=UwyJm1ydfT3BcoVkXd9NJokE (注意加上了verification token)
Token填第2步获取的oauth_token,Token Secret填第2步获取的oauth_token_secret
其他也是照旧

请求发送后返回一串新的令牌
oauth_token=l5uWjSKattTqk8ujmoZNL2PX&oauth_token_secret=AmVJ7skCbvK28u805gWTmzyZcULFhkRCwC9FCZruUP7qzKWm
自此登录认证完成。注意这个新的令牌是认证完成后的长期令牌,用于识别用户身份的,后面的请求要把令牌值换成新的令牌。
在WP后台的用户信息里会多出一个Authorized Applications,列出刚刚授权的网站应用:

6. 测试数据,根据Rest API规则发送一个DEL请求删除一篇测试文章
注意要更换令牌了,用上一步获取的值替换Token和Token Secret

测试结果文章删除成功。

自此就通关了OAuth1.0的测试,我踩的一个最大的坑:在发送请求method上,原教程描述和截图都是发送的POST请求,我实测到第2步,无论如何都走不通,一直提示签名错误。后来通过”第六感”改成GET方式就通过了。原教程毕竟是多年前的老文章了,WP又更新了多年,难免留下新坑等着我们去踩。

自此了解了OAuth认证应用场景适用于网站之间的通信,比如我访问A站点时候需要从B站请求和写入B站数据,那么上面的www.mysite.com就得都换成B站域名。不过OAuth有个局限,就是不能把微信小程序充当A站角色,因为在第4步需要出现B站的登录页面,我们在微信小程序里是无法做这样的弹窗的。或许可以通过web-view去强行打开这个页面,但UI方面就格格不入了,这个方案显然不适用。

如果能通过隐式数据通信避免第四部的交互,改成在A站用自定义弹窗的方式授权就好了,但目前我无法做到。试想一下常见的第三方网站接入QQ登录,QQ在这里就充当B站点角色,那个登录页面也是跳转到QQ域名下的,这一步应该无论如何都是无法的跳过的。

这种业务需求可以通过JWT满足,过几天再写一篇文章总结JWT Authentication。

本站所有文章均为原创,欢迎转载,请注明文章出处:https://blog.brain1981.com/2304.html。百度和各类采集站皆不可信,搜索请谨慎鉴别。技术类文章一般都有时效性,本人习惯不定期对自己的博文进行修正和更新,因此请访问出处以查看本文的最新版本。

关注我们的微信公众号-JennyStudio 本站记录了近几年的工作中遇到的一些技术问题和解决过程,“作品集”还收录了本人的大部分作品展示。除了本博客外,我们的工作室网站 – JennyStudio,内有更多作品回顾和展示。
您也可以扫描左边的二维码,关注我们的微信公众号,在微信上查看我们的案例。

发表评论

邮箱地址不会被公开。 必填项已用*标注