Api eventbriteapi.com -Telegram bot

[lenotizie]

Ciao a tutti,
Sto sviluppando un bot su telegram che prende tutti gli eventi relativi ad una città e una categoria inseriti dall'utente da telegram.

il BOT è questo: @ElencoEventiBot

Sul mio pc in locale funziona perfettamente, mentre su altervista sembra che ci siano problemi con questi comandi:

$eventiUrl = "https://www.eventbriteapi.com/v3/events/search/?sort_by=date&location.address=".urlencode("torino")."&location.within=50km&categories=103&token=MIOTOKEN";
$contents = file_get_contents($eventiUrl);
		
$eventi=json_decode($contents,true);

In particolare sembra che in qualche modo altervista non riesca ad eseguire questa funzione:
file_get_contents($eventiUrl);

C'è qualche limitazione su altervista per accedere ai contenuti di un altro server?
Ho già fatto l'autenticazione con l'sms per abilitare la funzionalità server to server.

Ripeto che sul mio computer in locale funziona benissimo, quindi è qualcosa relativo ad altervista.

Mi potete aiutare a risolvere per favore?
Grazie.

[pcrebuilding]

Ho lo stesso problema anch'io, il log dell'errore è:

file_get_contents(http://ipinfo.io/<IP>/json): failed to open stream: HTTP request failed! HTTP/1.0 500 SSL negotiation failed:

ha sempre funzionato (dopo aver abilitato l'accesso ai server esterni), da un po' dà questo errore, tu hai risolto?

[darbula]

http://forum.it.altervista.org/php-m...ml#post1354781
Anche se il problema della libreria da un altro tipo di errore.. Cmq. Prova

[pcrebuilding]

Ciao grazie del supporto, il problema è il redirect esplicito che avviene sul sito destinazione, anche se uso http (prima era facoltativo ed io potevo decidere se usare http o https in un file di configurazione) da un po' pare si possa utilizzare solo https (non c'è spiegazione sulla documentazione developers sul sito), in pratica:
- chiamo http://<url>
- il server risponde con un redirect 302 passando a https://<url>
- i proxy locali <path>/Protocol/http.pm bloccano la richiesta resettando la comunicazione.
Se come suggerito il problema è nelle librerie Openssl 1.0.1 devo valutare se il passaggio a MySQL 5.6 è 'indolore', magari darbula puoi aiutarmi tu? Grazie per avermi segnalato il thread

[darbula]

Il redirect da http a https è causato da loro e non da altervista che non ha colpa..
Ho appena provato con MySQL 5.1 e MySQL 5.6 con il codice php che ti ho linkato prima... https con quel sito funziona solo con MySQL 5.6.. purtroppo non so come assisterti è solo una tua scelta se effettuare l'upgrade a MySQL 5.6 o no (però già sai che tipo di problema è)

[pcrebuilding]

In realtà qualsiasi sito che fa il redirect su https può dare quel problema se si usa MySQL 5.1 e con i tuoi test mi confermi che l'errore sta nelle librerie Openssl 1.0.1 sui sistemi AV. Io uso MySQL 5.5 su server di test e funziona ma non ho proxy, firewall o altri filtri. Ora valuto l'upgrade alla 5.6, farò delle prove, nel frattempo magari mi viene in mente qualcos'altro.
Grazie per il supporto

[darbula]

Dipende se https usa tsl 1.2 ad. es https://www.google.it/ non lo usa e si vede che altervista non produce alcun errore .. Cmq. La labreria 1.0.1 è quella aggiornata.. Il redirect indica un renindirazzamento al cliente (non c'entra che da http lo trasformi in https... Anche perché altervista ha il blocco dei redirect per php) qualche altro server con php potrebbe fare il redirect ma qui no.
Nei server online è prassi bloccare follow_location (redirect per php)
http://php.net/manual/en/context.http.php

[pcrebuilding]

darbula ho fatto delle verifiche aggiuntive e ho provato ad usare curl passando direttamente https (quindi senza redirect),su due url diversi il risultato è che in uno dà errore SSL, nell'altro recupera i dati:

$curl_options = array(CURLOPT_RETURNTRANSFER => true,
CURLOPT_HEADER => false,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_ENCODING => "",
CURLOPT_USERAGENT => "",
CURLOPT_AUTOREFERER => true,
CURLOPT_CONNECTTIMEOUT => 120,
CURLOPT_TIMEOUT => 120,
CURLOPT_MAXREDIRS => 10,
CURLOPT_SSL_VERIFYPEER => true,
CURLOPT_SSL_VERIFYHOST => 2,
CURLOPT_VERBOSE => 1);

$curl_session=curl_init($url);
curl_setopt_array($curl_session,$curl_options);
$curl_content=curl_exec($curl_session);
$curl_error=curl_errno($curl_session);
$curl_error_message=curl_error($curl_session);
$curl_header=curl_getinfo($curl_session);
curl_close($curl_session);

var_dump($curl_error_message);
var_dump($curl_content);

con

$url = https://ipinfo.io/8.8.8.8/json (il DNS di Google ma vale per qualsiasi IP)

dà l'errore

Unknown SSL protocol error in connection to ipinfo.io:443

mentre con

$url = https://fonts.googleapis.com/css?fam...n+Sans:400,800

recupera i dati (in entrambi i casi è plain-text)

Ho configurato la verifica SSL e HOST, ignorandola il risultato non cambia. L'unica cosa che mi viene in mente è che il server destinazione usa TLS 1.1 o 1.2 e rifiuta connessioni TLS 1.0, non so se la versione di OpenSSL usa TLS 1.0 (potrebbe essere questo il problema). Qualche idea?
Ciao e grazie per il supporto

[darbula]

<?php
echo "openssl version text: ". OPENSSL_VERSION_TEXT ."\n";
?>

ipinfo rifiuta connessioni http ma usa un tsl aggiornato (tsl 1.2) che dunque inibisce anche connessioni https con tsl inferiore a 1.2..
CURLOPT_FOLLOWLOCATION => true gli host in cui viene eseguito il codice php protebbe essere bloccato (resta su false).

[pcrebuilding]

Ok chiarissimo. Grazie per il supporto, toccherà inventarsi qualcos'altro, non è un errore bloccante ma mi serve per le statistiche.
Saluti