Last modified: 2010-11-16 19:22:08 UTC
Were getting reports of missing ssl certs post captcha trigger. Detail below: "Hello, I tried to donate via my MasterCard but when I entered my credit card info a dialog came up saying some information will not be submitted securely and the SSL certificate on the page was lost. The page was then asking me to verify the words but since the SSL certificate was lost I was not comfortable submitting my credit card information again. I value Wikipedia so I will mail a check instead." "When the page is first loaded, the verification image is not shown, only is shown after clicking the donation button but shows again the form to enter data and deletes my credit card number, security code and valid until, so so it makes me angry. i hope you improve the page so the verification number is shown from the very beginning."
I have confirmed that there is some SSL issue when a user is presented with a captcha on the credit card form. It appears that communication pulling the captcha interface from reCaptcha is /not/ happening in SSL, which will cause some browser configurations to complain and even to potentially not show non-SSL content.
I've now fully identified the issue. The code currently uses $wgProto to determine whether or not to communicate with reCaptcha in HTTPS or HTTP. Becase we are terminating SSL before MediaWiki sees the traffic (on our payments cluster), the protocol is being set to regular HTTP. I am going to add a configurable variable in the DonationInterface to explicitly set whether or not to use HTTPS and update the reCaptcha code to rely on that instead.
This is resolved in r76717 of trunk, will be merging to deploy later today with Kaldari's changes
This was deployed at 11:20am PST on 11/16/2010. Judging by the minfraud logs on the payments cluster, users are seeing captchas and succesfully passing them.
