cancel
Showing results for 
Search instead for 
Did you mean: 

Auditing search queries

florentdelannoy
Champ in-the-making
Champ in-the-making
Hi,

As part of a project, I need to be able to audit searches performed by users in Alfresco (running 4.2.f from the maven archetype).

I've set up the Auditing subsystem, which works as advertised, but the SearchService is not part of the default alfresco-access application so I set out to create my own audit application:


  <PathMappings>
    <PathMap source="/alfresco-api/post/SearchService/query" target="/searchaudit/query" />
  </PathMappings>


  <Application name="SearchAudit" key="searchaudit">
    <AuditPath key="query">
      <AuditPath key="no-error">
        <RecordValue key="args" dataExtractor="simpleValue" dataSource="/searchaudit/query/args" />
        <GenerateValue key="user" dataGenerator="personFullName" />
      </AuditPath>
    </AuditPath>
  </Application>


I got those paths by turning on the extended audit logging which showed me these values when doing a search:


2014-10-10 15:16:51,719  DEBUG [repo.audit.inbound] [http-bio-8080-exec-4]
Inbound audit values:
   /alfresco-api/post/SearchService/query/args=null
   /alfresco-api/post/SearchService/query/no-error=null
   /alfresco-api/post/SearchService/query/result=org.alfresco.repo.search.impl.lucene.PagingLuceneResultSet@109d90ef


The application is loaded properly and appears as started in http://localhost:8080/alfresco/service/api/audit/control

And values appear when fetching http://localhost:8080/alfresco/service/api/audit/query/SearchAudit?verbose=true

However, no matter how I try, I cannot get this to record the terms that have been searched for (which I gather are in the /args part of the query?), only the user shows. Actually it appears as if the args are never recorded - 'args' always appear to be null both in the logs and when passing it to a custom dataExtractor I wrote and wired in for debugging purpose.

Obviously the SearchService has to be passed some sort of arguments to perform a search, so these cannot be null under the hood.

Looking at the code for SearchService.java, we can see the proper @Auditable annotations are set up where needed, so it looks like there's no problem here.

So my questions are…

- Am I doing something obviously wrong with the auditing subsystem?
- If not, how can I actually record the search terms though the auditing system?

Thanks in advance,
Florent
2 REPLIES 2

kaynezhang
World-Class Innovator
World-Class Innovator
It seems alfresco didn't extract invocation arguments correctly.it has nothing to do with your audit application,even if there is something wrong with  your audit application ,Alfresco should still can extract invocation arguments.
I'm afraid there is something wrong with your alfresco environment.

florentdelannoy
Champ in-the-making
Champ in-the-making
Thanks kaynezhang! Your comment reassured me that I wasn't doing anything wrong, so I continued investigating.

After debugging down the code through Eclipse, it turns out that the particular query() function being called is the following:
public abstract org.alfresco.service.cmr.search.ResultSet org.alfresco.service.cmr.search.SearchService.query(org.alfresco.service.cmr.search.SearchParameters)

The Audit subsystem, in this case the method getInvocationArguments from the AuditMethodInterceptor, tries to record the SearchParameters by calling getRecordableValue, but as it happens the class SearchParameters:
1. Is not Serializable, so we can't just save it as Serializable
2. Does not have a converter to String defined in DefaultTypeConverter, so we can't save it as String

After these two options are exhausted, getRecordableValue gives up and tells us that the value is not auditable.


So, possible solutions would be…
- Add a SearchParameters -> String converter, but that would need to be an Alfresco core change. Extending the DefaultConverter is not currently possible (cf. "TODO: Support for dynamically managing conversions" in DefaultTypeConverter.java)
- Make SearchParameters Serializable, but it probably would be more work than needed for this particular issue

In any case, there's no easy drop-in solution at this point I'm afraid.


Edit: I reported this issue in JIRA as <a href="https://issues.alfresco.com/jira/browse/ALF-21135">ALF-21135</a>.