application playback module

There are cases where we are required by law to be able to playback
requests that have changed something in the database.
Is there a module that can navigate through log history and show all
pages that were submitted?
Can it be done?
Something that wraps arround controllers, saving Requests to database,
and in certain admin mode restores the selected request and runs the
appropriate controller and the view.

There are cases where we are required by law to be able to playback
requests that have changed something in the database.

1. requests that *have* already changed something or that *could*
    (potentially) have changed something?
   - e.g. if an update request fails (validation, exception, error, etc.)
     should it still be recorded?

2. how much of the request environment do you need to capture
    to be able to realistically "play back" the request?
    - current_user
    - session variables
    - request headers
    - db state (data, schema) # see point #3
    - app version and state # see point #3
    - system environment (date/time, TZ, libraries) # see point #3

3. how far back does this history need to go?
    - is it reasonable or accurate to "play back" an operation:
      - if you've e.g. run a migration on the affected table since the
        original request?
      - if you're using a class or classes modified or added since the
        original request?
      - if you're using a system library that's been modified/updated
        since the original request?

P.S. Please tell me the "playback" operation -- which by definition is
non-idempotent -- would be happening on a backup/mirror database,
regardless :slight_smile:

Is there a module that can navigate through log history and show all
pages that were submitted?
Can it be done?

Anything can be done with enough time and money :slight_smile:

(If I had to implement something like this, I'd probably start looking
at ElasticSearch and Logstash.)

FWIW,

Hi!

You've got there a few good points!
I was hoping that playback could be based on requests only. More I think
of it, it would need to save responses, too.

To answer your questions:
1. Errors perhaps need not to be saved. Although, when everything is
saved it may lead to a huge amount of space, such a log would be finite,
1 year backwards or so.

2. The playback system would fake the original request. Session
variables can be tricky, though, but what is needed is recreating the
pages and forms user has submitted or viewed. Not to execute them again!
So session variables may not be that necessary.

3. Actually, playback could be in theory be run without a database at
all. The aim is to find an exact point when some specific change in the
database has occurred and who did it, and to document it.

I know, this looks like a Big Brother, but in medical applications it
may be required by law, in my country at least.

Regards, Zdravko

OK, that sounds less like "playback" and more like "audit" - keeping
a running record of attribute value changes (and changer identity).

I have one app that requires that kind of tracking, currently provided
by <https://github.com/collectiveidea/audited> but there are other
options:
<https://www.ruby-toolbox.com/search?utf8=✓&q=audit>

HTH,

Given your statement about legal requirements, I think it would be highly inappropriate to attempt to do that in Rails. You need to do it in the database, so that the audit log cannot be circumvented merely by making changes without going through your Rails app.

> The aim is to find an exact point when some specific change in the
> database has occurred and who did it, and to document it.

Given your statement about legal requirements, I think it would be highly
inappropriate to attempt to do that in Rails. You need to do it in the
database, so that the audit log cannot be circumvented merely by making
changes without going through your Rails app.

​Agreed. If you're using PostgreSQL there's a somewhat experimental
pg_audit extension that uses triggers to maintain a change log.​ Oracle has
AUDIT, etc..

Paul

Thanks! This seems very useful.
For changes without going through Rails app, well I'm not sure when
enough is enough. At db level one can not catch the current_user.
But anyway this will do. Thanks, guys.

Regards, Zdravko