Logging mechanism for debugging

[reden-tm]

Ruby has a logger and Python has a logger.

We're using the recurly-client-php library, and we really could use a debug mode logger or a general logger to trace logic errors with our usage of the recurly client.

Are there any plans for this?

[drewish]

No plans for it but we'd be be totally open to PRs.

[reden-tm]

Cool.

Mind if I refactor Recurly_Client-> _sendRequest() to use curl_setopt_array() to allow verbose curl?

[drewish]

Just for to clean up all those curl_setopt calls? Yeah that seems like a reasonable change. Were you thinking of controlling verbose via a property on Recurly_Client?

[reden-tm]

Yeah, I was thinking about controlling verbosity via a property on the client. I think I'll split this into two PR's. One with a simple property check:

if($this->curlopt_verbose) curl_setopt($ch, CURLOPT_VERBOSE, true);

And maybe another for the cleanup, because I probably won't get to the cleanup today.

[drewish]

What do you think about just calling the property verbose? i think curl just prints to standard err right? Wondering if it makes sense to expose CURLOPT_STDERR... I guess that could be a separate PR.

[reden-tm]

Yeah, verbose is better, but now I think the option is not really that useful. I see why there's a separate branch for verbose cURL; it's much easier to apply the patch to my local dev and use that.

I really like the logging available in the Ruby and Python clients, but it looks like that would be a fairly large PR.

For example, the Ruby code checks to see if a logger exists and decides what information to log.

          if Recurly.logger
            Recurly.log :info, "===> %s %s" % [request.method, uri]
            headers = request.to_hash
            headers['authorization'] &&= ['Basic [FILTERED]']
            Recurly.log :debug, headers.inspect
            if request.body && !request.body.empty?
              Recurly.log :debug, XML.filter(request.body)
            end
            start_time = Time.now
          end

If I add logging into the PHP client, do you think I should mimic the pattern and output from the Ruby client?

[drewish]

I'm wondering if it's worth finding a component to avoid re-inventing the wheel. maybe symphony has a component or something? Seems like there's probably something popular that we could add as a dev dependency and then let the caller inject it into the client... but yeah kind of a PITA to do it right.

[austinheap]

@drewish +1 to leverage Monolog

[reden-tm]

@drewish and @austinheap , I'm working on a patch for PSR-3 logging support now. You should see it soon.

[drewish]

@reden-tm awesome! i'm happy to look at any in progress commits.

[aaron-junot]

Hello all. I would like to point out that we recently disabled logging in production for the Python and Ruby client libraries as it is a security concern.

One of the benefits of using Recurly as a platform is that you lessen your compliance scope (PCI, etc.) by letting us handle the security of processing and storing your customers' PII and credit card data. By logging the information sent to and from the Recurly servers, you now open yourself up to various security and compliance risks, hence we do not advocate logging production data from our libraries.

For that reason, I'm going to go ahead and close out this issue and the related PR (without merging it). Please be aware of the risks of using forks of this library that log production data, and please take all precautions to protect your customers' data.