i cant use * or ? for change directory
chdir ("c:\win*\system*");
how it work, i cant guess full name of windows whats that, for example WIN or winxp or win7.
or how to guess whats full name of that
chdir() to a random wildcard directory supposed to be chosen by the system for you in case of collissions? Really?!
Paths are explicit. It's here or there... not somewhere, just look it up for me. And why try to access system directory from PHP in the first place? Got permissions setup right? Or you want to make modifications to users that use your script and can't guess the right path yourself?
Imagine that this guy's chdir() has to list paths in multiple
folders everytime to do one simple operation. Let's talk security,
performance... but most of all... common sense.
The things I see on SO...
PS: I -1'ed you. This question should not be asked by a developer with minimal understanding of... development stuff. Want to inject stuff into system dir, don't use PHP.
You are likely misunderstanding that chdir is equal to windows chdir (cd) in the windows operating system. But it is not.
However that should not pose you any problems because PHP and the shell can work together easily:
chdir(rtrim(`cd c:\win*\system* & cd`));
echo getcwd();
Example output:
C:\WINDOWS\system
If you know what command is for what, you can easily solve the issue.
Stumbled upon this:
CHDIR allows wildcards as path names, and changes to the first directory found whose name matches the wildcard specified. This is convenient with long directory names, as it is only necessary to type enough of the path to uniquely identify the directory, and then add a trailing "*" to the path name.
http://www.rcramer.com/tech/windows/cmd/ad.html#CHDIR
It is not PHP though...
Related
Good day! I have hit a wall.
I'm trying to get PHP to load a file from a folder on another server and have tried so many methods and variations of permissions (IIS/PHP use Windows Authentication) but have yet to find a solution. I am so close I can taste it.
The files are in a folder on the other server e.g. \\otherServer\my_photos
In order to access them this I have created a symbolic link on the server hosting the PHP site, e.g.
C:\my_photos > \\otherServer\my_photos
I am then doing various tests to determine whether or not the page has access, e.g:
$path = 'C:\\my_photos';
$isReadable = is_readable($path);
var_dump($isReadable);
The above returns TRUE.
However, if I do this:
$path = 'C:\\my_photos\photo_1.jpg';
$isReadable = is_readable($path);
var_dump($isReadable);
It returns FALSE.
The permissions on the file photo_1.jpg are identical to the folder my_photos so I suspect the cause is something else, such as some sort of security restricting affecting access to files on other servers, but I am out of ideas. I will reward any assistance with virtual gratitude and am even willing to draw you a picture with a personal message.
UPDATE:
If we switch Windows Authentication off and Anonymous Authentication on (running under the ApplicationPoolIdentity) it works, which seems to suggest that a) it's not some confusing cross-server security issue and b) the problem may relate more to the way PHP/fastCGI impersonates Windows users. Will switch back to Windows auth and keep testing!
I managed to get this working (after three days of head-scratching) by changing the FastCGI 'protocol' from NamedPipe to TCP, as detailed in this answer:
https://stackoverflow.com/a/41367358/1358231
I'm still not entirely sure why this works but will keep looking. In the end there was no need for a symbolic link (or mapped drive) - we could access the remote file directly via the UNC path.
You forgot to escape the slash preceding the directory name. It should look like this.
$path = 'C:\\my_photos\\photo_1.jpg';
$isReadable = is_readable($path);
var_dump($isReadable);
Every slash gets escaped, so, \otherServer\my_photos would become:
$path = '\\\\otherServer\\my_photos';
Note the four slashes before the server name, and the two slashes before the directory name.
Let's say we have a web directory with the following paths:
framework/
index.php
...
instance/
index.php -> ../framework/index.php (symlink)
...
If we now make a request for (...)/instance/index.php PHP will resolve the symlinks and set __FILE__ as (...)/framework/index.php
Is there a way around this so e.g. dirname(__FILE__) would be (...)/instance?
EDIT: Since it has been pointed out, I'm actually not sure if PHP itself is resolving the links or something else. In my case I'm using nginx as a webserver with php-fpm as FastCGI.
(The background is that I want to have multiple instances of a CMS or Framework referencing a common code base.)
The best approximation for your case is dirname($_SERVER['SCRIPT_FILENAME']) to get the "instance" dir, if you can live with the general warning in the doc about the $_SERVER vars:
There is no guarantee that every web server will provide any of these;
servers may omit some, or provide others not listed here.
Also, the PHP manual does not explicitly promise that symlinks will be preserved, but that seems to be the case (unless of course your server thinks otherwise). See also this answer.
(Note: this also works in CLI mode. If the script was launched via a relative path (to the CWD), PHP will keep it that way, so you may end up with "." then.)
However, for the general problem (of getting any script's dir with symlinks preserved), this doesn't work. It only works for the script that has been reached via HTTP. Since any other scripts you include later on will all have the same $_SERVER['SCRIPT_FILENAME'] (of course), regardless of their location, dirname($_SERVER['SCRIPT_FILENAME']) will yield the wrong dir if they are located elsewhere...
I don't think PHP has a solution for that today (as of v7.2).
(And you were correct initially: PHP is doing the symlink-resolving for __FILE__, irrespective of your server. And it's unlikely that this would ever change, because it has stayed this way for too long (and too much code depends on it), even though there's realpath() if we wanted the resolved path, while there's no bullet-proof solution for the symlinked case.)
Gone through related posts and found turning allow_url_include will does the trick. However when I did this :
remote file file.php at http://www.courierscripts.com
$content = file_get_contents('http://www.courierscripts.com/folder/file.php');
on my functions.php, was not able to use the functions of file.php. I also don't want to change my file.php to file.txt because everyone can see it.
Any other way?
If the file is on the same server, use absolute or relative path to it, not an url. Otherwise:
Short answer:
No, it's not possible.
Long answer:
Actually possible with conditions but I bet you won't like them.
It's obviously impossible if you don't have access to the target server (otherwise storing passwords in php config files like Wordpress does would be just one big security flaw).
First of all, file_get_contents returns a string. So you could eval it, but eval is very bad (you can search SO for the clues why).
OK, suppose you agree to eval what's coming from that server even after considering that someone might change the code and do whatever he wants on your machine. BUT you make an http request that is handles by the server (Apache, Nginx or whatever else).
The server knows that *.php files should not be handles as static files. For example, fastcgi. You can turn that off, for example, with RemoveHandler in Apache. But that would let everyone see the source code of files you expose this way.
So, after removing handlers and evaling the result, you could get the result. But be ready that someone you work with will punch you in the face for doing that ;)
UPD
For code sharing, use Composer to create a package and use it as a dependency.
I have a file located in my CakePHP root folder placed under a folder named cron. Path is:
c:/wamp/www/project/cron/daily.php
This file requires another file placed inside vendor folder of cake structure, like this:
require("/../vendors/phpMailer/class.phpmailer.php");
And i run this daily.php from task scheduler. This is the scenario in my development site.(Windows system). It works fine as expected. When i migrated the project to Ubuntu(production site), the require statement started causing issues; it cant find the required file. I made a small change there, like this:
require("../vendors/phpMailer/class.phpmailer.php"); <= removed the preceding slash
And it worked. So my doubt is, is there a difference in how parent directory notation work in widows and Linux? If so, how can i overcome this? Its not feasible to remove a slash every time I move the project from my development site(windows) to production site (Linux).
I tried this:
require("./../vendors/phpMailer/class.phpmailer.php");
It worked in linux. But gave "no such file directory" error in windows. It seems windows works only with:
require("/../vendors/phpMailer/class.phpmailer.php");
Solution
From #TWCrap's help problem was solved as follows:
require(dirname(__FILE__)."/../vendors/phpMailer/class.phpmailer.php");
It works in both windows and linux(* tears of joy *). But in windows it produces path as:
C:\wamp\www\project\cron/../vendors/phpMailer/class.phpmailer.php
This path looks ugly and i hope it wont cause probs in future!
-Thanks guys!
AS i remember, when you put 1 dot infront of the line, you start at the directory you are. So then the line must look like this:
require("./../vendors/phpMailer/class.phpmailer.php");
And that should work at windows and linux....
Do not use absolute paths if you really do not need so. It's safer and better to correctly set include_path so in case of move you just need to adjust one setting instead of digging thru whole project and all its files.
So my doubt is, is there a difference in how parent directory notation work in widows and Linux?
Paths starting with / (i.e. /foo/bar) are absolute paths as starting / indicates root folder. On Windows you got drive letter there.
I also suggest using require_once to avoid duplicated requires (which is OK if you mix HTML with code, but "spaghetti code" is not recommended anyway), but may cause problems with code
The problem is that, at least on a UNIX system, when you start with a preceding slash on a file path you start at the root.
You should either write ./../* or just ../ ond both systems. It should work both.
Why did all my require_once calls that are written with paths like ../.../ this folder/thifile.php broke as soon as I deployed my website?
Are they wrong? On the localhost they were working just fine.
I got his errorfailed to open stream: No such file or directory in , and my file structure has not changed after I deployed it
Are you sure the paths point to the same places? If you have a different directory structure on your deployed site, relative paths like "../../etc" may not point to the same files.
I didn't bring my chrystal ball, so you might need to explain some more, but
You host has a different system than you (windows vs linux?), so the / and \ are not compatible?
There was some other problem (hard to guess, since you didn't provide an error)
Not enough rights to read the files
A virtual directory, so you can't go back in the structure like that, cause you're getting a different (real) dir?
Its definitely a path issue. Try going to the files u included using http://yourdomain/path/you/included