PHP: Passing data on the same server without conflict

Any reason you can't use a SESSSION variable.

// You have to have this at the start of your script before any output is sent to the browser
session_start()

// Set your session variable to some value you can check later
$_SESSION['user'] = 'loggedon';

// Check session variable exists and it has a specific value and act accordingly
if (isset($_SESSION['user']) && $_SESSION['user'] == 'loggedon') {
    echo "Menu A";
}
else {
    echo "Menu B";
}

Select allOpen in new window

Hi Julian,

We seem to be getting a conflict with our trading sessions and wordpress ones.

Also we want to be able to "send" the menu items of the wordpress menu as well.

That's understandable about sessions conflicting. However, you can still use cookies as long as both sites are on the same domain:
http://php.net/manual/en/function.setcookie.php

As long as you use a name for your cookie that isn't in use by either site, you should be fine. You can use Firebug (Firefox) or Chrome developer tools to watch your cookie values for easier development.

Another possibilty is to send what you want via https if your server has the relevant certificates. An alternative that I sometimes use is to encrypt the data with something like blowfish and send it as an encrypted string, that way I can send any data I please in a secure fashion. Your server would need to have mcrypt installed

@maccaj51 and @Beverley,

Both of you had mentioned HTTP or HTTPS requests.

Just my two cents. Usually network requests going from one server to itself can be problematic due to IP routing and DNS, and HTTPS can exacerbate the problems with those specific reasons.

For example, let's say you have two PHP scripts:
https://www.mysite.com/sender.php
https://www.mysite.com/receiver.php

If sender.php tries to post data to the URL "http://www.mysite.com/receiver.php", it becomes a question of how your server's firewall and DNS are configured. I'd say you have about a 50/50 chance that it will work, because many DNS configurations can either turn www.mysite.com into a local IP (particularly if you run a mail daemon on the same server), or the firewall won't understand how to route a request for an external IP that it is already hosting, so it hangs.

If the DNS turns it into a local IP (a loopback like 127.0.0.1), then the request will hit the web server at that address. If the web server is even listening on the loopback address, then it will require that the server is configured for that hostname on that IP. If the web server isn't configured to listen on that IP or doesn't have the www.mysite.com hostname associated with that loopback address, then the request could go to the wrong folder.

With HTTPS, you face a bigger problem in that you typically have one IP address per host, so if you're hitting that loopback DNS issue, then you would need to have the loopback IP configured for HTTPS -specifically- for that hostname.

Overall, there are usually just a lot of hurdles with same-server HTTP/HTTPS requests. They aren't impossible, but they usually depend on specific configuration on both network and web server ends.

Aside from the network configuration, the HTTPS / HTTP requests to receiver.php will not change the visitor's session / cookies. Those requests will execute without the visitor's own cookie data, so it will be similar to a stranger simply posting data straight to http://www.mysite.com/receiver.php without logging into www.mysite.com or anything like that. So in maccaj's scenario of trying to access "isLoggedIn.php", it would always return false, because in that scenario, the SERVER is the visitor, and the server is not logged in.

It really is best to use sessions or cookies here.

@gr8gonzo

I usually avoid https. I mentioned it in case it was already in place.

@julianh

Sessions can give conflicts if you have multiple instances of the same browser open and attempting to do different tasks on the same website. The browser instances all share the same session data and if both browser window #1 and browser window #2 depend on session data to determine their state then window #1 can affect window #2. I agree that it is then a case of designing the session data sensibly, but at that point it usually gets simpler to create a session key and place it in the URL and use it to access the session data which would then be held in an array keyed by the URL key.

--

Both of the above is why I sometimes find it simpler to encrypt a string, send it and decrypt it at the other end. Admittedly I often do this on different websites where I want RESTful type interfaces to control things and need a way to prevent malicious updates. It also has the advantage that it matters little whether the sender and receivers are on the same server or not so it gives flexibility as well. The minor inconvenience of keeping keys sorted out is worth the trouble (I usually use symmetric encryption rather than public key)

Thanks for all your help