I'm trying to read public data from smartCard with wampServer, PHP 5.4, winSCard and php_pcsc.dll for PHP5 (http://pecl.php.net/package/pcsc/0.2/windows).
I found this project http://hanez.org/pcsc-for-php.html (code is for php4 but my dll is for php5) and tried to do in localhost but php throws me this error "Call to undefined function SCardListReaders()".
When I see de phpinfo I can see the extension enabled but it hasn't any information (I can't put images because I haven't points), only has table headers
PC/SC
| PC/SC support | enabled |
Thank you
You may be getting an error because the function is actually scard_list_readers() not SCardListReaders() as the error shows in your post.
But before you can use most of the functions, you need to establish a context first.
Try:
$context = scard_establish_context();
$readers = scard_list_readers($context);
print_r($readers);
// then when you have your card reader's identity from $readers
$connection = scard_connect($context, 'YOUR CARD READER HERE');
$response = scard_transmit($connection, 'pdu string');
Related
I'm getting this error after upgrading from php5.6 to php8.2 on windows. Looks like the new openssl dll does not support splitting of my apple push notification certificate pk12 file into separate cert and key array. Any ideas how to get it to do that ? There is another similar question on stackoverflow but it only discusses ubuntu, not windows. I tried to ask a question to the contributors of the ubuntu related article but i had insufficient permissions.
$p12_filename = "..\\path\\to\\pass.com.testpass.p12";
$p12data = file_get_contents($p12_filename);
$p12Password = 'MyPassword';
$rp12 = array();
// following function works in php5.6 but fails in php8.2
$rc = openssl_pkcs12_read($p12data, $rp12, $p12Password);
$cert_data = $rp12['cert'];
$cert_key = $rp12['pkey'];
So according to the link above supplied by Jacob Mulquin
, the openssl component supplied in PHP8.2 has a legacy function removed which prevents it from parsing certain types of certificate that were previously supported. As i don't need the latest language enhancements of PHP8.2, the quickest solution for me ( on windows ) was to replace PHP8.2 with the next most recent release, PHP8.1.13.
I have developed a website using PhalconPHP. the website works perfectly fine on my local computer with the following specifications:
PHP Version 7.0.22
Apache/2.4.18
PhalconPHP 3.3.1
and also on my previous Server (with DirectAdmin):
PHP Version 5.6.26
Apache 2
PhalconPHP 3.0.1
But recently I have migrated to a new VPS. with cPanel:
CENTOS 7.4 vmware [server]
cPanel v68.0.30
PHP Version 5.6.34 (multiple versions available, this one selected by myself)
PhalconPHP 3.2.2
On the new VPS my website always gives me Error 500.
in my Apache Error logs file: [cgi:error] End of script output before headers: ea-php70, referer: http://mywebsitedomain.net
What I suspect is the new database System. the new one is not mySql. it is MariaDB 10.1. I tried to downgrade to MySQL 5.6 but the WHM says there is no way I could downgrade to lower versions.
this is my config file:
[database]
adapter = Mysql
host = localhost
username = root
password = XXXXXXXXXXXX
dbname = XXXXXXXXXXXX
charset = utf8
and my Services.php:
protected function initDb()
{
$config = $this->get('config')->get('database')->toArray();
$dbClass = 'Phalcon\Db\Adapter\Pdo\\' . $config['adapter'];
unset($config['adapter']);
return new $dbClass($config);
}
And in my controllers...
for example this code throws Error 500:
$this->view->files = Patients::query()->orderBy("id ASC")->execute();
but changing id to fname fixes the problem:
$this->view->files = Patients::query()->orderBy("fname ASC")->execute();
or even the following code throws error 500:
$user = Users::findFirst(array(
"conditions" => "id = :id:",
"bind" => array("id" => $this->session->get("userID"))
));
is there a problem with the compatibility of PhalconPHP and MariaDB?
MariaDB was built to be mostly compatible with MySQL clients, it's unlikely to be the reason for your problems. If you're still concerned, you can switch from MariaDB to MySQL (and vice versa) by dumping (exporting) your tables, switching over, and importing them again.
More likely, the error line you're showing indicates that your new server is actually running PHP7 (ea-php70) and not PHP5.6 as you thought you selected.
The error End of script output before headers means the CGI script (in this case PHP7 itself) did not produce any HTTP headers before terminating. I suspect that your version of PhalconPHP is incompatible with PHP7 and therefore just crashes immediately.
If cPanel doesn't let you properly configure your infrastructure you likely have no other option but to drop it and set up your stack manually. But since you probably paid for cPanel, you could try opening a support ticket with them first: https://cpanel.com/support/
Most probably old phalconPHP version it does not support latest php 7.x version i guess. as i remember I have read similiar problem in another blog question.
I get a 500 server error when running the docusign php sdk example code.
I've ensured that I am using a PHP version above the required version. I am using PHP v 5.3.5, and the required version is 5.3.3. I have also ensured that curl and json are enabled. I have cut the example code listed on the github down to just these few lines, and still get the error. When I comment out the part that uses name spacing, the error stops occurring.
<?
require_once( 'includes/docusign-php-client-master/autoload.php' );
class DocuSign {
private $config;
public function __construct( $email, $password, $integratorKey ) {
// error happens on next line
$this->config = new DocuSign\eSign\Configuration();
}
}
$docusign = new DocuSign( $myemail, $mypassword, $myintegrationkey );
?>
I have replaced my actual email, pass, and key with variables. Any ideas as to why I am getting the error?
It turns out the required PHP version listed on the SDK is wrong. The SDK uses the array creation shorthand [], which requires PHP version 5.4 or higher.
In my experience, error 500 will often happen if newly uploaded files don't have the appropriate permissions on the server. Apply appropriate chmod permissions from the bash console (or FTP server) to allow Apache to read the files.
I'm connecting to DB2 DB
$sql = 'CALL procedures.name(1,1,'text',1,1,'2017-08-30','2017-08-31',?,?)';
try {
$con = new PDO("idb:all_the_connections_stuu",'user','pass',
[
PDO::ATTR_PERSISTENT => FALSE,
PDO::ATTR_ERRMODE => PDO:ERRMODE_EXCEPTION,
PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL,
PDO::ATTR_AUTOCOMMIT => 0
]
);
$stmt = $con->prepare($sql);
$stmt->bindParam(1, $errorNumber, PDO::PARAM_INT); //also trying without PDO::params
$stmt->bindParam(2, $errorCode, PDO::PARAM_STR, 800); //and with |PDO::PARAM_INPUT_OUTPUT
$stmt->execute(); //return *TRUE*
var_dump($errorNumber); //return NULL
var_dump($errorCode); //return NULL
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC)); //returns Error
$stmt->closeCursor();
$stmt = null;
} catch (PDOException $e) {
echo ($e->getMessage());
}
and got this error:
Fatal error: Uncaught PDOException: SQLSTATE[57017]: <<Unknown error>>: -332
[IBM][CLI Driver][DB2] SQL0332N
Character conversion from the source code page "" to the target code page "" is not supported.
SQLSTATE=57017
(SQLFetchScroll[-332] at /home/user/shared/PDO_IBM-1.3.4/ibm_statement.c:1306) in /var/www/html/server/testsIBM/index.php:80
Stack trace:
#0 /var/www/html/server/testsIBM/index.php(80): PDOStatement->fetchAll(7, 0)
#1 {main}
thrown in /var/www/html/server/testsIBM/index.php on line 80
If I connect with db2_connect
$con = db2_connect("DATABASE=DB2D;HOSTNAME=10.243.13.65;PORT=5000;PROTOCOL=TCPIP;USERNAME=asdf23;PASSWORD=asdfasf1","", "")
and output db2_client_info($con) and db2_server_info($con) I see that CONN_CODEPAGE from client = 819 and DB_CODEPAGE from server = 1208.
How can I set CONN_CODEPAGE in my client? I already set LANG in CentOs locale, but still got error of character conversion.
______upd:
Current $LANG = en_US.utf8 (also in locale -a I have en_US, en_US.iso88591, en_US.iso885915, en_US.utf8)
No matter what $LANG is set output from db2_client_info($con) still the same:
["APPL_CODEPAGE"]=>
int(819)
["CONN_CODEPAGE"]=>
int(819)
And same error about Character conversion from the source code page
I'm using PHP+Apache. Apache httpd.conf defaultCharset setting different locales didnt't change anything.
In php code setlocale don't changing anything either.
I think this setting store somewhere else, and ibm_db2 or pdo_ibm drivers use it. =|
____upd2
The only way I found out - change DB2CODEPAGE from installed db2 client. But I don't have installed client. I'm using inly libraries.
Now i installed v11.1.2fp2_linuxx64_client.tar.gz (1.03 GB). But i can't laucn db2 client. Think I need another new question =\
____upd3
After all manipulations with CentOs, apache locales - I still get -322 exception. No matter what I changed - db2_client_info($con) still shows me 819 CodePage. And all work nice, until fetch()/fetchAll()
CentOs 7.3, PHP 7.1.8 with PDO_IBM 1.3.4-patched, and ibm_db2. BUT I make this modules from PECL sources (cause server doesn't have internet connection).
And I also don't have any DB2 products installed on mine application server (thats why I decide that CodePage getting from CentOs locale). It seems from your test, that DB2 data server client is required?
If you are using the "IBM DB2 Data server driver for ODBC and CLI" specifically for your Centos client, you can try ensuring that the environment for the account that runs PDO and connects to DB2 has DB2CODEPAGE=1208. You can export this variable (only for this specific client type) via:
export DB2CODEPAGE=1208
and restart whatever process(es) are involved in your solution.
Also for the account(s) you are using to connect to DB2, their client LANG setting should be an UTF-8 locale (and that locale needs to be installed on your Centos). Use the command locale -a to show which locales are installed, and choose one which has an utf-8 for your territory. For example if your $LANG was en_us then change it to en_us.utf-8, if that locale is installed. Export that $LANG in the shell startup of the relevant accounts and restart your apps.
If you are using a full-DB2 client (or the local DB2-client on a DB2-server on unix) you also need to correctly set the LANG variable to a value compatible with the encoding of your DB2 database. Otherwise you will either get codepage conversion at run time, which may have unexpected results, including exceptions if no suitable conversion exists.
For information:
Tested PHP 7.0.20 with PDO_IBM 1.3.4-patched, and ibm_db2 , with DB2 V11.1.2.2 , on ubuntu 16.04 LTS - appl_codepage = conn_codepage = db_codepage.
Also tested PHP 5.3.3 with PDO_IBM 1.3.4-patched, and ibm_db2, with DB2 V10.5.0.7, on RHEL 6.9: appl_codepage = conn_codepage = db_codepage.
Also tested PHP 5.4.16 with PDO_IBM 1.3.4-patched and ibm_db2, with DB2 V11.1.2.2 data server client , on CENTOS 7.3: appl_codepage = conn_codepage = db_codepage.
Note: Ubuntu , RHEL, Centos had default locale set for utf-8, before building pdo_ibm from github, or installing ibm_db2 with pecl. All local and remote databases had utf-8 encoding.
You may find, trying the tips described here (with more explanations) very useful, notably :
Make the source and target code pages compatible with each other.
Search the DB2 information Center
using the phrase
"Code set Territory code" for compatibility of the supported DB2 code
pages. To set the client's code page compatible with the database code
page:
On Unix platforms, set the LANG, LC_CTYPE or LC_ALL environment
variable to a locale whose code page is compatible with the database
code page. Consult the platform documentation to see the valid locale
names and the code page associated with each of them.
On Windows
platforms, set the DB2CODEPAGE registry variable to override the
client's code page with a value compatible with the database code
page.
For database manager code page support, search the
DB2 information Center
using the phrase
"Code set Territory code". For federated system users, see the
Federated Systems Guide for data source code page. If the source and
target code pages are compatible, then DB2 currently does not support
this particular code page conversion. Contact your technical service
representative to determine if such support can be added.
Recently I asked my hosting company to setup a new package and since then my existing package is now giving me errors with anything to do with using openSSL.
For instance, I have a function to generate a GUID:
function generateGUIDV4($data)
{
assert(strlen($data) == 16);
$data[6] = chr(ord($data[6]) & 0x0f | 0x40); // set version to 0100
$data[8] = chr(ord($data[8]) & 0x3f | 0x80); // set bits 6-7 to 10
return vsprintf('%s%s-%s-%s-%s-%s%s%s', str_split(bin2hex($data), 4));
}
$newID = generateGUIDV4(openssl_random_pseudo_bytes(16));
This now throws an error: Fatal error: Call to undefined function openssl_random_pseudo_bytes(). From what I've researched this has to do with Fatal error: Call to undefined function openssl_random_pseudo_bytes().
Now I'm also getting an error now when I call any web services from my application which again point to the openSSL.
Error:
Objectfaultcode: "WSDL"faultstring: "SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://*******'"__proto__: Object
.I've hidden the web service as it's not public. From what I've researched this points to OpenSSL again: SOAP-ERROR: Parsing WSDL: Couldn't load from <URL>.
PHP Ini is showing openSSL IS installed
OpenSSL support enabled
OpenSSL Version OpenSSL 0.9.8b 04 May 2006
Anyone have any ideas or point me in the right direction? I've got the hosting company looking into this.
I've fixed this and it had nothing to do with the hosting company.
I published a new version of the site, but in the publish profile I told it to delete all files which deleted the .htaccess file which contained the version of PHP in.
Unfortunately, I needed version 5.4 or above to run my code but since the file was removed it dropped down to 5.2 of PHP.
So I've uploaded a new .htaccess file with the correct version in and everything is working.
Hopefully this may help someone if they're as daft as I am.