Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 182
  • Last Modified:

PHP: Passing data on the same server without conflict

Hi Experts,

My site is currently split into two parts - a wordpress front end and a custom built trading area.

I am currently passing whether a user is logged in from the trading area to wordpress in the form of a php generated xml file.

and I have the following in my wordpress header.php file:

$xml=simplexml_load_file("http://mysite.com/launch/isLoggedIn.php");
if ($xml->status === "false") { 
echo Menu A
}
else {
echo Menu B
}

Open in new window


It works ok but seems from my limited knowledge like using a http request on the same server isnt the best way to go about it.

I also now want to display my wordpress menu in the trading system but do not want to include wp-load.php for fear of conflicting functions.

I am thinking of add the menu to the xml file I've already created.

I'm hoping I've explained myself well enough and that someone can either confirm that the way im doing it is ok or whether there is a better way of passing information from one part of my website to the other?

Thanks in advance
0
maccaj51
Asked:
maccaj51
  • 2
  • 2
  • 2
  • +1
1 Solution
 
Julian HansenCommented:
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";
}

Open in new window

0
 
maccaj51Author Commented:
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.
0
 
gr8gonzoConsultantCommented:
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.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
Beverley PortlockCommented:
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
0
 
Julian HansenCommented:
We seem to be getting a conflict with our trading sessions and wordpress ones.
What sort of conflict - the only conflict you can have is on name - in which case use a different name for your session variables.
We run multiple sites on the same server that all use sessions we just have a prefix in a config file that we prepend on to all variables so they don't bump into each other

// Config file
define('SITE_PREFIX', 'mysite_');

// In our functions file
function getSession($id) {
    return isset($_SESSION[SITE_PREFIX . $id]) ? $_SESSION[SITE_PREFIX . $id] : '';
}
function setSession($id, $value) {
    $_SESSION[SITE_PREFIX . $id] = $value;
}

Open in new window

0
 
gr8gonzoConsultantCommented:
@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.
0
 
Beverley PortlockCommented:
@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)
0
 
maccaj51Author Commented:
Thanks for all your help
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

  • 2
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now