SWTC | Password Set Error
Created: 22/May/17
Updated: 07/Aug/17
Resolved: 07/Aug/17
Status: Resolved
Hi Team,
We have had a few calls about people receiving the reset password (see below example) but when they click on it they get an internal server error (see snip below)
Can we please get this checked as while with one user it could be an anomaly we were now able to replicate it inhouse.
Much thanks in advance for the assist.
Cheers
Comment by James Davidson [ 22/May/17 ]
I’m actually already looking into this. I noticed the errors in SumoLogic. Not sure what’s going on.
Comment by James Davidson [ 22/May/17 ]
Ok, looks to be a problem with the Gigya integration. I’ll have a chat with @andrewda tomorrow.
Comment by James Davidson [ 25/May/17 ]
Hi Chiara,
At first glance this seems to be a bug in our integration with Gigya (the authentication system).
This might be a bit tricky. Let me see if I can find a work-around. I’ll get back to you first thing tomorrow morning.
James
Comment by James Davidson [ 26/May/17 ]
Hi Chiara,
Brendan and I had a look last night but couldn’t find an easy fix.
I had to take care of some other things this morning but I will make fixing this problem my priority for this afternoon.
James
Comment by James Davidson [ 29/May/17 ]
ubuntu@DIGSFP07:/mnt/c/Users/jamesd$ curl -v –silent https://gigya.com/
Hostname was NOT found in DNS cache
Trying 74.120.149.12…
Connected to gigya.com (74.120.149.12) port 443 (#0)
successfully set certificate verify locations:
CAfile: none
CApath: /etc/ssl/certs
SSLv3, TLS Unknown, Unknown (22):
SSLv3, TLS handshake, Client hello (1):
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Closing connection 0
Comment by James Davidson [ 29/May/17 ]
Hi Chiara,
I believe the only customer affected today was a chap called Denis based on what I can see in the server logs. I tried this afternoon to reset my password and seemed to work just fine. Weird!
This bug has me stumped. Hopefully the Gigya team (our authentication service provider) might be able to shed some light on the situation. I’ve raised a support ticket with them.
James
0430015575
Comment by James Davidson [ 29/May/17 ]
Ok, this is interesting. Over the last week, all twenty-three server errors have come from ip-172-21-128-125, not from ip-172-21-128-233. But surely they are the same?
_collector=ip-172-21-128-* AND _source=NginxAccess AND “POST /actions”
| where status_code >= 500
| count by _collector
I’ve turned the ip-172-21-128-125 server (ec2-prd-ttc-craft-a) off for now. Let’s just run with ip-172-21-128-233 (ec2-prd-ttc-craft-b) for a bit and see how we go.
Comment by James Davidson [ 30/May/17 ]
It looks like shutting off ip-172-21-128-125 (ec2-prd-ttc-craft-a) meant that we didn’t have any errors today. I wonder what the difference is between the two servers?
Comment by James Davidson [ 29/Jun/17 ]
The Pixel & Tonic team released version 2.6.2985 of the Craft CMS yesterday. In the release notes they mention that they fixed a similar issue ‘Fixed a bug where users would get an “Invalid Verification Code” error when clicking on the link in a verification email.’. This is interesting. Especially when you check what they did in the `UserRecord.php` in the commit: https://github.com/craftcms/cms/commit/3373da4e5071 . Hopefully the change they’ve made won’t interfere with our Gigya integration.
Comment by James Davidson [ 04/Jul/17 ]
We can work around this issue by going to /ttccontrol/settings/plugins/gigya and changing the path to the certificate authority file. Replace the default value /var/www/sevenwesttravelclub.com.au/plugins/gigya/resources/Gigya_PHP_SDK/cacert.pem with /etc/pki/tls/certs/ca-bundle.crt .
Comment by Joel Hopson [ 31/Jul/17 ]
James can I resolve this ticket?
Comment by James Davidson [ 07/Aug/17 ]
Yep, please mark this as resolved. It is a known bug for which a work-around is documented in Confluence.
Generated at Fri Feb 02 23:59:35 AWST 2018 by James Davidson using JIRA 7.3.6
James Davidson 