Github user janhoy commented on a diff in the pull request:
    --- Diff: solr/core/src/java/org/apache/solr/security/ ---
    @@ -0,0 +1,388 @@
    + * Licensed to the Apache Software Foundation (ASF) under one or more
    + * contributor license agreements.  See the NOTICE file distributed with
    + * this work for additional information regarding copyright ownership.
    + * The ASF licenses this file to You under the Apache License, Version 2.0
    + * (the "License"); you may not use this file except in compliance with
    + * the License.  You may obtain a copy of the License at
    + *
    + *
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +import javax.servlet.http.HttpServletRequest;
    +import java.lang.invoke.MethodHandles;
    +import java.util.Date;
    +import java.util.Enumeration;
    +import java.util.HashMap;
    +import java.util.List;
    +import java.util.Map;
    +import org.apache.solr.common.SolrException;
    +import org.slf4j.Logger;
    +import org.slf4j.LoggerFactory;
    +import static;
    + * Audit event that takes request and auth context as input to be able to 
audit log custom things
    + */
    +public class AuditEvent {
    +  private static final Logger log = 
    +  private String message;
    +  private Level level;
    +  private Date date;
    +  private String username;
    +  private String session;
    +  private String clientIp;
    +  private List<String> collections;
    +  private Map<String, Object> context;
    +  private HashMap<String, String> headers;
    +  private Map<String, Object> solrParams;
    +  private String solrHost;
    +  private int solrPort;
    +  private String solrIp;
    +  private String resource;
    +  private String httpMethod;
    +  private String queryString;
    +  private EventType eventType;
    +  private AuthorizationResponse autResponse;
    +  private String requestType;
    +  private double QTime = -1;
    +  private int status = 0;
    +  private Throwable exception;
    +  /* Predefined event types. Custom types can be made through constructor 
    +  public enum EventType {
    +    AUTHENTICATED("Authenticated", "User successfully authenticated", 
    +    REJECTED("Rejected", "Authentication request rejected", Level.WARN),
    +    ANONYMOUS("Anonymous", "Request proceeds with unknown user", 
    +    ANONYMOUS_REJECTED("AnonymousRejected", "Request from unknown user 
rejected", Level.WARN),
    +    AUTHORIZED("Authorized", "Authorization succeeded", Level.INFO),
    +    UNAUTHORIZED("Unauthorized", "Authorization failed", Level.WARN),
    +    COMPLETED("Completed", "Request completed", Level.INFO),
    --- End diff --
    That could of course be a way to leverage levels, that with INFO you get 
all intermediate events but with WARN you get the result of the whole request. 
    Solr is a bit different from stateful session-based apps, where you expect 
to get one LOGIN event, then multiple queries and finally a logout - then it 
makes sense to log everything.
    I'll thy to think of some other way to configure whether to log only "leaf" 
events, i.e. the last event. That could be a `type=[info|final|partial]` or 
something, where the type of each event would be
        AUTHENTICATED: info
        REJECTED: final
        ANONYMOUS: info
        AUTHORIZED: info
        UNAUTHORIZED: final
        COMPLETED: final
        ERROR: final
    The partial state would be used for async APIs where someone has e.g. 
ordered (and were allowed to do so) a collection delete, but we don't yet know 
if it succeeded or failed. Then the question is whether it is sufficient to log 
the partial event. I feel that perhaps we need to also log a followup event 
either COMPLETED or ERROR once the delete has gone through, and link the two 
with the job-ID or similar. And this should be done in a generic way so that it 
would also work for other APIs than the collection API?


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to