Steve,

Thanks for the suggestion... I too have the ability to turn debugging on for certain IP addresses on the fly. We leave logging on so we can go back over log files after an error has been reported.

/John

Steve Smith 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

Reply via email to