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

To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to