Open wtwhite opened 6 months ago
GET /favicon.ico
also does not trigger the Interceptor
..css
, .png
, .js
) does trigger it.The plot thickens: Although Firefox doesn't show provenance-id:
HTTP header for GET /favicon.ico
, it is there if we directly curl
it:
wtwhite@wtwhite-vuw-vm:~$ curl -i http://localhost:8080/favicon.ico
HTTP/1.1 200
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Clacks-Overhead: GNU Terry Pratchett
provenance-id: 18
Last-Modified: Fri, 15 Mar 2024 01:50:54 GMT
Accept-Ranges: bytes
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: image/x-icon
Content-Length: 67646
Date: Fri, 15 Mar 2024 02:01:43 GMT
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
The above output also shows X-Clacks-Overhead: GNU Terry Pratchett
, indicating that an example plain Filter
(from here) also runs.
This made me hopeful that perhaps Firefox was also just hiding the provenance-id:
header for the POST /login
request as well -- but not only is that header not there even when using curl
, the Filter
(which I had hoped would operate at a lower, harder-to-disable level) does not fire either 😢:
wtwhite@wtwhite-vuw-vm:~$ curl -X POST -i http://localhost:8080/login
HTTP/1.1 302
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Set-Cookie: JSESSIONID=68C7C0E8167F27D92DC834E7F8995232; Path=/; HttpOnly
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Location: http://localhost:8080/?error
Content-Length: 0
Date: Fri, 15 Mar 2024 02:02:58 GMT
Could it be that the Filter
was running, but the HTTP header it added was getting removed by later processing? No, since both the Filter
and the Interceptor
log to stdout but Spring logs show no sign of either of them:
2024-03-15 15:02:58.081 DEBUG 695178 --- [nio-8080-exec-2] o.s.w.s.handler.SimpleUrlHandlerMapping : Mapped to ResourceHttpRequestHandler [URL [file:src/main/resources/static/], Classpath [static/], ServletContext [/]]
2024-03-15 15:02:58.142 DEBUG 695178 --- [nio-8080-exec-2] o.s.jdbc.core.JdbcTemplate : Executing prepared SQL query
2024-03-15 15:02:58.143 DEBUG 695178 --- [nio-8080-exec-2] o.s.jdbc.core.JdbcTemplate : Executing prepared SQL statement [select username,password,enabled from users where username = ?]
recordActivity(capturedReturn=null, activityTypes=DBRead!
ThreadLocalProvenanceTracker.track(nz.ac.wgtn.veracity.provenance.injector.model.Invocation@c2a56ed) called for ID NO_ACTIVE_REQUEST!
ThreadLocalProvenanceTracker.track(): There are now 1 invocations tracked so far for ID NO_ACTIVE_REQUEST.
recordActivity(capturedReturn=null, activityTypes=DBRead!
ThreadLocalProvenanceTracker.track(nz.ac.wgtn.veracity.provenance.injector.model.Invocation@3cae1e9b) called for ID NO_ACTIVE_REQUEST!
ThreadLocalProvenanceTracker.track(): There are now 2 invocations tracked so far for ID NO_ACTIVE_REQUEST.
recordActivity(capturedReturn=null, activityTypes=DBRead!
ThreadLocalProvenanceTracker.track(nz.ac.wgtn.veracity.provenance.injector.model.Invocation@5e361f75) called for ID NO_ACTIVE_REQUEST!
ThreadLocalProvenanceTracker.track(): There are now 3 invocations tracked so far for ID NO_ACTIVE_REQUEST.
recordActivity(capturedReturn=null, activityTypes=DBRead!
ThreadLocalProvenanceTracker.track(nz.ac.wgtn.veracity.provenance.injector.model.Invocation@1bfc108c) called for ID NO_ACTIVE_REQUEST!
ThreadLocalProvenanceTracker.track(): There are now 4 invocations tracked so far for ID NO_ACTIVE_REQUEST.
Is the issue POST
requests generally? No, since posting to a different (and nonexistent) page triggers both the Filter
and the Interceptor
:
wtwhite@wtwhite-vuw-vm:~$ curl -X POST -i http://localhost:8080/nonexistent-page
HTTP/1.1 404
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Clacks-Overhead: GNU Terry Pratchett
provenance-id: 19
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
provenance-id: 20
Content-Type: application/json
Transfer-Encoding: chunked
Date: Fri, 15 Mar 2024 02:03:43 GMT
{"timestamp":"2024-03-15T02:03:43.635+00:00","status":404,"error":"Not Found","path":"/nonexistent-page"}wtwhite@wtwhite-vuw-vm:~$
Conclusion: Spring's auth mechanism somehow overrides the normal Servlet
-spec handling for specific HTTP requests (like POST /login
here) to turn off Filter
s (as well as turn off its own Interceptor
mechanism) 😢
When applied to https://github.com/veracitylab/provenance-demonstrator-movie, some DB reads are being detected by the agent but are not occurring inside an
Interceptor
, so they will not be picked up.App started with:
Specifically, logging in via the web app triggers DB reads, but this request is not intercepted by the
Interceptor
set up to do so:Positive example of requesting
/testprov
withcurl
for comparison (note the "pre handle" and "post handle" log lines):Requesting the library page (list of movies) also works: