Ruby on Rails

On Aug 19, 2016, at 10:23 AM, Brendon <brendon@darkindigo.com> wrote:

If you are trying to be PCI compliant, then this approach just doesn't cut it. PCI DSS compliance rules apply to anybody who is Processing, Transmitting or Storing card info. Since your server is handling (processing and transmitting) the "banking information" it needs to be inside the PCI 'zone' with all the logging, software requirements physical access restrictions, etc. I'd strongly urge you to NOT do this.

If somebody gains access to your server, they can easily log the request parameters and *bang* you are liable for the data breach, even if you don't store the data. That is basically what happened at Target, where the system sent the card info out of the company until the breach was found.

The easy way to dodge PCI responsibility is to NEVER touch the sensitive data.

It is much easier than it used to be:

1. You render your card info entry screen in the browser, but have the submit button go STRAIGHT to Stripe, Braintree, Authorize.net, etc.
2. When the user submits, the browser sends the PCI data to the payment processor directly.
3. They grab the payment info and do whatever needs doing... then
4. The Payment processor then REDIRECTS the client back to your server with some context so you can match up the client, payment, etc.  
   
5. You get the request from the client and do whatever you need to tell them if it worked or not.

Take a look at: https://stripe.com/docs/security for an overview. And then look at https://stripe.com/docs/stripe.js as an easy way of handling the details.

All the other providers provide similar capabilities -- and if they don't, change provider! I looked by Authorize has moved all the docs around so I grabbed the above from Stripe instead.

We are a Stripe customer and I've been a Braintree and Authorize.net customer in the past.

Good luck,

Brendon.

On Thursday, August 18, 2016 at 4:41:23 PM UTC-7, Phil wrote:

Have a few cases where it is critically important to flush the output of 'render' immediately.  For example:


 def place_order
  if validate_and_record_order?
   render :text => "OK"
  else
   render :text => "ERROR"
  end
  # DESPERATELY WANT TO FLUSH OUTPUT HERE!
  # Do lots of talking with banks, send out mailers, etc.
 end


Another wrinkle here is we can't store the customer's banking information to run as a deferred task.  Ideally we just want to say 'flush the output' after the 'if' block.  Even if there's an exception after the 'if' we still don't want them to get a 500, we want them to get the OK/ERROR.

The problem we have is the people connecting to our app are sometimes timing out (they have a short timeout) and think the order failed when in fact it was recorded, customer was charged, etc.  I'm a little hesitant about using Thread.new, but perhaps that's the only reasonable way to flush the output early?

btw- This is Rails 4.0.x, Apache+Passenger.

Thanks!


Phil

--
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-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/52341f3a-7cf6-40a1-8914-1cb162210599%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.