edamov
No errors, empty result
On a test server, $client->push() works correctly and notification is received.
On the production server, nothing happens. There are no errors in the error log, but $client->push() returns an empty array.
What could be causing this? Is there a verbose or debug mode?
+1 For this problem.
- APN in production mode.
- Certificate in date.
- Been working for ~10 months no problems.
about 2 days ago started receiving this response on all $client->push(); actions
Pushok\Response::__set_state(array(
'apnsId' => '',
'deviceToken' => 'secret',
'statusCode' => 0,
'errorReason' => '',
'error410Timestamp' => '',
)),
Usually it will at least will spit out an error and statusCode.
Managed to fix the above problem by updating to <0.12.* and adding:
$this->client = new Client($this->authProvider, env('APN_PRODUCTION'), [CURLOPT_SSL_VERIFYPEER => false]);
when creating the client as mentioned in this comment: https://github.com/edamov/pushok/pull/110#issuecomment-773667592
Experiencing the same problem for over +1 week (with laravel-notification-channels/apn), ignoring the ssl wil work for now. But I do not like this solution...
I think it's a better approach using:
$this->client = new Client($this->authProvider, env('APN_PRODUCTION'), [CURLOPT_CAINFO => 'GeoTrust_Global_CA.pem']);
with an up to date cacert.pem to avoid disabling the authenticity verification of the peer's certificate. More info here:
Communication between your provider server and APNs must take place over a secure connection. Creating that connection requires installing the GeoTrust Global CA root certificate (until March 29, 2021) and the AAA Certificate Services root certificate (starting March 29, 2021) on each of your provider servers.
Seems the problem and the possible solution is described in #109 in the comment Also you can find the description in the Apple documentation:
One common OpenSSL error is verify error:num=20:unable to get local issuer certificate.
That message means that one or more of the certificates from the server could not be verified because the issuer (root or intermediate) certificates were not found.
The CAfile argument to s_client specifies the trusted root certificates to use to verify the server certificate. The trusted root certificate for the push servers is the GeoTrust or Entrust root certificate mentioned previously.
I am also having this issue. Anyone can please help, really appreciate it.
I am using "Token based/p8" authentication on my local (mac) a. Then on Production I was using the same setup, but it is not sending anything or rather I am not receiving anything after the $this->client->push() (just nothing happens).
I even added the cert and renamed as their corresponding hash ee64a828.0 (unable to symlink it though) and updated the client parameter, but it still doesn't work.
$cert = '/etc/ssl/certs';
$this->client = new Client($this->authProvider, $production = true, [CURLOPT_CAPATH => $cert]);
Details:
edamov/pushok: v 0.13
php 7.3.10
curl 7.75.0 (x86_64-redhat-linux-gnu) libcurl/7.75.0 NSS/3.36 zlib/1.2.7 libpsl/0.7.0 (+libicu/50.1.2) libssh2/1.9.0 nghttp2/1.33.0
Release-Date: 2021-02-03
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL UnixSockets
Note: Note: But the weird part is, another service of ours, is working by just using token based/p8.
Just a friendly note: we were getting this same exact result and, upon further investigation, I was able to determine that our libcurl version did not support HTTP/2.
Just a friendly note: we were getting this same exact result and, upon further investigation, I was able to determine that our libcurl version did not support HTTP/2.
What libcurl version are you using?
Just a friendly note: we were getting this same exact result and, upon further investigation, I was able to determine that our libcurl version did not support HTTP/2.
What libcurl version are you using?
7.47.0
Just a friendly note: we were getting this same exact result and, upon further investigation, I was able to determine that our libcurl version did not support HTTP/2.
What libcurl version are you using?
Keep in mind, I'm not saying that's your issue, but I was receiving the exact same result as everyone else: an empty array was being returned from $client->push();
Your mileage may vary
you can use curl_version() to get back information about your current curl library attached to your fpm or whatever you're using. in my case, the string http2 does not appear in curl_version()['protocols']. There is a way to use a bitwise AND operation with curl_version()['features'] and some curl http version 2 constant (I can't remember off the top of my head) and that should tell you if your libcurl was built with http/2 support. The way I was able to find out our libcurl version was outdated was that I simply tried the cli:
curl --http2 https://google.com
That failed miserably.. it reported that it was an "Unsupported protocol". Often times on servers the curl CLI depends on the same library as your PHP installation, so that led me to test out our php libcurl version. Sure enough it didn't support HTTP/2.. so I have reason to believe the curl CLI tool relies on the same lib as my php-fpm.
@wmerfalen thank you, indeed in my case the production server does not support HTTP/2. I suggest $client->push() should return at least some error code indicating a problem.