application playback module

[Zdravko Balorda]

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.

--
Posted via http://www.ruby-forum.com/.

[Hassan Schroeder]

On Tue, Jul 14, 2015 at 11:14 AM, Zdravko Balorda <li...@ruby-forum.com> 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 :-)

> 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 :-)

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

FWIW,
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
Consulting Availability : Silicon Valley or remote

[Zdravko Balorda]

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

[Hassan Schroeder]

On Wed, Jul 15, 2015 at 12:36 AM, Zdravko Balorda <li...@ruby-forum.com> 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=%E2%9C%93&q=audit>

HTH,

[Scott Ribe]

On Wed, Jul 15, 2015 at 12:36 AM, Zdravko Balorda <li...@ruby-forum.com> 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 Ribe
scott...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice

[Paul Makepeace]

On Wed, Jul 15, 2015 at 10:31 AM, Scott Ribe <scott...@elevated-dev.com> wrote:

On Wed, Jul 15, 2015 at 12:36 AM, Zdravko Balorda <li...@ruby-forum.com> 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.

​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

--
Scott Ribe
scott...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9607EA48-BB99-433E-88C1-4EF2516EEC37%40elevated-dev.com.

For more options, visit https://groups.google.com/d/optout.

[Zdravko Balorda]

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