newbie trying to write to database
Moderator: General Moderators
newbie trying to write to database
Hi All, I have a form that is asking the user for credit card data and then writes the data to a database. It has to be secure, so I tried to use the following:
$make=fopen("https://www.glencovemarine.com/forms/us ... ta.dat","a");
It WAS $make=fopen("admin/data.dat","a"); before I tried to modify it.
But what happens is I get the errors:
Warning: fopen(https://www.glencovemarine.com/forms/us ... n/data.dat): failed to open stream: HTTP wrapper does not support writeable connections. in /home/glencove/public_html/forms/use/dewx/process2.php on line 109
Warning: fwrite(): supplied argument is not a valid stream resource in /home/glencove/public_html/forms/use/dewx/process2.php on line 113
I need to go live with this form in the next 2 days, it was created with PHP form generator and I have modified it to suit my needs, but with the error nothing gets written to the DB, but it has to write to a secure location. What do I need to do? I am extremely green, so please be gentle!
I can provide any/all of the code if needed. HELP!!!
Thanks, Dawn
$make=fopen("https://www.glencovemarine.com/forms/us ... ta.dat","a");
It WAS $make=fopen("admin/data.dat","a"); before I tried to modify it.
But what happens is I get the errors:
Warning: fopen(https://www.glencovemarine.com/forms/us ... n/data.dat): failed to open stream: HTTP wrapper does not support writeable connections. in /home/glencove/public_html/forms/use/dewx/process2.php on line 109
Warning: fwrite(): supplied argument is not a valid stream resource in /home/glencove/public_html/forms/use/dewx/process2.php on line 113
I need to go live with this form in the next 2 days, it was created with PHP form generator and I have modified it to suit my needs, but with the error nothing gets written to the DB, but it has to write to a secure location. What do I need to do? I am extremely green, so please be gentle!
I can provide any/all of the code if needed. HELP!!!
Thanks, Dawn
- daedalus__
- DevNet Resident
- Posts: 1925
- Joined: Thu Feb 09, 2006 4:52 pm
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Because you are dealing with local files, the https:// and related text is not necessary. The way you were doing it before was fine.
However, you must secure the admin using an .htaccess file with the contents "Deny from all" or similar depending what your webserver is.
One last thing: data.dat does not a database make. If you want a fully-fledged DB, you'll need to check out MySQL or the like.
Finally, in accordance to daedalus__'s views, why the hell are you using a generic form/comment submission form to collect credit card addresses?
However, you must secure the admin using an .htaccess file with the contents "Deny from all" or similar depending what your webserver is.
One last thing: data.dat does not a database make. If you want a fully-fledged DB, you'll need to check out MySQL or the like.
Finally, in accordance to daedalus__'s views, why the hell are you using a generic form/comment submission form to collect credit card addresses?
Why the generic form
To answer both of your questions, I guess it's because I don't know any better, I told you I was green. I am actually writing this to a MySQL database, as far as I can tell the admin.dat is just a portal, but to truly remove records I have to go into the MySQL, not just the admin.dat. I know that much.
If you can give me a more formidable solution, I am more than willing to learn. Any help would be most appreciated. I don't understand though what is wrong with building the generic form for this as long as it is behind my SSL. Please advise.
Thanks, Dawn
If you can give me a more formidable solution, I am more than willing to learn. Any help would be most appreciated. I don't understand though what is wrong with building the generic form for this as long as it is behind my SSL. Please advise.
Thanks, Dawn
I guess I am in need of some direction
If I'm doing this all wrong, I would appreciate some direction from the obviously MUCH more experienced people I see here. I am running under a deadline (naturally), but I don't know what else to do other than what I have done. I have no peers where I work and live, these forums are all I've got (that and a skinflint boss, I might add).
I don't host our webserver, it is externally hosted. I can see that there is a shopping cart in my cpanel, should I look at that instead? Otherwise, I have to go with what I have because it has to be up by tomorrow. On the other hand, the last thing I need it to compromise my customers' data.
I might mention that we have no intention of leaving this information on the webserver. As soon as a notification of an order comes through to us, that record will be pulled and the cc info placed into our local inhouse database and the web record deleted.
I don't host our webserver, it is externally hosted. I can see that there is a shopping cart in my cpanel, should I look at that instead? Otherwise, I have to go with what I have because it has to be up by tomorrow. On the other hand, the last thing I need it to compromise my customers' data.
I might mention that we have no intention of leaving this information on the webserver. As soon as a notification of an order comes through to us, that record will be pulled and the cc info placed into our local inhouse database and the web record deleted.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
As previously mentioned, go directly to a database; lose the file altogether.
It's extremely risky taking people's credit card information. Not only from a security stand-point, but from a legal protections stand-point. If at all possible, I would strongly suggest using a third-party processing firm.
Another possibility would be for the server to FTP the information directly to your in-house server via some tunnel. SSH may be a better route.
It's extremely risky taking people's credit card information. Not only from a security stand-point, but from a legal protections stand-point. If at all possible, I would strongly suggest using a third-party processing firm.
Another possibility would be for the server to FTP the information directly to your in-house server via some tunnel. SSH may be a better route.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
Secure Shell.
http://en.wikipedia.org/wiki/Ssh
There are a few classes around (like one on our network sister site phpclasses.org) for communicating over SSH.
http://en.wikipedia.org/wiki/Ssh
There are a few classes around (like one on our network sister site phpclasses.org) for communicating over SSH.
Thanks. I would like to emphasize that we are not taking a payment online (althouth that is wanted in the future). We are just taking the information.
I have removed the portion of the code that writes to data.dat, and now the record is only written to the MySQL database. I know this doesn't solve all my problems, because I need to know how to make the mySQL database secure, but am I headed in the right direction?
I have removed the portion of the code that writes to data.dat, and now the record is only written to the MySQL database. I know this doesn't solve all my problems, because I need to know how to make the mySQL database secure, but am I headed in the right direction?
Thanks feyd, but please clarify, do you mean that just the act of storing the data is dangerous? I would definitely agree with you there. As I mentioned, we have no intention of leaving it there. I will look into the things you mentioned, and believe me I try to take as many online classes as I can, not that that always helps, but it is better than nothing!
For now I am going to do just that. I appreciate all of the assistance I have gotten here, and I may be back later with some other numbskull newbie question, so please continue to monitor this thread.
Thanks so much, Dawn
For now I am going to do just that. I appreciate all of the assistance I have gotten here, and I may be back later with some other numbskull newbie question, so please continue to monitor this thread.
Thanks so much, Dawn
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
The act of storing it for any period of time, even in the server's memory, brings the full brunt of liability from the credit card companies. This is why we typically suggest using a third party as they should have passed certification from the major card companies for their security concerns. Don't just get any third-party that says they can do transactions. Due diligence is needed.
With the use of SSH it would never be held on the public server longer than it takes to dump the memory to your internal server. If the SSH user's rights are properly set (or the in-house server has cleaning routines) the information would never be readable by the SSH user once it leaves your public server. The more strict the settings, the better in these cases.
With the use of SSH it would never be held on the public server longer than it takes to dump the memory to your internal server. If the SSH user's rights are properly set (or the in-house server has cleaning routines) the information would never be readable by the SSH user once it leaves your public server. The more strict the settings, the better in these cases.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
It is only a suggestion, but I would consider keeping all sensitive personal customer information away form your servers entirely if you can. You are collecting it now. That makes you responsible for the data. If it is compromised, you and your company are headline news as to how insecure your systems are.
If you absolutely must take information, regardless for how long it is on your systems, it should be encrypted. It should be collected over SSL, encrypted as soon as it is validated and only unencrypted when presented to your inhouse data stores. NEVER WRITE INFORMATION LIKE THIS TO A FILE. Hit the database with it directly, as feyd suggested, then get it out of there as soon as you can if it is not essential that it be there.
But in any case, if you can use a third party processor, use one.
If you absolutely must take information, regardless for how long it is on your systems, it should be encrypted. It should be collected over SSL, encrypted as soon as it is validated and only unencrypted when presented to your inhouse data stores. NEVER WRITE INFORMATION LIKE THIS TO A FILE. Hit the database with it directly, as feyd suggested, then get it out of there as soon as you can if it is not essential that it be there.
But in any case, if you can use a third party processor, use one.