这是一个创建于 2007 天前的主题，其中的信息可能已经有所发展或是发生改变。
GET 参数 params 来获取指定页内容
/api/cont?limit=数量&continue=Base64 加密的 JSON 页数
大家有没有遇到过这样搞分页的，页码数 base64 加密？
 |
1
viakiba 2019-05-25 16:44:06 +08:00 via Android
base64 只能称为编解码 不属于加密
|
 |
2
FrankFang128 2019-05-25 16:44:46 +08:00
这不算奇葩，只能算脱裤子放屁——多此一举。
|
 |
4
imnpc 2019-05-25 16:46:27 +08:00
页数 base64 ？我记得 get 传递 base64 会出问题来着？有些符号会变？
|
 |
5
yahon 2019-05-25 16:46:44 +08:00  1
可以，但没必要。
|
 |
7
zjsxwc 2019-05-25 16:49:16 +08:00
如果 base64 后包含符号 & ? + 等符号时，
你不就凉了 233333 |
 |
8
LancerComet 2019-05-25 16:49:33 +08:00
如果是 JSON 的问题，可以 stringify 之后当字符串传，这种还挺多的
|
 |
9
Elethom 2019-05-25 16:50:58 +08:00
这种后端留着过年？怕不是来搞笑的吧。
|
 |
11
tomczhen 2019-05-25 17:03:49 +08:00 6
为了防止遍历分页还是有把分页编码或者加密的需求的。
base64 中只有 / 和 + 字符，没有 & 和 ？，而且 web 上一般用 url safe base64，所以担心特殊字符的就算了。 |
 |
12
passerbytiny 2019-05-25 17:08:13 +08:00
难道是反爬？
|
 |
14
qshu OP @passerbytiny 反爬好像是有那么点效果的
|
 |
17
Macolor21 2019-05-25 18:11:16 +08:00 via iPhone 4
@qshu
编码就是编码，加密就是加密，不能混淆。那我们的编程语言的也对普通人不可理解，那算加密么？ 另外这种风格我见国外的外部 api 也有用的，一般就是出于各种考虑和妥协的后果，不要见到什么不和自己的理念就吐槽，这种心态不太好。 |
 |
18
hanxiV2EX 2019-05-25 18:25:12 +08:00 via Android
加密 url 参数也不是这样搞的呀，接过 sdk 的都应该知道是给参数加盐后求 sign
|
 |
19
fundon 2019-05-25 18:31:51 +08:00
还不如 POST 数据一把梭
|
 |
20
vevlins 2019-05-25 18:37:34 +08:00
反爬也不能用这种手段啊，太不优美。大佬都给你安排好了你还准备跟他肛一波不成？按照要求写呗
|
 |
21
Vegetable 2019-05-25 20:06:48 +08:00
自以为是吧，不过 base64+urlencode 看起来的确不那么容易直接看出来，但是 f12 看一下，大家都会把 base64 过的字段解出来看一下的。所以这一步只是自己骗自己。
|
 |
22
MonoLogueChi 2019-05-25 20:16:42 +08:00 via Android
base64 没问题啊，jwt 就是 base64 编码的，有那么多人在用，为什么楼上说凉凉之类的。这样用也没什么问题吧，只要能解决需求就好，在 get 参数里做 base64 编码也是很常见的操作
|
 |
23
code2019 2019-05-25 20:20:12 +08:00
不应该是 POST 嘛
|
 |
24
Lax 2019-05-25 20:50:36 +08:00
如果目的是反爬的话，单单把参数放 json 里在 base64 这一种措施真的是没什么用，大佬的方案里是不是还有其它关键参数？
|
 |
25
winglight2016 2019-05-25 21:42:50 +08:00
@code2019 post 没法缓存，不适合列表页面
|
 |
26
kekxv 2019-05-25 22:07:34 +08:00 via Android
也许是祖传的坑，一直没改
|
 |
27
xiangyuecn 2019-05-25 22:33:09 +08:00
@viakiba base64 编码也算是一种加密！不信来一段试试：
5oiR5LiN5L+h5L2g6IO95LiA55y855yL5Ye65oiR5Yqg5a+G55qE5q2k5q615YaF5a65 在不知道解密算法的前提下，要得到明文是很困难的，哈哈😉 ---------------- 此后端分页要求在合理的场景下不算奇葩。也许是增加别有用心的人的利用难度而已，算是低成本高回报；加密算法也许哪天可以不用 base64 了，换成别的，或者算法一天一换。 另一个心里安慰：用户看不到 url 里面的页码。。。看起来蛮高大上😂 |
 |
28
yhxx 2019-05-25 22:41:21 +08:00
类似 "{"start":2}"这种字符串也转 base64
不会因为 url 长度太长出现某些奇怪的问题吗？ |
 |
29
zsdroid 2019-05-25 22:48:53 +08:00
md5 可还行
|
 |
30
an168bang521 2019-05-25 22:52:43 +08:00
感觉这么做可以的，类似网页防用户复制和前端压缩混淆一样，防住一些初级小白和君子就好；
业务上没问题，增加爬取难度就行了， 真想爬你的页面，你再怎么加盐，加 sige，别人大不了直接绕过你那一套，直接拿你页面"下一页"的最终链接，还不是直接爬到； |
 |
31
luopengfei14 2019-05-25 23:19:26 +08:00 via iPhone
@zsdroid md5 不可逆，只能做校验吧 눈_눈
|
 |
32
mooncakejs 2019-05-25 23:23:21 +08:00
关键在于 continue 的内容是前端 encode 的还是后端直接字符串返回的，如果是后者，这就是一个 cursor，前端不应该关心其内容。
|
 |
33
chendy 2019-05-25 23:25:43 +08:00
脱裤子放屁行为
还反爬虫…随便开几个观察一下参数就知道怎么回事了好么… |
|
34
qshu OP @mooncakejs 作为分页的按钮来跳转，每次都需要 encode，跳转的话，翻下一页的话，还是需要自己转
|
 |
36
Youen 2019-05-26 14:22:30 +08:00
和 OData 差不多啊。 编码一下也没啥， 反向代理会过滤一些带特殊字符的 URL
|
 |
37
yanguangs 2019-05-26 15:48:23 +08:00
base64 可不是加密啊
我们的解决方式是 post 方式传 json, 因为之前的项目使用的 mogodb,所以参数是 skip limit,还是很奇怪 |
|
38
qshu OP @xiangyuecn 同理解
|
 |
39
Jiangyf 2019-05-26 16:12:32 +08:00
这边建议加盐再 Base64 处理传给后端呢
|
 |
40
pinews 2019-05-26 17:33:05 +08:00
php:
function urlsafe_base64_encode ($data) { return str_replace(array('+','/','='),array('-','_',''), base64_encode($data)); } |
 |
41
bwangel 2019-05-26 18:26:08 +08:00
base64 中就三个特殊点的字符，+ / =
可以搜索 URL Safe Base64，会将 + / 替换成 - _，同时不再尾部添加=表示补充的字节。 |
Select Language