Code cleanup & refactoring.

[mingyoung]

优化开放平台代码
API 名称大幅修改，所以不兼容以前API写法。

预授权简化：

// BEFORE
$openPlatform->pre_auth
    ->setRedirectUri('https://domain.com/callback')
    ->getAuthLink();

// AFTER
// 直接跳转
$response = $openPlatform->pre_auth->redirect('https://domain.com/callback');
// 获取跳转的链接
$response->getTargetUrl();

OpenPlatform.php 增加 __call 魔术方法快速访问 BaseApi 中的方法：

// BEFORE
$openPlatform->authorizer->getAuthorizationInfo();
// AFTER
$openPlatform->getAuthorizationInfo();

微信推送授权事件后不缓存 authorizer_access_token 和 authorizer_refresh_token，因为SDK处理后再次获取授权信息的话容易造成 Token 失效的问题。当调用授权方 API 会缓存并自动刷新 Token。

简化调用授权方 API：

// BEFORE
$app = new Application($options);
$app->access_token = $app->open_platform->authorizer_token;
$authorizerAppId = $authorizer->app_id;
$app->open_platform->authorization->setAuthorizerAppId($authorizerAppId);

// AFTER
$app = $openPlatform->createAuthorizerApplication('authorizerAppid', 'authorizerRefreshToken');
// 然后调用方法和普通调用一致。
// ...

[mingyoung]

@tsunamilx how about it?😄

[overtrue]

Daemon 是什么？

[mingyoung]

@overtrue 主要是授权方APPID，TOKEN的 Setter 和 Getter 吧

[overtrue]

@mingyoung 感觉用词不对，daemon 一般是守护进程

[overtrue]

https://scrutinizer-ci.com/g/overtrue/wechat/inspections/36f0b4c2-dbcc-474e-95e6-8a8a32fe340f/issues/files/src/OpenPlatform/OpenPlatform.php?status=new&orderField=path&order=asc&honorSelectedPaths=0

[mingyoung]

I'll fix this later.

[overtrue]

@mingyoung 👍

[tsunamilx]

代码改动很大，没有太多时间去理解。不过有几个疑问：

微信推送授权事件后不缓存 authorizer_access_token 和 authorizer_refresh_token，因为SDK处理后再次获取授权信息的话容易造成 Token 失效的问题。当调用授权方 API 会缓存并自动刷新 Token。

这里不理解 Token 为何会失效，Token 没有自动刷新吗？再次授权的话不就是覆盖原来的 Token 了吗，怎么会失效？

// AFTER
$app = $openPlatform->createAuthorizerApplication('authorizerAppid', 'authorizerRefreshToken');

那么开发者是要手动处理 authorizer_refresh_token 了？之后为了刷新 authorizer_access_token 开发者都要手动带上 authorizer_refresh_token ？ 我认为这里可以自动处理掉的，是有什么考虑不做吗？

[mingyoung]

如果开发者在回调页面中根据 auth_code 获取授权信息的话那就有冲突了

[mingyoung]

authorizer_refresh_token 应该都要保存到自己的数据库吧，如果交给缓存来处理，那清空缓存不就都没了？ @tsunamilx

[tsunamilx]

在回调页面中根据 auth_code 获取授权信息的话那就有冲突了

我这边没出现过这样的情况。通过 auth_code 是重新获取这两个 token 了对吗？照理应该是覆盖了原来缓存的 token，之后应该会使用新的 token，不觉得会冲突。我理解有误？

authorizer_refresh_token 应该都要保存到自己的数据库吧，如果交给缓存来处理，那清空缓存不就都没了？

这个同意，不过感觉清空缓存的可能性不大，那 component_verify_ticket 是不是也要拿出来自行处理。

[mingyoung]

授权事件推送了，然后 SDK 获取 token A 并缓存。

开发者在回调页面根据 auth_code 调用 $openPlatform->getAuthrizationInfo('auth_code)（这个方法没有重新写缓存） 再次获取了 token B。

那 token A 失效了，但是还在缓存 token A。

这个同意，不过感觉清空缓存的可能性不大，那 component_verify_ticket 是不是也要拿出来自行处理。

就算清空缓存了，component_verify_ticket 可以等10分钟微信推送过来，authorizer_refresh_token
就要重新用户授权才有了。

[tsunamilx]

开发者在回调页面根据 auth_code 调用 $openPlatform->getAuthrizationInfo('auth_code)（这个方法没有重新写缓存） 再次获取了 token B。

额，这我觉得应该是开发员的责任了吧，原来的 Authorization 类里有 handleAuthorization 方法，这里是获取并且缓存的。应该调用这个方法的。

就算清空缓存了，component_verify_ticket 可以等10分钟微信推送过来，authorizer_refresh_token
就要重新用户授权才有了。

见仁见智吧。正式环境中，清空缓存应该是不会发生的，如果发生了，10分钟不可用也是很严重的问题。另外 component_verify_ticket 是被动的，只能等微信推过来，急死人。。。authorizer_refresh_token 的话叫客户主动重新授权，可以很快解决，不过客户多的话也是挺要命的。。。所以清空缓存更加是不太可能了。

[mingyoung]

所以要减少踩坑的机会。还有我觉得不应该重新包装微信返回的内容，再返回给开发者。
根据自己的需求调用相应的API就好，SDK不做太多事：）