Using POST from cron job

[Kent Multer]

Hi folks,

I have a number of clients using modules that are triggered by cron jobs to perform various functions automatically once a day. The cron commands all use the Linux GET command to trigger merchant.mvc or admin.mvc. But in some cases the URL parameters include passwords, which really shouldn't be exposed in this way. I'd like to switch to using an HTTP POST instead of GET, so that the passwords and other data can be transmitted securely.

I've been doing some Web searches, and it looks like this can be done by using POST instead of GET as the command, or by using wget with a --post option, or by using curl. But I had trouble finding examples for the first one; and I'm not sure if any of these can be used on the clients' servers.

Has anyone used any of these techniques? Can you give me an example of how to write the command?

Also, maybe someone from Miva can chime in on whether POST, wget, and/or curl are available on Miva-hosted stores?

Thanks -

[ILoveHostasaurus]

I'd use curl:

/usr/bin/curl -s --location --data "var1=val&var2=val2" http://domain.com/mm5/admin.mvc

Honestly though I'd avoid doing things this way at all if user/pass must be passed, especially if we're talking admin username and password. There are just too many ways it can turn into a liability later. If someone accesses the hosting control panel and looks at your cron job, now they have a user/pass for the store admin interface. If a php script or similar on the website gets compromised, it would be able to read the cron jobs for that user since php scripts run as the user associated with the website. If the login information changes, now the cron job breaks. It would be a violation of PCI if the client must adhere to those requirements.

Can you create a custom PAGE in the store that performs the relevant asks and just set up the cron job to hit that page at the necessary interval?

[Kent Multer]

Hi David, thanks for the info.

I'm aware of the issues you raised; and in some cases, I do use custom merchant.mvc pages instead of going thru admin. But some of these modules do payment processing using saved credit-card numbers. So the decryption passphrase has to be passed at some point in the process. If there's a better way to do that, I'd love to hear about it.

Sometimes I suggest to the client that they use a scheduled task running on their office computer, instead of a cron job. But so far, no one has wanted to do that. I also occasionally point out that, hey, it only takes a few moments to view a page and enter a password once a day; but the clients really like having it happen automatically.

The cron jobs are protected by the control-panel login, so there's one extra level of security between them and anyone who has access to the store. For more complete security, I suppose it would be better for the cron job to be on a separate server, so the passphrase would be on a different hard drive from the store. I'm not sure if that would be PCI compliant?

Thanks --

[ILoveHostasaurus]

There is no way a cron job should ever contain both login credentials and a credit card decryption pass phrase. I'm not a lawyer, but I would suggest talking to one for advice on that before ever considering producing a solution that uses such a setup. Having admin credentials in the cron job is bad enough, and certainly not following the guidelines of PCI if such a configuration is desirable.

If you have a client who needs to do recurring billing, they should use a payment gateway that supports it and implement it on the payment gateway side. You simply go in, pick the transaction, then choose the frequency of recurrence and amount. In the future, we will have a product that offers it as well, using the gateway of your choice, all built into Merchant. I don't have a time frame to share on that right now but I believe additional info will be released at the conference.

Regarding a cron job's security, there is no security for a cron job that is adequate. Any script running on the website in question would have access to read it, bypassing the control panel and anything else. So basically if you have a copy of wordpress, and it gets hacked, now the person has your cron job and the store credentials. Having it on a separate server is no more secure and certainly not permitted by PCI regardless.