[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953259#comment-16953259
]
ASF subversion and git services commented on SOLR-13835:
Commit b58695c98ce1356efc27beeb338a8300f6f72346 in lucene-solr's branch
refs/heads/branch_8_3 from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b58695c ]
SOLR-13835 HttpSolrCall produces incorrect extra AuditEvent on
AuthorizationResponse.PROMPT (#946)
(cherry picked from commit 611c4f960e9472880e2ec24dda9336a59cd41426)
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953257#comment-16953257
]
ASF subversion and git services commented on SOLR-13835:
Commit 5a074b0fe49ef863a162e7f5d55e351bc043c806 in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5a074b0 ]
SOLR-13835 HttpSolrCall produces incorrect extra AuditEvent on
AuthorizationResponse.PROMPT (#946)
(cherry picked from commit 611c4f960e9472880e2ec24dda9336a59cd41426)
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953246#comment-16953246
]
ASF subversion and git services commented on SOLR-13835:
Commit 611c4f960e9472880e2ec24dda9336a59cd41426 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=611c4f9 ]
SOLR-13835 HttpSolrCall produces incorrect extra AuditEvent on
AuthorizationResponse.PROMPT (#946)
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953219#comment-16953219
]
Chris M. Hostetter commented on SOLR-13835:
---
+1
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952774#comment-16952774
]
Jan Høydahl commented on SOLR-13835:
New commits to PR to explicitly handle known codes:
* 401 => EventType.FORBIDDEN
* 403 => EventType.UNAUTHORIZED
* 200/202 => EventType.AUTHORIZED
* All other statuses => EventType.ERROR
Please review. Think this should be mergeable now.
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16951179#comment-16951179
]
Chris M. Hostetter commented on SOLR-13835:
---
Jan: genreally speaking
[https://patch-diff.githubusercontent.com/raw/apache/lucene-solr/pull/946.patch]
seems like an improvement, but as far as the larger issue of how this code is
deciding what AuditEvents to fire based on the AuthorizationResponse i
still have the same concern i mentioned before regarding he "non-200|202" block
(which is unchanged in your patch):
bq. ...automatically assumed to be EventType.UNAUTHORIZED ... that seems kind
of brittle and error prone ... what if an AuthorizationPlugin returns a 500
status code?
bq. (particularly since the AuthorizationPlugin API seems open enough (ie:
there is no fixed enum of authResponse.statusCode values) that a custom plugin
could return a lot of diff non-200/202 error codes that the AuditLogger would
all report as "UNAUTHORIZED")
As a concrete example: i can write an AuthorizationPlugin that recognizes a
user does in fact have access to a resource, but returns {{new
AuthorizationResponse(429)}} because of the current state of the system,
causing a 429 error to be returned to external client -- but that will be
reported to the AuditLogger plugin as {{EventType.UNAUTHORIZED == 403}}
that seems brittle. Shouldn't the AuditLogger hooks be more explicit &
restricted and only report each {{EventType}} when they know for a fact that
situation / HTTP Status code occured, and have some more generic, and/or use a
more generic {{EventType.UNKNOWN}} if there is no direct correlation between
the AuthorizationResponse.statusCode and the predefined EventTypes? (or at the
very least, use {{EventType.ERROR}} when there isn't a direct correlation?
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950454#comment-16950454
]
Jan Høydahl commented on SOLR-13835:
{quote}Jan: Maybe i'm missing something, but IIUC in the context of how simple
those blocks were when the code was initially added, it was reasonable for the
first block to fall through to the second
{quote}
The logic was flawed originally since the code would return a 403 *instead* of
a 401 due to the fall-through.
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950452#comment-16950452
]
Jan Høydahl commented on SOLR-13835:
PR [GitHub Pull Request #946|https://github.com/apache/lucene-solr/pull/946]
ready for review, also folding in changes from SOLR-13840 which is now marked
as duplicate.
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16949629#comment-16949629
]
Chris M. Hostetter commented on SOLR-13835:
---
Jan: Maybe i'm missing something, but IIUC in the context of how simple those
blocks were when the code was initially added, it was reasonable for the first
block to fall through to the second:
Back when the code was introduced in SOLR-7757:
* If authResp.status == PROMPT: do some logging specific to the authResp, and
add some HTTP response headers specified by the auth plugin
* If authResp.status != OK: sendError(authResp.status)
** ie: it didn't matter if the authResp.status was PROMPT, or FORBIDDEN, or
anything else ... it wasn't ok so send an error with
...it's only as a result of changes introduced since then (with the addition of
audit logging to each of the conditionals) that we now have a bug in the form
of multiple Audit Events when authResp is PROMPT.
IIUC: from the perspective of the external client the behavior is still
entirely correct either way, it's only if/how an AuditLogger plugin is used and
what it expects that seems to be at risk.
(particularly since the AuthorizationPlugin API seems open enough (ie: there is
no fixed enum of authResponse.statusCode values) that a custom plugin could
return a lot of diff non-200/202 error codes that the AuditLogger would all
report as "UNAUTHORIZED")
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Priority: Major
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16949225#comment-16949225
]
Jan Høydahl commented on SOLR-13835:
The first if block was introduced back in 2005 as part of SOLR-7757.
[~noble.paul] why does the if not return? It will *always* fall through to and
trigger the next if block!
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Priority: Major
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13835) HttpSolrCall produces incorrect extra AuditEvent on AuthorizationResponse.PROMPT
[
https://issues.apache.org/jira/browse/SOLR-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16949098#comment-16949098
]
Chris M. Hostetter commented on SOLR-13835:
---
FWIW: it also seems a little concerning to me that any "non-200|202"
{{AuthorizationResponse}} is automatically assumed to be
{{EventType.UNAUTHORIZED}} ... that seems kind of brittle and error prone ...
what if an {{AuthorizationPlugin}} returns a 500 status code?
> HttpSolrCall produces incorrect extra AuditEvent on
> AuthorizationResponse.PROMPT
>
>
> Key: SOLR-13835
> URL: https://issues.apache.org/jira/browse/SOLR-13835
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
>Reporter: Chris M. Hostetter
>Assignee: Jan Høydahl
>Priority: Major
>
> spinning this out of SOLR-13741...
> {quote}
> Wrt the REJECTED + UNAUTHORIZED events I see the same as you, and I believe
> there is a code bug, not a test bug. In HttpSolrCall#471 in the
> {{authorize()}} call, if authResponse == PROMPT, it will actually match both
> blocks and emit two audit events:
> [https://github.com/apache/lucene-solr/blob/26ede632e6259eb9d16861a3c0f782c9c8999762/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L475:L493]
>
> {code:java}
> if (authResponse.statusCode == AuthorizationResponse.PROMPT.statusCode) {...}
> if (!(authResponse.statusCode == HttpStatus.SC_ACCEPTED) &&
> !(authResponse.statusCode == HttpStatus.SC_OK)) {...}
> {code}
> When code==401, it is also true that code!=200. Intuitively there should be
> both a sendErrora and return RETURN before line #484 in the first if block?
> {quote}
> This causes any and all {{REJECTED}} AuditEvent messages to be accompanied by
> a coresponding {{UNAUTHORIZED}} AuditEvent.
> It's not yet clear if, from the perspective of the external client, there are
> any other bugs in behavior (TBD)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
