请教关于微信授权 redirect_url 配置问题

现在开发越来越多使用前后端分离,后端单纯提供接口,那么对于微信授权的 redirect_url 来说网上也有两种做法:

  1. redirect_url 设置前端的url,前端拿到 code ,然后将 code 传入到后端 ,后端去连接微信服务器拿到 openid 进行登录,返回 token 到前端。(目前也是使用这种)
  2. redirect_url 设置后端的url (含有一个前端需要最终重定向的 return_url参数 ), 那么后端直接拿到 code,后端去连接微信服务器拿到 openid 进行登录,然后携带 token 参数并重定向到 return_url 上,前端取得token。

所以想和各位大佬商讨一下这两种做法。

《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 19
你看我吊吗啊

你想讨论哪个点?个人觉得第二种更方便呢

4年前 评论

我们用的是第二种方式,前端完全不用关心具体的业务逻辑,全部由后端进行处理。

但是我不明白为什么你要把 token 传到前端,理论上 token 这种数据前端不需要关注。

4年前 评论

第二个方式

4年前 评论

提出第一种写法的不配称之为 工程师,这种需求肯定是纯后端交互处理好,再 redirect 到相应业务页面

4年前 评论

@24K大白羊 token 不传到前端,怎么保持前端登录状态呢,还有后面很多接口需要这个 token

4年前 评论
24K大白羊 4年前

@Hachiko 第一种写法是居多的,因为是前后端分离的,网上大部分教程都是这样的做法。L03 Laravel 教程 - 实战构架 API 服务器 ( Laravel 5.8) 也是这种做法

4年前 评论
leo

在我的实践中选择的是方案一,理由如下:

  1. 方案二只能通过 Get 参数或者 Url Hash 的方式将 token 返回给前端,我们使用的 Laravel Passport 生成的 Token 又很长,个别浏览器的不支持那么长的 Url;
  2. 我们的后端 Api 是多个前端站点公用的,微信授权之后 Api 并不知道应该往哪个前端站点跳转(因为是真·API 没有 Session 的)。
4年前 评论

@leo 第二种方案可能我还需要再解释一下,前端传递一个 url 过来,后端最终需要重定向到这个 url 上,微信跳转这边都是统一跳转到后端的 api 上

4年前 评论

@Hachiko 肯定首选第一种
现在基本都是前后端分离的,都不是同一个域名,后端怎么 用户信息调转,api 无法存用户信息

4年前 评论

@gyp719 是不是同一个域名没关系的,api是无法存储用户信息什么意思,最终是将token返回到前端

4年前 评论
leo

@jake666 如果后端是纯 API 无状态的,那么前端把自己的回调 Url 传给后端之后,后端把这个 Url 存在哪里?后端跳转到微信登录页面之后这个信息就丢失了吧。

4年前 评论

@leo return_url 带到 redirect_url 中,差不多是这样的

https://open.weixin.qq.com/connect/oauth2/authorize?appid=XXXX&http://xxxx.com/passport/weixin/callback?return_url=http://xxx.com/login&response_type=code&scope=snsapi_userinfo&state=rQ0WabuZniLF2rSXlBD4ORUqrF8TUrY2EFH72tko&connect_redirect=1#wechat_redirect

做好相应的 url_encode 处理

4年前 评论
leo

@jake666 对于微信可以这么做,但是有些其他的 OAuth 登录会要求不能在回调 Url 里加入 Get 参数,这种情况下你的方案就不适用了。

4年前 评论

@leo 你说的也是对的,估计会存在回调 redirect_url 不允许追加任何参数,这时候 state 参数就发挥作用了,可以生成唯一 id ,放到 state 参数,然后将 id => returl_url 存入到 redis 中,redirect_url 返回的时候是携带 state 的,就可以取到 returl_url 了,

所以大佬的意思,还是第一种喽 :wink:

4年前 评论

我用的第一种,@Hachiko 我是一名不合格的工程师 :joy:

4年前 评论

@overtrue 那我也做一个不合格的 工程师 吧 :see_no_evil:

4年前 评论

:joy: 这么多人不合格,见笑了,不合格的判断根据是:

  • 项目是前后端分离,但是是维护了会话(状态),也就是上面 说的无状态 API 需做另外考虑
  • 如果 SPA 做(第一种方案),会频繁需要把参数发给后端处理,一共需要3、4步,为了简化逻辑,还不如接入后端路由,在后端把逻辑做好再进入 SPA 页面,减少接口交互量

做了前后端分离,并非所有的事情都要前端来做。像一个页面渲染,需要调用五六个接口的童鞋,就不是合格的工程师(应该打死) :see_no_evil:

@jake666 @overtrue

4年前 评论

@Hachiko 我在上楼中,一会儿自杀。 :sob:

项目是前后端分离,但是是维护了会话(状态),也就是上面 说的无状态 API 需做另外考虑

前后端分离就不要后端维护啥会话了,直接 token 传递解决

如果 SPA 做(第一种方案),会频繁需要把参数发给后端处理,一共需要 3、4 步,为了简化逻辑,还不如接入后端路由,在后端把逻辑做好再进入 SPA 页面,减少接口交互量

并没有频繁把参数发给后端,登录操作本身就是低频的,并且也不需要 3-4 步,前端没登录就直接请求后端拿 redirect_url 跳转,回调回来的时候将 query 透传到后端的 callback 接口,后端处理完用户信息反返回 token 前端存起来即可,在过期前根本不需要再走如上这两流程,这是非常简单且成熟的做法。所以:“频繁需要把参数发给后端” 和 “减少接口交互量”并不存在。

4年前 评论

我用的也是第一种 :joy: :joy:

4年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!