这是允许通配符搜索用户的正确方法吗？

发布于 2024-12-10 07:00:54 字数 898 浏览 0 评论 0原文

例如，给定一个文本框名称，用户要求能够进行通配符搜索（例如包含、开头为、结尾为）。

只要我仍在后端（Java）中使用参数化查询，是否可以接受 sql 通配符（“%”和“_”）作为输入？实际上，允许用户构建自己的正则表达式，这就是用户的需求。

示例：

用户在
中键入
```
文本框 = '%are%'
```

中输入此参数，如下所示：

公共类 PersonDaoImpl {

        公开列表<人员> search(String name){//name 从带有 sql 通配符的文本框中获取值
        Query q = mgr.createNativeQuery('select * from Person where name like :name'); //默认总是使用like，因为需要带有sql通配符的searchkey    
        q.setParameter('name', name);//给出来自屏幕的输入
        返回 q.getResultList();
        } 
}

结果集将包括名称为“Waren”、“Jared”、“Clare”、“Blare”的人员，正如预期的那样，因为用户提供了正则表达式。

通过 SQL 参数化查询，我可以确保不会允许 SQL 注入。这实现了通配符搜索的用户要求，但也许它违反了我可能错过的任何内容？

更新：刚刚发现 Google 也允许通配符，来自他们的帮助页面。

原文

Given a textbox name for example, the user requirement wants to be able to do a wildcard search (such as contains, starts with, ends with).

Is it ok to accept the sql wildcard characters ('%' and '_') as input as long as I am still using parameterized query in the backend (Java)? Effectively, allowing the user to build his own regular expression which is what the user's requirement is all about.

Example:

User types in the
```
textbox = '%are%'
```

This parameter is feed to the backend as such:

public class PersonDaoImpl {

        public List<Person> search(String name){//name gets the value from textbox w/ sql wildcards
        Query q = mgr.createNativeQuery('select * from Person where name like :name'); //default to always use like since expecting searchkey with sql wildcards    
        q.setParameter('name', name);//gives the input from the screen
        return q.getResultList();
        } 
}

The result set would include people with names 'Waren', 'Jared', 'Clare', 'Blare' as expected since user provided a regular expression.

With the SQL Parameterize Query, I can ensure that I won't be allowing SQL Injection. This implements the user requirement for wildcard search, but perhaps does it violate anything that I may have missed?

UPDATES:
Just found out that Google allows wildcard too, from their help page.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

风轻花落早 2024-12-17 07:00:54

好吧，它违反了用户需要知道（或被告知）如何构造 SQL“LIKE”语法的事实，但仅此而已。这样您可能会得到一个缓慢的查询，因为它通常无法使用索引，但我不会担心安全性或正确性。

回复收藏 0 原文

你在看孤独的风景 2024-12-17 07:00:54

它是“安全的”，但可能不是一个好主意，原因有两个：

要求用户了解 sql 语法可能不是最好的 UI 设计。
对于性能来说，这很糟糕：这些查询通常无法使用您的索引，因此执行速度很慢。它们需要大量的 CPU 时间来比较所有文本，因此它们会给您的服务器增加大量负载（与已经很高的执行时间不成比例）。您需要一个依赖全文索引的解决方案。

回复收藏 0 原文

注定孤独终老 2024-12-17 07:00:54

~~我很好奇，name 参数最终如何在请求中设置？这是什么平台？~~（OP 之前错过了 setParameter）

正如您所指出的，用户需要了解通配符语法，即使用 %、_ 等。更流行的方法是仅从用户名中获取字符串，以及“完全匹配”/“开头为”/“名称中的任意位置”选项。如果您走这条路，您还可以在前两种情况下执行更有效的查询。

编辑：

如果客户坚持 contains 查询，那么我认为您当前的方法是要求最终用户输入模式，然后通过输入 % 将输入字符串转换为模式围绕它。

这是因为用户仍然可以选择不添加（或有选择地添加）% 到搜索字符串，从而加快查询执行速度。例如：

如果用户输入搜索字符串Don，则查询为select ... from ... where name like 'Don'。 RDBMS 很可能会使用名称索引。
如果用户输入搜索字符串Don%，则查询为select ... from ... where name like 'Don%'。 RDBMS 仍然很可能使用名称索引。
如果用户输入搜索字符串 %Don 或 %Don% 则无法使用索引。