奇葩的后端分页要求 --后端大佬安排&前端小白实现

[qshu]

GET 参数 params 来获取指定页内容

/api/cont?limit=数量&continue=Base64 加密的 JSON 页数

大家有没有遇到过这样搞分页的，页码数 base64 加密？

[Vegetable]

自以为是吧，不过 base64+urlencode 看起来的确不那么容易直接看出来，但是 f12 看一下，大家都会把 base64 过的字段解出来看一下的。所以这一步只是自己骗自己。

[MonoLogueChi]

base64 没问题啊，jwt 就是 base64 编码的，有那么多人在用，为什么楼上说凉凉之类的。这样用也没什么问题吧，只要能解决需求就好，在 get 参数里做 base64 编码也是很常见的操作

[code2019]

不应该是 POST 嘛

[Lax]

如果目的是反爬的话，单单把参数放 json 里在 base64 这一种措施真的是没什么用，大佬的方案里是不是还有其它关键参数？

[winglight2016]

@code2019 post 没法缓存，不适合列表页面

[kekxv]

也许是祖传的坑，一直没改

[xiangyuecn]

@viakiba base64 编码也算是一种加密！不信来一段试试：

5oiR5LiN5L+h5L2g6IO95LiA55y855yL5Ye65oiR5Yqg5a+G55qE5q2k5q615YaF5a65

在不知道解密算法的前提下，要得到明文是很困难的，哈哈😉

----------------


此后端分页要求在合理的场景下不算奇葩。也许是增加别有用心的人的利用难度而已，算是低成本高回报；加密算法也许哪天可以不用 base64 了，换成别的，或者算法一天一换。

另一个心里安慰：用户看不到 url 里面的页码。。。看起来蛮高大上😂

[yhxx]

类似 "{"start":2}"这种字符串也转 base64

不会因为 url 长度太长出现某些奇怪的问题吗？

[zsdroid]

md5 可还行

[an168bang521]

感觉这么做可以的，类似网页防用户复制和前端压缩混淆一样，防住一些初级小白和君子就好；
业务上没问题，增加爬取难度就行了，
真想爬你的页面，你再怎么加盐，加 sige，别人大不了直接绕过你那一套，直接拿你页面"下一页"的最终链接，还不是直接爬到；

[luopengfei14]

@zsdroid md5 不可逆，只能做校验吧 눈_눈

[mooncakejs]

关键在于 continue 的内容是前端 encode 的还是后端直接字符串返回的，如果是后者，这就是一个 cursor，前端不应该关心其内容。

[chendy]

脱裤子放屁行为
还反爬虫…随便开几个观察一下参数就知道怎么回事了好么…

[qshu]

@mooncakejs 作为分页的按钮来跳转，每次都需要 encode，跳转的话，翻下一页的话，还是需要自己转

[qshu]

@vevlins 有疑问，感觉这么做不大合适，才发出来看看大家意见和建议

[Youen]

和 OData 差不多啊。 编码一下也没啥， 反向代理会过滤一些带特殊字符的 URL

[yanguangs]

base64 可不是加密啊
我们的解决方式是 post 方式传 json,
因为之前的项目使用的 mogodb,所以参数是 skip limit,还是很奇怪

[qshu]

@xiangyuecn 同理解

[Jiangyf]

这边建议加盐再 Base64 处理传给后端呢

[pinews]

php:

function urlsafe_base64_encode ($data) {
return str_replace(array('+','/','='),array('-','_',''), base64_encode($data));
}