search

HangfireIO / Hangfire

An easy way to perform background job processing in .NET and .NET Core applications. No Windows Service or separate process required
https://www.hangfire.io
Other
9.41k stars 1.7k forks source link

How to save user Manual activity on the hangfire dashboard to database ? #1902

Open prichakraborty09 opened 3 years ago

prichakraborty09 commented 3 years ago

Hi All,

I need to save any manual activity done on the dashboard to a database. I'm currently using OnStateUnapplied(), to track such activities and will be using the Reason field for 'Triggered by Dashboard UI' & 'Triggered by Recurring Job' to track these manual operations. I have 2 questions.

1) Is there a cleaner way to implement this ? 2) Whenever I delete anything under the Recurring Jobs section, can that be tracked as well because OnStateUnapplied() doesn't get invoked during the operation.

Thanks PC

Frazi1 commented 3 years ago

Every dashboard action is implemented as a separate IDashboardDispatcher. You can find a list of all the used dispatchers here: https://github.com/HangfireIO/Hangfire/blob/1b5dc4074fc34484290b4621c7097ef5334eb804/src/Hangfire.Core/Dashboard/DashboardRoutes.cs#L41-L179

A better way of building an audit trail for the Dashboard actions would be in decorating the dashboard dispatchers and logging from there. But the problem is that everything is private, and you can't really decorate the existing dispatchers. You can try to use reflection or create a PR for Hangfire to expose some new methods that will allow you to do your magic.

I don't see a better way of doing it. If you don't want to mess with dispatchers, your current approach may be a good one.

But as you noticed already, filters do not get invoked on recurring jobs modifications. That is expected. You can decorate IRecurringJobManager interface to create an audit trail when the interface methods get invoked. But this approach will not let you detect whether the action was triggered via the Dashboard or automatically.

I have an example of implementing a decorator that is used to automatically clean-up outdated recurring jobs here: https://github.com/Frazi1/DSR_HangfireExample/commit/bdc9010631c7bb0a8092c4591c32e6d8f5e2e7c7 That commit demonstrates how you implement a decorator and wire it up with the Microsoft's DI container. You can borrow the idea, but create a decorator with your custom logic.

prichakraborty09 commented 3 years ago

@Frazi1 Thank you for your response. Looks like we are gonna wait this out at the moment. I am gonna implement a read-write access only to the dashboard for our team(10-15), so only those users will have the access to trigger a manual action. If we still need a detailed report on who did what, then would have to go back to what I was trying before.

pieceofsummer commented 3 years ago

You probably don't really need to know how users navigated pages, right? If you only need to know if some user has run or deleted the job, you can just go with logging in a custom IApplyStateFilter. If http context is available the moment filter is executed, you can extract user info from it.

Or you can set a middleware on the web server running the dashboard and log (or even intercept) requests the users are making to Hangfire endpoints.

prichakraborty09 commented 3 years ago

@pieceofsummer yes I did do that like. Just that if someone deleted a recurring job schedule there is no way to track it though. IApplyStateFilter methods do not get invoked in this scenario. So was asking for a way to catch that event.