In some of our applications we keep a history table. A single method
called insertHistory is invoked at the application entry point. The
table includes date, time, userID, userRef, contractID and 5 columns for
args that control the flow through the application called class, method,
function, mode and args. The args column is a longtext datatype that
gets all the postargs except for a predefined set, like cardNumber.

The benefit is that we can turn off witango logging and still keep track
of everything that happened across multiple witango services. A simple
SQL statement can be used to see everything that has been done on a
particular contract, or everything that a user did during a given
session. So when a user identifies a problem we can determine the exact
steps he took to find out what went wrong. Or we can tell who changed
what and when on a given contract.

Sensitive information, like cardNumber, is excluded from the table.

With a relatively fast database, like mySQL, it only adds a few mSec to
each hit.

BTW, if your going through SSL to get credit card info and ssn's there
shouldn't be a problem. Witango doesn't log postargs passed through SSL.

Dave

-----Original Message-----
From: John McGowan [mailto:[EMAIL PROTECTED] 
Sent: April 29, 2004 10:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Witango-Talk: logging and security

Too much work... I would have to reinvent the logging system and know 
ahead of time where I am going to need to see the values of the
variables.

If I had to describe the feature i need it would go something like this.

in witango.ini
SENSITIVE_POSTARGS=CARDNUMBER,SSN
SENSITIVE_VARNAMES=CardNumber,SSN

And then the logging system could simply "XXX" the values out or not 
output the variable at all.  Of course the longer the list of sensitive 
vars the more of a performance hit there would be, So then perhaps the 
following would be better.

SENSITIVE_VARSUFFIX=NOLOG

This way if I assign to a variable called Local$CardNumber_NoLog  it 
won't show up in the logfile.  In the meantime I think I'm going to 
write a simple perl script to look at every line for the offending vars 
and postargs.

Perhaps the Witango logging could be piped to a separate process tasked 
with cleaning up the logfile.  and that separate process could be 
"nicer" than the witango process, so it would not interfere with the 
rest of the app servers responsibilities.

/John

witango man wrote:

>You may also like to use <@logmessage> - I don't know
>what the limit on the length of the message is but
>it's pretty big - thus you could write out all args
>and vars leaving out the sensitive ones...
>
>
>--- Steve Smith <[EMAIL PROTECTED]> wrote:
>  
>
>>Is the logging something that you can turn on after,
>>to try to  
>>reproduce a problem that a user has reported? Or do
>>you need to be able  
>>to go back over the log files after a user has
>>reported an error.
>>
>>If it is the former, what I do is to have a
>>"developer's" taf that  
>>allows me to go in and turn debug on and off for the
>>current user's  
>>session. It's not the same as logging, but it has
>>helped me track down  
>>problems by going through and reproducing what the
>>user did.
>>
>>If you want more info on this, let me know.
>>
>>Hope this helps,
>>
>>Steve Smith
>>
>>Oakbridge Information Solutions
>>Office: (519) 624-4388
>>GTA:    (416) 606-3885
>>Fax:    (519) 624-3353
>>Cell:   (416) 606-3885
>>Email:  [EMAIL PROTECTED]
>>Web:    http://www.oakbridge.ca
>>
>>On Wednesday, April 28, 2004, at 03:10 PM, John
>>McGowan wrote:
>>
>>    
>>
>>>That's what I thought.
>>>
>>>We typically have the logging set to show actions.
>>>      
>>>
>> Which takes up a  
>>    
>>
>>>lot of disk space, but is very helpful in proving
>>>      
>>>
>>that there was "user  
>>    
>>
>>>error" in some situations.  I'm considering just
>>>      
>>>
>>shutting down logging  
>>    
>>
>>>right now.  I just know that if I do i'm going to
>>>      
>>>
>>get a call the next  
>>    
>>
>>>day asking to investigate a problem that a user
>>>      
>>>
>>experienced.
>>    
>>
>>>/John
>>>
>>>Robert Shubert wrote:
>>>
>>>      
>>>
>>>>I agree that those files are something to
>>>>        
>>>>
>>consider. You might want to
>>    
>>
>>>>think about making a simple BAT that would
>>>>        
>>>>
>>zip/encrypt/password the
>>    
>>
>>>>files each night. They would then be available to
>>>>        
>>>>
>>you if you wanted.  
>>    
>>
>>>>The
>>>>suggestion of post processing, perhaps with a
>>>>        
>>>>
>>regex command is also
>>    
>>
>>>>valid.
>>>>An argument might be made that LogLevel=1 should
>>>>        
>>>>
>>not contain  
>>    
>>
>>>>post/search
>>>>arguments. I guess the log might still be useful
>>>>        
>>>>
>>in the long run for
>>    
>>
>>>>basic access/error searching.
>>>>
>>>>One thing that I am asking for in the next major
>>>>        
>>>>
>>release is an
>>    
>>
>>>>ERRORSONLY logging class. At first I was thinking
>>>>        
>>>>
>>this for the
>>    
>>
>>>>witangoevents.log file, but I can also see it
>>>>        
>>>>
>>useful in the regular  
>>    
>>
>>>>log.
>>>>This wouldn't necessarily solve the problem you
>>>>        
>>>>
>>brought up, but if the
>>    
>>
>>>>log contained only error data, it would be much
>>>>        
>>>>
>>smaller and more  
>>    
>>
>>>>useful
>>>>with the occasional time you needed such data.
>>>>
>>>>Aside from my free-thinking, there are no current
>>>>        
>>>>
>>mechanisms with  
>>    
>>
>>>>which
>>>>to deal with your problem. I would assign the log
>>>>        
>>>>
>>folder to a  
>>    
>>
>>>>non-shared
>>>>partition of the server if you can, or off the
>>>>        
>>>>
>>server on a machine  
>>    
>>
>>>>with
>>>>more security, and less public access.
>>>>
>>>>Robert
>>>>
>>>>-----Original Message-----
>>>>From: John McGowan [mailto:[EMAIL PROTECTED]
>>>>        
>>>>
>>Sent: Wednesday, April  
>>    
>>
>>>>28, 2004 1:59 PM
>>>>To: [EMAIL PROTECTED]
>>>>Subject: Witango-Talk: logging and security
>>>>
>>>>Many times we leave Witango logging turned on so
>>>>        
>>>>
>>we can debug a  
>>    
>>
>>>>problem after it's been reported by a user.  When
>>>>        
>>>>
>>that site is one  
>>    
>>
>>>>that does e-commerce, there is a problem.  The
>>>>        
>>>>
>>Witango log contains  
>>    
>>
>>>>all the post arguments passed in and variable
>>>>        
>>>>
>>changes etc... that  
>>    
>>
>>>>data could be sensitive, and not something we
>>>>        
>>>>
>>want laying around.
>>    
>>
>>>>Is there any way to control the witango logging
>>>>        
>>>>
>>system to not print  
>>    
>>
>>>>certain post args, and not show the value of
>>>>        
>>>>
>>certain variables when  
>>    
>>
>>>>they
>>>>
>>>>change?
>>>>
>>>>Otherwise the only thing i can think of is to run
>>>>        
>>>>
>>a program that  
>>    
>>
>>>>processes the logfile after it has been rolled to
>>>>        
>>>>
>>stirp out any  
>>    
>>
>>>>patterns
>>>>
>>>>that we don't want in the logfile.
>>>>
>>>>/John
>>>>
>>>>
>>>>        
>>>>
>______________________________________________________________________
>  
>
>>>>__
>>>>TO UNSUBSCRIBE: Go to
>>>>        
>>>>
>>http://www.witango.com/developer/maillist.taf
>>    
>>
>>>>        
>>>>
>______________________________________________________________________
>  
>
>>>>__
>>>>TO UNSUBSCRIBE: Go to
>>>>        
>>>>
>>http://www.witango.com/developer/maillist.taf
>>    
>>
>>>>        
>>>>
>>>      
>>>
>_______________________________________________________________________
>  
>
>>>_
>>>TO UNSUBSCRIBE: Go to
>>>      
>>>
>>http://www.witango.com/developer/maillist.taf
>>    
>>
>>>      
>>>
>>    
>>
>_______________________________________________________________________
_
>  
>
>>TO UNSUBSCRIBE: Go to
>>    
>>
>http://www.witango.com/developer/maillist.taf
>
>
>
>       
>               
>__________________________________
>Do you Yahoo!?
>Win a $20,000 Career Makeover at Yahoo! HotJobs  
>http://hotjobs.sweepstakes.yahoo.com/careermakeover 
>_______________________________________________________________________
_
>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>
>  
>

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to