You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Andres de la Peña (Jira)" <ji...@apache.org> on 2022/11/04 14:03:00 UTC
[jira] [Comment Edited] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629002#comment-17629002 ]
Andres de la Peña edited comment on CASSANDRA-17967 at 11/4/22 2:02 PM:
------------------------------------------------------------------------
[Here|https://github.com/apache/cassandra/compare/trunk...adelapena:17967-trunk] is a draft patch that:
# [Here|https://github.com/adelapena/cassandra/commit/3354f1339fc3f75cdcadd8f654a5ce2ffd441cf4] it adds a brief reason of AF is pernicious to the documentation of the {{allow_filtering_enabled}} property in {{{}cassandra.yaml{}}}:
{code:java}
# Guardrail to allow/disallow querying with ALLOW FILTERING. Defaults to true.
# ALLOW FILTERING can potentially visit all the data in the table and have unpredictable performance.
# allow_filtering_enabled: true{code}
I guess that any user finding the guardrail violation error would land there, so it seems a good place to document the reason for disabling it. We should probably add similar reasons for all other guardrails and guardrail-like properties.
# [Here|https://github.com/adelapena/cassandra/commit/852afe334318b86483a916c6533c876a486c3045] it adds a "reason" optional string attribute to every guardrail, so it's printed right after the guardrail violation error message. For the AF guardrail the full message is:
{code:java}
> SELECT * FROM k.t WHERE v = 2 ALLOW FILTERING;
Guardrail allow_filtering violated: Querying with ALLOW FILTERING is not allowed. ALLOW FILTERING can potentially visit all the data in the table and have unpredictable performance.{code}
Other guardrails don't use this "reason" property, but we should probably start using them.
# [Here|https://github.com/adelapena/cassandra/commit/b8ebb7bbfc6f8c9c3247bca70a887f52c64e503f] it makes the message for missing AF depend on whether the guardrail is enabled or not. So if a query without AF requires filtering it prints exactly the same message as before, which is:
{code:java}
> SELECT * FROM k.t WHERE v = 0;
Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING{code}
But if the guardrail is disabling AF, the message is
{code:java}
> SELECT * FROM k.t WHERE v = 0;
Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. Executing this query despite the performance unpredictability with ALLOW FILTERING has been disabled by the allow_filtering_enabled property in cassandra.yaml{code}
The commit is a bit noisy due to the need to make the {{ClientState}} available to {{{}StatementRestrictions{}}}.
was (Author: adelapena):
[Here|https://github.com/apache/cassandra/compare/trunk...adelapena:17967-trunk] is a draft patch.
# [Here|https://github.com/adelapena/cassandra/commit/3354f1339fc3f75cdcadd8f654a5ce2ffd441cf4] it adds a brief reason of AF is pernicious to the documentation of the {{allow_filtering_enabled}} property in {{cassandra.yaml}}:
{code:java}
# Guardrail to allow/disallow querying with ALLOW FILTERING. Defaults to true.
# ALLOW FILTERING can potentially visit all the data in the table and have unpredictable performance.
# allow_filtering_enabled: true{code}
I guess that any user finding the guardrail violation error would land there, so it seems a good place to document the reason for disabling it. We should probably add similar reasons for all other guardrails and guardrail-like properties.
# [Here|https://github.com/adelapena/cassandra/commit/852afe334318b86483a916c6533c876a486c3045] it adds a "reason" optional string attribute to every guardrail, so it's printed right after the guardrail violation error message. For the AF guardrail the full message is:
{code:java}
> SELECT * FROM k.t WHERE v = 2 ALLOW FILTERING;
Guardrail allow_filtering violated: Querying with ALLOW FILTERING is not allowed. ALLOW FILTERING can potentially visit all the data in the table and have unpredictable performance.{code}
Other guardrails don't use this "reason" property, but we should probably start using them.
# [Here|https://github.com/adelapena/cassandra/commit/b8ebb7bbfc6f8c9c3247bca70a887f52c64e503f] it makes the message for missing AF depend on whether the guardrail is enabled or not. So if a query without AF requires filtering it prints exactly the same message as before, which is:
{code:java}
> SELECT * FROM k.t WHERE v = 0;
Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING{code}
But if the guardrail is disabling AF, the message is
{code:java}
> SELECT * FROM k.t WHERE v = 0;
Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. Executing this query despite the performance unpredictability with ALLOW FILTERING has been disabled by the allow_filtering_enabled property in cassandra.yaml{code}
The commit is a bit noisy due to the need to make the {{ClientState}} available to {{{}StatementRestrictions{}}}.
> Guardrail: allow_filtering_custom_error_message
> -----------------------------------------------
>
> Key: CASSANDRA-17967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
> Reporter: Sarma Pydipally
> Priority: Normal
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT commands. Users get following error message :
> <stdin>:1:InvalidRequest: Error from server: code=2200 [Invalid query] message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is not allowed"
> I propose for a new parameter in conf file : something like : allow_filtering_custom_error_message and allow cluster operators to configure custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering as well as give them to configure a custom error message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org