Keeping track with printed certificates
| 6:00 pm on Sep 8, 2006 (gmt 0)|
I have a client that would like gift certificates for his site. However; we need to auto number each certificate. I'd like to number the certificates automatically after the persons completes the form. I will be using PHP to auto insert the person's name and the date and a print function. I do not want to use a data base for the client will be using Excel to keep track internally.
| 6:19 pm on Sep 8, 2006 (gmt 0)|
Open up a text editor. Type "1". Save as a file, "next_certificate.dat".
Have your PHP program lock the file (important!), read the number from the file, insert it into the certificate, increment the number, and write it back to the file, (enabling "overwite" mode.) Unlock the file.
Oh, sorry, now you have a database! One row, one column, stored in a flat text file. Sorry, you'll have to live with that. :)
This is the classic "Unix way" of keeping track of simple sequence numbers.
I don't know specifically how to do this in PHP, as I'm not a PHP programmer. But this is programming 101.
I think people should at least take Programming 101 (or read a book, website, etc. or two) before attempting to write PHP code, rather than coming here for answers. But that's my opinion...
I assume you are keeping track of the certificates issued somehow (if not with a database). Sending an email to the client, who will then stuff it into Excel?)
Sorry to be so critical, but it scares me how many untrained people are apparently trying to program these days - while being paid by a client who presumes them to be an expert!
Programming!= web design, and even if you are an expert web designer, once you delve into programming you need proper training (whether formal or self-directed). When you use PHP, you are programming. There are some simple things a non-programmer can do with it without fully understanding just what they are doing, but once you go beyond that, you are stepping onto a slippery slope.
There are places for beginners to get help learning programming, but this isn't it. (Except for "New to Web Development", where you will get a more gentle suggestion to educate yourself, and perhaps some pointers to specific resources to do so.)
| 1:39 pm on Sep 10, 2006 (gmt 0)|
I had a project exactly like this (except I would dynamically generate a PDF gift certificate after the person paid).
At first I used an auto-incrementing integer to create the number. So in your SQL table just set the column storing the id as auto-increment (id).
Later in the project we switched over to a GUID to identify the certificate row, along with a bar-code at the bottom that the restaurant could scan in to identify (and to make sure that someone hasnt used it already).
BTW, i agree with the above poster. Programming!= web-design.. If you are having trouble with how to auto-increment an integer, you really need to do some reading/learning before you delve into something like generating gift certs where a merchant can actually lose money if you forget to check something.
| 3:40 pm on Sep 11, 2006 (gmt 0)|
Thank you! You're right; I do need to learn more. I do write (and validate) my forms in PHP; however my data base experience is limited.
I designed a feedback form for a client and after completion of this form the person is brought to a coupon page. To make the coupon look nice I have inserted "<?php echo &name?> and the person's name is on the coupon. This looks very nice.
Thank for everything.
| 4:16 pm on Sep 11, 2006 (gmt 0)|
You're going to e-mail credit card information?! You are just begging for trouble and a lawsuit!
| 4:29 pm on Sep 11, 2006 (gmt 0)|
Not to mention if the Merchant Account finds out they will pull the account pretty quick..
| 6:59 pm on Sep 11, 2006 (gmt 0)|
|You're going to e-mail credit card information?! You are just begging for trouble and a lawsuit! |
When going through normal channels, email text and passwords are unencrypted. As such, they are subject to a "man in the middle" attack.
I used to poo-poo the possibility of this, except in certain scenarios - say, a college campus, a public Internet cafe, within a company, at a hotel.
This attack is made somewhat more difficult today since the widespread replacement of hubs with switchs. Without special configuration by an administrator, it generally isn't possible to "spy" on other uses within a facility by sniffing Ethernet packets any more.
However, I read a discussion the other day suggesting that personnel at large ISPs may be "paid off" by criminals to provide such information. Those with sufficient access certainly could perform a man-in-the-middle attack.
A better solution for email is to use SSL connections. This encrypts the email and passwords. Most email clients and servers today offer this option. While this provides all the security needed for the password, it still leaves the email itself open to attack if the server then passes the email through additional servers. Of course, most email passes through at least two servers. (The sender's and the receiver's.) Typically, encryption is NOT used to send email between servers.
If a single email server can be used to send and receive the mail, then an SSL connection would be an acceptable solution. Your client would have to add a POP account to his email client to retrive the mail directly from your server (rather than from his normal ISP's server.)
Alternately, you could write the information into a file (doesn't have to be a database - a flat file would be fine) locally, and then securely transfer that file nightly. I should point-out that FTP suffers the same security issues as email. A preferable solution is to use SFTP. Another alternative would be to have it retrieve by logging-in to a secure (SSL) web site.
Finally, here's a slick, secure, relatively low-tech alternative solution. Write each credit card record into a file, locally. Make the file available to your client on a secured SSL website. Create an RSS channel for the credit card data. Your client can run an RSS reader, and by setting a sufficiently-low refresh period, can process credit cards with a minimum of turn-around time. Each card record will appear as an "article" in the RSS reader, and the reader can be set-up to "beep", etc. when a new one come sin. No database needed on either the server or client end, unless they have some reason for wanting the Excel spreadsheet. Some software could be written on the client end to load the web pages into the Excel spreadsheet.
| 12:00 am on Sep 12, 2006 (gmt 0)|
It will be secure. I will use an SSL. I have no idea what the other two were speaking about? It's all in the plan to be secure.
| 12:03 am on Sep 12, 2006 (gmt 0)|
I forgot to mention...thank you for taking the time to explain my options. It's obvious that you have the experience to give lengthly advice instead of a mention of one short sentence.
| 12:09 am on Sep 12, 2006 (gmt 0)|
Bartainer, don't take it personal when we give a one sentence reply, sometimes thats all it really needs. I was in no way trying to poke at you or your development decisions.
You *really* need to make sure you have dotted your 'i's and crosed your 't's or you will be held liable if the financial data is comprimised. I cringe when I hear non-experienced programmers ask e-commerce related questions for this very reason.
Again, it's nothing at all personal and I hope you believe that. It's just this thread started with you asking a very simple question about incrimenting integers only to progress into you handling sensitive financial information.. that my friend is cause for concern.
Good luck with the project, and feel free to sticky me if you need help.
| 1:57 am on Sep 12, 2006 (gmt 0)|
Thank you! I may take you up on the sticky.