Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wildcards "%" and "_" can be used on partial searches #35

Closed
pcarana opened this issue Jul 4, 2017 · 1 comment
Closed

Wildcards "%" and "_" can be used on partial searches #35

pcarana opened this issue Jul 4, 2017 · 1 comment
Labels
Milestone

Comments

@pcarana
Copy link
Contributor

pcarana commented Jul 4, 2017

When a partial search is made using the only wildcard allowed "*", I still can use other wildcards to get more information in the response. Here are some cases assuming that the minimum of characters allowed for the search is 5:
"/domains?name=%%a%*" will search for all the domains that have the char 'a' in their names.
"/domains?name=__e_*" will search for all the domains that the 3rd char of its name is the char 'e' followed by at least another char.

The use of this wildcards is valid when I have a MySQL or Oracle DB (just to say a few databases) as my data repository. To avoid this behavior I propose this update on the server code "mx.nic.rdap.server.RdapSearchRequest" line 80:

default:
	searchReq.type = RequestSearchType.PARTIAL_SEARCH;
	// Escape special characters to avoid its use as wildcards
	if (searchReq.getParameterValue().contains("*")) {
		searchReq.setParameterValue(searchReq.getParameterValue().replaceAll("(\\%|\\_)", "\\\\$1"));
	}
	break;

The purpose of the code is to escape the wildcards if the search is to be made using the sentence "LIKE" in the implementation, which I think is the most probable case.

@pcarana
Copy link
Contributor Author

pcarana commented Jul 7, 2017

The purpose of the code is to escape the wildcards if the search is to be made using the sentence "LIKE" in the implementation, which I think is the most probable case.

This issue left me thinking: the server shouldn't be responsible to escape this characters, this should be a task of the implementation. The implementation should identify which are special characters in order to take action (escape them, ignore them,...).

Closing the issue and reporting at rdap-sql-provider...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant