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

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

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

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

第二个方式

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

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

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

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

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

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

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

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

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

@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 处理

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

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

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

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

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

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

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

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

@jake666 @overtrue

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

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

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

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

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

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