Application playback module

Rails
1

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.

2

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

3

On Tue, Jul 14, 2015 at 11:14 AM, Zdravko B. [email protected]
wrote:

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,

Hassan S. ------------------------ [email protected]

twitter: @hassan
Consulting Availability : Silicon Valley or remote

4

On Wed, Jul 15, 2015 at 12:36 AM, Zdravko B. [email protected]
wrote:

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.

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,

Hassan S. ------------------------ [email protected]

twitter: @hassan
Consulting Availability : Silicon Valley or remote

5

On Wed, Jul 15, 2015 at 12:36 AM, Zdravko B. [email protected]
wrote:

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.

–
Scott R.
[email protected]
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice

6

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

7

On Wed, Jul 15, 2015 at 10:31 AM, Scott R.
[email protected]
wrote:

​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