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,会将 + / 替换成 - _,同时不再尾部添加=表示补充的字节。 |