My development servers are external "dev.site.com"
We have our database on an external IP address, but there is no DNS records for it. DNS has been set up locally using hosts files.
For example: database.site.com 55.444.33.21
Since my external development server cannot resolve database.site.com or 55.444.33.21 independently, nor can I add local DNS records to the server, how can I properly access it?
Is there some method in PHP I can utilize to essentially create an on-the-fly DNS for?
I do not have the ability to change how anything is setup, but I have full control of the codebase which is PHP. Essentially, I'm looking for a way to say 55.444.33.21 = database.site.com in my script so whenever I call database.site.com in code it works.
EDIT
I am not able to access it with just the ip, and i cannot add it to the local hosts file on the server. My goal is to find a workaround to these issues.
Don't call "database.site.com" in code.
Instead, define a constant in one place in the code and use that constant throughout the rest of the code:
define("DATABASE_SERVER", "database.site.com");
or
const DATABASE_SERVER = "database.site.com";
Then throughout the code you'd use that constant instead of the actual value. So when you need to move the code to another environment, you configure it for that environment by changing the value of the constant:
define("DATABASE_SERVER", "55.444.33.21");
or
const DATABASE_SERVER = "55.444.33.21";
In general, you want to use actual dynamic values as little as possible in the code. This gives all of your code multiple reasons to change. The value should be abstracted behind a constant or variable or symbol of some kind so that, if the value changes, only that one piece of code has a reason to change. The rest continues to function.
Quick hack, but you can define("database.site.com", "55.444.33.21");
Related
I'm, not sure if this is a common use-case, but I'm a normal kind of guy, so I can't believe this is unusual:
I have a server running a LAMP stack. There are a few PHP applications on the server. I spotted the other day that two completely different apps are sharing session information. WTF?! I get that they do, but why? they trust the server, but why does the server assume that the two apps trust each other?
okay: #1 fix is for one or both use session_name(). That's superb and it does fix the issue if either or both of them do this and neither tries to get the others session by setting the name, but is there a fix where both apps are hostile to each other? Is there something at the PHP level that can make the sessions independent, regardless of anything the apps might try to do?
Essentially nothing that
https://www.server.com/app1/index.php does should get access to session info of
https://www.server.com/app2/index.php etc.....
I thought that setting the path using session_set_cookie_params() would sort this out, but naah, setting this variable to a limited path actually has no obvious effect which is interesting - both apps #can still get to the session stuff or the other - interesting!
I can't believe this is a new issue and yet I don't spot a fix....
Cheers,
turbotas
Example code:
<?php
session_set_cookie_params(3600,"/webapps/test1");
session_name("mysession");
session_start(); ?>
<html>
<head>
</head>
<body>
<?php echo session_id(); ?>
</body>
</html>
imagine this code in webapps/test1 and exactly the same in webapps/test2. I would not expect test2 to be able to use the test1 session state simply by stating a directory outside it's own installation point - I would expect PHP to protect against that. It doesn't - I get the same session.
As you're coding the different applications, you need to make sure that each one saves its session-information (server side) in different places. The session.save_path configuration variable, for instance, specifies the host-side directory if you are saving the sessions using files. If you're storing the session information in a database table, you should be using different tables or more likely different databases.
Thus, even if an identical session identifier is somehow produced, it will produce different results for each application because each one is referencing its own distinct host-side source.
GOAL: To have a global variable that any php on my website can access. The variable would be a bool.
What I am stuck on is how I can store such a variable that is available to all php scripts, but can also be updated via php.
The variable is a bool that determines whether or not the site loads advertisements based off if a certain criteria was met that day. So, every day I will have a cron job that runs to reset this variable, thus meaning the variable needs to be update-able via php.
The only way I can think of to store it is either via a db table, which seems like overkill just for one little bool, or a json file that I store outside of the public_html directory.
With the json file, I would just perform a get on load with file_get_contents via my "class lib" file that is present on all pages of the site. Then do something similar to update it with the cron job.
NOTE: I do have a php file that is present on ALL of my pages, so including a file on every page is not a problem.
Is there a better way? It would be nice if there was a way I could just set a PHP superglobal or something, but I'm unsure if settings something like $_SERVER['custom-variable'] sticks or if it's just for that session.
Apologies if this is a simple mis-understanding of how PHP superglobals/constants work.
I appreciate any help.
A couple of options:
Just store it in the database. This is a perfectly reasonable solution.
Store it in a file, in whatever format you want. JSON is handy if you want to store anything more complex than a single string or number.
Store it in a PHP file which returns a value, e.g.
<?php return array("ads_enabled" => true);
then require() that file -- the require() call will return that value. If your server has a PHP opcode cache enabled, this will be faster than loading a normal file, as the contents of the file will be cached.
Note that the file cannot return false, as that's indistinguishable from the include() failing.
The following are not viable options:
Storing it in a session. Sessions are per-user, and start out empty.
Storing it in an in-memory cache, like APCu or Memcache. Caches are not persistent storage; the value may be evicted from the cache.
Storing it in an environment variable. Environment variables are awkward to update in most server environments.
SetEnv APPLICATION_ENV "development"
Use that in your Apache vhost definition if you are using Apache and have access to modify it. I think you can do something similar in .htaccess files.
You can use a .env file and a library for reading that file.
If you are using a front controller where all requests pass through a single index.php file then you can set a global variable or constant in there.
Using the file function, is there any difference in using an URL or a path?
$my_array = file("http://www.mydomain.com/my_script.php?id=1");
$my_array = file($_SERVER['DOCUMENT_ROOT']."my_script.php?id=1");
I'm using the first one, but I guess that it's dependant on my server internet conection because, sometimes, despite the fact that the script is called (I know it because my_script.php inserts a row in the database) I don't get the response and $my_array is empty.
Am I right?
If so, using the second call would fill always $my_array with a response. Won't it?
Can I call a file from a path passing arguments in the same way I would do with the URL?
Edit: Thanks a lot for your answers, and sorry if this question is too stupid.. I'm working on some other guy code. He was doing it this way because my_script.php is also called from other server. I'll try to do it with require preparing firstly the $_GET variable (a bit tricky but I don't want to touch my_script.php).
Any path starting with http://... will make an actual HTTP request. Essentially, it'll do the same as if you typed that URL into your browser. If you're doing this for a script on your own server, it's extreme nonsense because:
it needs to "go out" and establish a TCP connection, to itself
it ties up another web server process
it ramps up another separate PHP process
it doesn't keep the context of the current PHP process
it may not be able to return anything at all, because it will only return whatever the other script echos out
This only ever makes sense if you're trying to communicate with some other remote server.
On the other hand, using ?id=1 on a local, non-http://... file is not possible, since ?id=1 is not a valid part of a file name (or at least it probably doesn't do what you think it does).
What you typically want is something like:
require __DIR__ . '/foo.php';
This includes the other PHP script in your current script as PHP code. You should be defining functions and classes, use autoload to load them and call them as needed, but this is quite a broad topic of proper code organisation I won't go into here.
All file() does is read a file. It's intended to load something from disk, but supports any fopen wrapper PHP provides, such as HTTP.
When you pass a URL to file(), it goes and fetches that URL from your web server. Your web server will execute your PHP and return the result, which is what you get back from file(). So no, what you have there are completely different mainly because one involves the web server and PHP, and the other doesn't.
Don't do it this way. Use require() or require_once() instead.
I'm working on a PHP project and I'm using a global settings file which I include where I need some global values such as database credentials for connecting to mysql.
For example:
settings.php:
<?php
const DB_ADDRESS = 'localhost';
const DB_USERNAME = 'johndoe';
const DB_PASSWORD = 'mypassword';
const DB_PORT = 7777;
?>
My question, is it safe enough?
For example, is there any way to see variables values while debugging in explorer/chrome?
Is there any alternative safer way?
Thanks.
PHP information is processed on the server before being sent to the browser so it can't be seen inside of a browser under normal circumstances. However, if your webserver is misconfigured the plain text version of your code may be sent to the browser thus rendering it visible to users. That's why important code should always be kept outside of your document root and included into files when needed.
Whilst this offers little protection in the event of a compromised server, should your source code ever become publically viewable, through a bug or other vulnerability (such as this: http://www.php.net/archive/2012.php#id2012-05-06-1) an increasingly common approach is to set various credentials and parameters as server environment variables.
E.g. in apache vhost/.htaccess you can set an environment variable such as the following:
SetEnv DB_ADDRESS localhost
...
And in your PHP code:
$DB_ADDRESS = getenv('DB_ADDRESS');
Of course you could assign this value to a class constant, global constant depending on your use case etc....
This also makes your source code more portable, allowing different configurations to be provided depending on the hosting environment (staging/production etc):
SetEnv APPLICATION_ENV development - .htaccess interacting with Zend Framework?
Your settings are never hard coded and not accessible in the source code. Heroku uses a similar approach to application configuration.
Variables are kept within a server, and aren't sent to the client. Unless your script has any vulnerabilities that allow users to output custom variables, then they'll remain secure to anyone without sourcecode access.
Your back-end code should never appear on the front-end, unless something goes terribly wrong with your setup. If that happens and your back-end source code is "leaked" -- unlikely but possible -- then your password will be visible in plain sight.
You can encrypt the password string with a symmetric encryption scheme, but you will have to store the encryption key somewhere. Then if the encryption key gets leaked, you are back to the starting point. It's still a bit better than having the password in plain text, but nothing will be 100% safe.
That's the standard way (look at phpmyadmin, mediawiki, etc.) : this php file is not accessible and if you don't make any error in your server settings, it's not readable.
Usually you'll add a test to check this settings file is included in one of your php files :
<?php
if ( !defined('IN_KP') ) die("Hacking attempt");
?>
Of course you define 'IN_KP' in your including files :
<?php
define('IN_KP', true);
include("sensitive_file.php");
?>
But the best protection overall is that those sensitive data aren't so sensitive because your mysql account is only accessible by localhost (if not fix it !).
For example, is there any way to see variables values while debugging in explorer/chrome?
If you never send them to the view (i.e. echo, var_dump, print_r, session etc) - then no. The browser will never know about them.
I'm really inexperienced when it comes to PHP and hoping someone can clarify something for me when it comes to how variables are handled in PHP.
I have a PHP Web App that I created and needed to make a quick duplicate of, so I simply copy and pasted this app into a new folder on the same server.
I am wondering are there any concerns if the apps, in 2 different folders, have the exact same variable names?
I'm thinking of an accidental overwrite situation. If "no", then can someone explain to me why there is no concern?
No, there will not be any collisions between application global variables as long as the two application directories are truly separate and don't include files from one another. When a PHP script runs, the HTTP request that initiated it can be thought of as an isolated incident. It is separated and isolated from all other requests to the same application (even concurrently) and from other applications.
Each script gets its own variable namespace when execution starts, and that environment is terminated and deleted from memory when the script completes.
Now, if you happen to be using $_SESSION and both applications use the same value for session_name() and run on the same domain name, there is the possibility that values persisting in $_SESSION can collide between your application instances. This is simply solved by changing the value for one of the applications from the default PHPSESSID:
// Application 1
session_name("APP1");
session_start();
// Application 2
session_name("APP2");
session_start();
You probably are already aware of this, but I'll say it to be complete. Wherever possible, it is advised to abstract out aspects of the code that can be shared between the two application instances and included by both of them. This is in keeping with the DRY principle, and will save you lots of headaches if you ever have to make modifications to the code both applications share.
In my opnion you may or may not use indenticle variables names in different folders. this depends on the functionality of your app. you need to do a little research on google 'scop of global and local variables in php'.
In short, yes, you can duplicate the app into new folder, you just need to update/reset the paths (for example the include files paths) and database connection strnigs (if your app use database to store data).