Oauth跳转地址参数及默认跳转页面code解析问题

[HansBug]

您好，这边经过简单的测试，发现在使用Oauth进行页面登陆后，跳转的地址使用#而非?分隔编码后的参数和URL路径（也就是说，参数会以fragment而非parameters的形式存在），例如：

https://oauth.cnblogs.com/auth/callback#code=210dd1ae7584ca228f3d2a84d6d557a83af96fe871e15aadf46180b3933c57a2&id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjlFMjcyMkFGM0IzRTFDNzU5RTI3NEFBRDI5NDFBNzg1MDlCMDc2RDAiLCJ0eXAiOiJKV1QiLCJ4NXQiOiJuaWNpcnpzLUhIV2VKMHF0S1VHbmhRbXdkdEEifQ.eyJuYmYiOjE1OTM1NjYzNjYsImV4cCI6MTU5MzU2NjY2NiwiaXNzIjoiaHR0cDovL29wZW5hcGlfb2F1dGgtc2VydmVyIiwiYXVkIjoiZjJhMWEwM2QtM2RiNy00MTU1LTg0M2ItYWNjYzlmY2FmY2RkIiwibm9uY2UiOiI2WUdWVDdZRzBNSzdCS1gyIiwiaWF0IjoxNTkzNTY2MzY2LCJjX2hhc2giOiJFcnZOYTM2Qng2UTk4RjRLbVNyMmdBIiwic2lkIjoiMTVjNjgyODYzMzVlOWFkZWM0NjRlNjAxMzhlNDYyMDUiLCJzdWIiOiIwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAiLCJhdXRoX3RpbWUiOjE1OTM1MDgwOTgsImlkcCI6ImNuYmxvZ3Nfb2F1dGgiLCJhbXIiOlsiYXV0aG9yaXphdGlvbl9jb2RlIl19.QmE-ptQwpVhghUAmlgv3qFI4909RzqtOOSUZISebZ39v8wHpKNVWicowLdAVCt81B2EgS62A9O9vQxh8GrSL7I4aGc1gy6FP0XJ8Vx6DqVMx9Drg3R41wokJOanUUattLdAVKpQpgO3W80R-MC5_ZFN9XBS_YgCMSNMacgp4tddXlJxZULaixt7HDiieubAgHrwmrMF9nTfHnpddj1dnTOyNCjbukOBf9B7VzR1Qc31sKHjH03gAJeHhrXU58lW1h6oNRnZSHMGSvP3k8IybP9qI1Mvg-p1Qn-DaF81fr2n_ShKKZlLaTc4zYiulQKOlXZuQJbsLegT4FcUeit4F-A&scope=openid%20profile%20CnBlogsApi&state=LRNVJGMXIVZ0GCRA&session_state=vDJ3A55GTlsPdDP0P1jMsg5E025QQXTn27A8mQoi19U.ff01605d589d3938e962959c2403173a

在更换过redirect_uri后，也一样出现了类似的问题，分隔的符号为#而不是?。这将导致在真正用于redirect到用户自己的地址时，由于code、state等数值性质为fragment，所以无法通过parameter进行后端数据解析（实际上可能根本都无法传到后端，毕竟锚点本身就是作用于前端，用于定位的），从而导致数据丢失。

此外，在默认的跳转页面上，js对code的解析代码为

var url = window.location.href;
var codeElement = document.getElementById("code");
if (url.indexOf("code") > 0) {
    var strart_index = url.indexOf("=");
    var end_index = url.indexOf("&");
    var code_value = url.slice(strart_index + 1, end_index);
    codeElement.innerHTML = code_value;
} else {
    codeElement.innerHTML = "不好意思,授权码走丢了....."
}
$.post("/Users/SignOut");

该部分的解析思路完全基于对=和&符号的定位，没有进行URL结构拆分，没有参考code字符串的位置，对于拆出来的内容也没有进行url解码。目前Oauth默认跳转页面上暂时显示正常是因为code参数常常处于第一个参数位置且字符串内容较为简单，这实际上有可能出现很多的状况，包括但不限于：

• 有且仅有code一个参数（&将无法找到，code解析错误）
• code参数并非位于第一个参数位（code解析结果将是第一个参数的值）
• code参数包含复杂内容（没有进行URL解码）

希望以上问题可以尽快得到回应并修复，非常感谢

[cnblogs-team]

您好，这个问题应该与 response_type 有关，如果 response_type 用的是 code id_token ，麻烦您改为 code 试试。

[HansBug]

您好，response_type改为code后，页面出错，返回信息为

{"type":"https://tools.ietf.org/html/rfc7231#section-6.6.1","title":"unauthorized_client","status":500,"traceId":"|7958343c-47d50341e264cc05."}

[cnblogs-team]

您好，我们改进了 api ，现在可以通过 response_mode="form_post" 解决，示例 python 代码如下：

u = URLObject("https://oauth.cnblogs.com/connect/authorize").add_query_params(
    client_id=CLIENT_ID,
    scope="openid profile CnBlogsApi",
    response_type="code id_token",
    redirect_uri=REDIRECT_TARGET,
    state="this is state string",
    nonce=random_str(16),
    response_mode="form_post"
)

# ...

pre = chrome.find_element_by_tag_name("pre").text
data = json.loads(pre)
print(data)
print("code: " + data["code"])

[HansBug]

您好，该部分我会进行后续尝试。

不过先基于提供的demo代码，对这波改建提几点想法：

• 目前的api中，response_type和response_mode并存，这部分建议在设计上统一起来，现在这种定位和含义高度重合的设计容易带来不必要的混乱。
• 实际上，在原本的交互模式中，如果用的是默认的redirect_uri，那么可以通过find_element_by_id直接获取code（实测对于部分浏览器，最多也只是需要轮询判定下而已，不复杂），然而form_post这样的设计，按照上述代码的描述，实际上并未真正改变原有工作模式（具体来说，原有的坑点一个都没避开）
• 实际上，如果想要实实在在方便纯api用户的话，可以考虑开设非callback型oauth，直接返回json数据（个人的一点建议，轻喷），当然，这也是个折中解，对于纯api用户最方便的大概还是个人id/secret模式

[cnblogs-team]

您好，谢谢您的建议，我们会进行改进。