If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
It supports https-based connections, sending of file data via such a request, cookie acceptance if you need to auth first and then post the data, etc.; could be an alternative.
Ideally you would not have php scripts on the same website as a payment application (e.g. Miva Merchant), as that would bring them into scope for PCI, and given they're not compiled, they make excellent places to hide things that should not be there. That being said, could use php scripts on an independent subscription on the same server (so they run as a different user), or cron jobs that trigger them and interact with Merchant to search for work that needs doing, etc.
Ghm... Ideally yes. But life changes everything :-)
Levels theme (not sure about now, but few months ago for sure) out of the box comes with a php script included - CSS aggregation.
Isn't there a way to configure a directory that only another application (such as Miva Merchant) can access? There are still plenty of reasons (see above) that PHP functionality is still needed. Or, can the server be setup to use compiled PHP and would that solve the security issue?
I'm not disagreeing; there are plenty of reasons one may want to place more than one application, php or otherwise, on the same site as a payment application. However, any entity choosing to do so should carefully analyze the potential liabilities that may be realized from having ANY other application on the same website as a payment application, or one that is otherwise able to alter the files of said website, even if not actually sharing the space.
Whether the code is compiled or not, if talking about scripting languages, won't really make a difference. If we're talking PCI specifically, and card data, a post-breach audit is not really going to care if the exploited app that was knowingly placed alongside the payment application was compiled or not; it was "in scope" and not secure.
Comment