How do I customize the Hapi.js access log? - node.js

I'm using Hapi.js's Good and GoodFile for access logs by logging 'response' events. How can I customize the object that gets logged? Specifically, I do not want to include the 'query' property on response events when the 'statusCode' is a 404.

good-file is not configurable in that fashion. It logs the JSON representation of the complete request. At present, if you want to control how the output is formatted, you will have to write your own custom reporter. Documentation can be found here.
You may also be able to fork good-file and just make some changes to the way the output is formatted.

Related

BuildFire: How do we access the public logs?

We are pushing logs using "buildfire.publicData.insert". How do we get access to those logs?
Would these logs contain the header that is sent in the calls? We also need to see the source and destination information. Those are the logs we really need.
Public data is really just a data source, think of it as a database where the data you save in you can retrieve later.
So if you're using it to push logs you need to make sure that any needed information is in the body object are passed to save or insert calls. those can be retrieved later using search calls as documented in https://sdk.buildfire.com/docs/public-data
You can also implement the search only on the control side of your plugin if these data are not meant to be shared with widget users.
Since you might have a lot of records it is recommended you use https://sdk.buildfire.com/docs/indexed-fields so your queries are efficient.

testcafe log full request header

For a test case, I want to log the full request and/or response header of a testcafe test with the RequestLogger.
Is this possible? By default, only some basic information is logged.
Thanks
Make sure to enable the necessary options that are disabled by default when you create a request logger:
If any information is missing, specify what it is and why you need it.

Modify a CloudFront request before logging?

I'm building an ELK stack (for the first time) to track end-user REST API usage for a CloudFront distribution (in front of an S3 origin). Users pass a refresh token as part of their request and I was hoping to use this token to identify which users were making which request. Unfortunately, it looks like CloudFront access logs are missing some header information (particularly Authorization/Accept in my use case). This leaves me with three questions:
Is there a way to tell CloudFront to log additional items? It appears the answer is no.
As an alternative strategy, I tried modifying the request object with lambda#edge (in Viewer Request) to move the header information into the query string (so that it would get logged) but any manipulation in lambda#edge does not seem to be reflected in the log. (though it is reflected in the Origin Request function). Should this be possible?
If doing what I want is impossible, I think the alternative approach is forgo CloudFront logs completely and just fire an http request to logstash with every user request, but I feel like this could be easy to overload.
Thanks
After a few days of research and reaching out to Amazon, I was finally able to answer my own questions:
CloudFront logs can't be customized, they are what they are.
See 1.
It turns out that customization is the wrong approach. What I really need to do is aggregate two separate logs that have the information I need into a single logstash entry. It turns out that the Viewer Response lambda#edge function contains a requestId property (actually event.Records[0].cf.config.requestId) which matches the CloudFront log x-edge-request-id column. So while I haven't finished implementing it yet, these two columns can be used in the logstash config for aggregation. I just need to make sure I set up a Viewer Response event that logs out a consistent format that I can then part with logstash. I'm using the logstash-input-cloudwatch_logs to retrieve teh cloudwatch logs.

Request specific logging using Bunyan

I am using bunyan for logging service in my express-nodeJS application. I want to log per user/per request logging so that flow of request can be tracked down easily and will be easier to debug and keep a check on response time.
I am thinking to create a child logger on every request and attach user info to it and then attach that logger to request object. My application is kind of mvc, so my model doesn't know about request object and most of the logging is being done in models only. Now with this approach I have to pass that child logger as parameter to every function call in function and then may be that needs to be passed in other adapters that model will call.Is this the right way to do this ? As the codebase is really vast every function needs to be updated. Can you suggest any better way to achieve same results with less changes in code ?

Can I capture JSON data already being sent with a userscript/Chrome extension?

I'm trying to write a userscript/Chrome extension to capture JSON data being sent while using a web service so that I can reformat it and display selected portion on page. Currently the JSON is sent as the application loads (as I've observed from watching traffic with Fiddler 2). Is my only option to request the JSON again or is capture possible? As I'm not providing a code example, a requested answer is even some guidance on what method / topic to research or if I'm barking up the wrong tree.
No easy way.
If it is for a specific site you might look into intercepting and overwriting part of a code which sends a request. For example if it is sent on a button click you can replace existing click handler with your own implementation.
You can also try to make a proxy for XMLHttpRequest. Not sure if this even possible, never seen a working example. You can look at some attempts here.
For all these tasks you probably would need to run your javascript code out of sandboxed content script to be able to access parent page variables, so you would need to inject <script> tag with your code right into the page from a content script:

Resources