BraveXaiver

@fsdrw08 #6 公司很大又都是外国人，外国人一般记中间名，就会导致第一个英文单词记不住，搜索中间名的话准确性太差也没个按最后通讯时间排序，不得不去翻邮件确认后再联系。

@fsdrw08 我用 Teams 和人沟通前还得去 outlook 里翻出来人也太麻烦了，就不能在 teams 中单独有一个 Contact tab ，我可以把联系人存进去并分组吗？

@huxins 经常有复制出来后放在邮件和公司内部的通讯软件的聊天输入的需要。。

不过我现在选完，按 ctrl+c 直接出错，错误弹窗中的内容是 this action will not work for multiple selection

@nowaytotalk
@adoal
我试了一下， 没有成功，错误弹窗中的内容是 this action will not work for multiple selection

https://learn.microsoft.com/en-us/office/troubleshoot/excel/command-cannot-be-used-on-selections

@ho121
@xuko

有的时候可能选的是 A, C, F, Z 列。我的问题是一个最简化的场景。

@TimG
@dfkjgklfdjg #6
是的，谢谢，我的显示器是带 KVM 的，typec 接口连笔记本，DP+USBA 连我的台式机。

@cslive hmm 所以你同意， 如果官方在文档中强调一下用户需要对用作列名参数的值做检查（就像 mybatis 那样强调），那么便不存在问题吗？

@qq135449773 #9

这篇后记的语气也真傲慢，或者说双标。

引用其原文：

Mybatis 的${}问题（他们好爱拿这个来举例子）。"外部数据传入 Mybatis ${} 可以造成 SQL 注入" - 这是一个已知的问题(漏洞)。一个应用因为外部不可控参数传入${}并导致 SQL 注入，我们不会去找 Mybatis 给他们提报漏洞（因为对于官方来说，这是一个已知的问题(漏洞)，官方给了足够的说明、警告、风险提醒、适用场景以及替代方案），我们会直接找这个应用去提报漏洞

但是对于 MybatisPlus 来说，几乎没有人知道在使用这个框架的时候要怎么避免 SQL 注入（要不是看了源码，我也不会知道他们什么都不处理就直接做字段拼接），两者根本没有可比性

然而， 至少今天，不需要查看 MP 的源码，MP 的官方文档： https://baomidou.com/reference/about-cve/

已经强调：

该“漏洞”也是前端端传入 SQL 片段 导致 SQL 注入攻击。框架 QueryWrapper UpdateWrapper 字段部分是允许子查询的因此不能人为允许前端传入 SQL 片段。

如果使用者有这种需求，可以使用 SqlInjectionUtils.check(内容) 或 xxWrapper.checkSqlInjection() 方法来检查，如果检查通过，则不会抛出异常。

框架也提供了非常严格的条件构造器 LambdaQueryWrapper LambdaUpdateWrapper 推荐使用。

@leaflxh
@L0L
是的，我也同意这种写法不好。如果开发者这么写了，代码质量分析工具报问题，我没意见。但不应该视作对 mybatis-plus 这个库本身的 CVE issue 。如果视作，那么 mybatis 也应当适用此 CVE issue 。