codeant-ai-for-open-source[bot] commented on code in PR #41965:
URL: https://github.com/apache/superset/pull/41965#discussion_r3564775344
##########
tests/unit_tests/security/api_test.py:
##########
@@ -66,6 +66,50 @@ def test_csrf_exempt_blueprints_with_api_key(app: Any,
app_context: None) -> Non
assert "ApiKeyApi" in {blueprint.name for blueprint in
csrf._exempt_blueprints}
+def test_security_api_trailing_slash_handled_consistently(client: Any) -> None:
+ """Regression for #29934: sibling ``/api/v1/security/*`` endpoints handle a
+ misspelled (wrong trailing-slash) URL inconsistently.
+
+ Three routes live under the same ``/api/v1/security/`` prefix but are
+ declared with different slash conventions:
+
+ * ``login`` -> ``@expose("/login")`` (no trailing slash,
FAB)
+ * ``csrf_token`` -> ``@expose("/csrf_token/")`` (trailing slash,
Superset)
+ * ``guest_token`` -> ``@expose("/guest_token/")`` (trailing slash,
Superset)
+
+ Because of that mix, a client that gets the slash "wrong" is treated three
+ different ways by Werkzeug routing:
+
+ * ``POST /api/v1/security/login/`` -> 404 (no redirect for the extra
slash)
+ * ``GET /api/v1/security/csrf_token`` -> 308 redirect to the canonical
URL
+ * ``POST /api/v1/security/guest_token`` -> 308 redirect to the canonical
URL
+
+ A user hitting one misspelled security URL gets a clean redirect while
+ another gets a hard 404, which is exactly the inconsistency reported in the
+ issue. This asserts the *desired* contract โ that a trailing-slash
+ misspelling is handled uniformly across the sibling endpoints โ so it fails
+ (red) on master where the responses diverge, and would pass once the slash
+ conventions are unified. It does not prescribe which uniform behavior is
+ correct (all-redirect or all-404), only that they agree.
+ """
+ # (method, canonical route, misspelled route)
+ misspelled = [
+ ("post", "/api/v1/security/login/"),
+ ("get", "/api/v1/security/csrf_token"),
+ ("post", "/api/v1/security/guest_token"),
+ ]
Review Comment:
**Suggestion:** Add an explicit type annotation for the local collection
that stores the endpoint/method tuples. [custom_rule]
**Severity Level:** Minor ๐งน
<details>
<summary><b>Why it matters? โญ </b></summary>
This is a newly added Python variable that can be annotated, and it lacks a
type hint. That matches the custom rule requiring type hints for relevant
variables.
</details>
<details>
<summary><b>Rule source ๐ </b></summary>
.cursor/rules/dev-standard.mdc (line 28)
</details>
[](https://app.codeant.ai/fix-in-ide?tool=cursor&prompt_id=5d34af4836174cfc993199e38f63c9f0&service=github&base_url=https%3A%2F%2Fgithub.com&org=apache&repo=apache%2Fsuperset)
[](https://app.codeant.ai/fix-in-ide?tool=vscode-claude&prompt_id=5d34af4836174cfc993199e38f63c9f0&service=github&base_url=https%3A%2F%2Fgithub.com&org=apache&repo=apache%2Fsuperset)
*(Use Cmd/Ctrl + Click for best experience)*
<details>
<summary><b>Prompt for AI Agent ๐ค </b></summary>
```mdx
This is a comment left during a code review.
**Path:** tests/unit_tests/security/api_test.py
**Line:** 96:100
**Comment:**
*Custom Rule: Add an explicit type annotation for the local collection
that stores the endpoint/method tuples.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask
user if the user wants to fix the rest of the comments as well. if said yes,
then fetch all the comments validate the correctness and implement a minimal fix
```
</details>
<a
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F41965&comment_hash=fa242cb022a8e0ed83d64db73a9b95af0d6b9b2b4bcfb61ea369dad63c5c8632&reaction=like'>๐</a>
| <a
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F41965&comment_hash=fa242cb022a8e0ed83d64db73a9b95af0d6b9b2b4bcfb61ea369dad63c5c8632&reaction=dislike'>๐</a>
##########
tests/unit_tests/security/api_test.py:
##########
@@ -66,6 +66,50 @@ def test_csrf_exempt_blueprints_with_api_key(app: Any,
app_context: None) -> Non
assert "ApiKeyApi" in {blueprint.name for blueprint in
csrf._exempt_blueprints}
+def test_security_api_trailing_slash_handled_consistently(client: Any) -> None:
+ """Regression for #29934: sibling ``/api/v1/security/*`` endpoints handle a
+ misspelled (wrong trailing-slash) URL inconsistently.
+
+ Three routes live under the same ``/api/v1/security/`` prefix but are
+ declared with different slash conventions:
+
+ * ``login`` -> ``@expose("/login")`` (no trailing slash,
FAB)
+ * ``csrf_token`` -> ``@expose("/csrf_token/")`` (trailing slash,
Superset)
+ * ``guest_token`` -> ``@expose("/guest_token/")`` (trailing slash,
Superset)
+
+ Because of that mix, a client that gets the slash "wrong" is treated three
+ different ways by Werkzeug routing:
+
+ * ``POST /api/v1/security/login/`` -> 404 (no redirect for the extra
slash)
+ * ``GET /api/v1/security/csrf_token`` -> 308 redirect to the canonical
URL
+ * ``POST /api/v1/security/guest_token`` -> 308 redirect to the canonical
URL
+
+ A user hitting one misspelled security URL gets a clean redirect while
+ another gets a hard 404, which is exactly the inconsistency reported in the
+ issue. This asserts the *desired* contract โ that a trailing-slash
+ misspelling is handled uniformly across the sibling endpoints โ so it fails
+ (red) on master where the responses diverge, and would pass once the slash
+ conventions are unified. It does not prescribe which uniform behavior is
+ correct (all-redirect or all-404), only that they agree.
+ """
+ # (method, canonical route, misspelled route)
+ misspelled = [
+ ("post", "/api/v1/security/login/"),
+ ("get", "/api/v1/security/csrf_token"),
+ ("post", "/api/v1/security/guest_token"),
+ ]
+ statuses = {}
Review Comment:
**Suggestion:** Add a concrete type annotation for the dictionary that maps
URLs to status codes. [custom_rule]
**Severity Level:** Minor ๐งน
<details>
<summary><b>Why it matters? โญ </b></summary>
This is a newly introduced empty dictionary assigned to a local variable
without any annotation, so it violates the rule requiring type hints on
relevant variables that can be annotated.
</details>
<details>
<summary><b>Rule source ๐ </b></summary>
.cursor/rules/dev-standard.mdc (line 28)
</details>
[](https://app.codeant.ai/fix-in-ide?tool=cursor&prompt_id=b35037cae3ac49eda87f9a151356266f&service=github&base_url=https%3A%2F%2Fgithub.com&org=apache&repo=apache%2Fsuperset)
[](https://app.codeant.ai/fix-in-ide?tool=vscode-claude&prompt_id=b35037cae3ac49eda87f9a151356266f&service=github&base_url=https%3A%2F%2Fgithub.com&org=apache&repo=apache%2Fsuperset)
*(Use Cmd/Ctrl + Click for best experience)*
<details>
<summary><b>Prompt for AI Agent ๐ค </b></summary>
```mdx
This is a comment left during a code review.
**Path:** tests/unit_tests/security/api_test.py
**Line:** 101:101
**Comment:**
*Custom Rule: Add a concrete type annotation for the dictionary that
maps URLs to status codes.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask
user if the user wants to fix the rest of the comments as well. if said yes,
then fetch all the comments validate the correctness and implement a minimal fix
```
</details>
<a
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F41965&comment_hash=633b91fec593235790910205ea4b8cb2bc324625a98f99fa66217bacd6d8f572&reaction=like'>๐</a>
| <a
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F41965&comment_hash=633b91fec593235790910205ea4b8cb2bc324625a98f99fa66217bacd6d8f572&reaction=dislike'>๐</a>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]