Sindbad~EG File Manager
Prior to 1.13.05 I have already created an outline of the HelpWithMath website, by imitating
the Otter-lambda site. I changed the color schemes, which involved changing
several gif files. I used Photoshop to create image files from Ramanujan's notebooks,
introduce a background gradient, and save as compressed jpeg. I also created
an Access database in \home\HelpWithMath\Orders.mdb, following a template
provided by Access.
1.13.05 Worked on page download.php. Used Access2MySql to generate \home\HelpWithMath\Orders.sql.
1.14.05 Edited Orders.sql file, copied it to MySql\bin and ran it to create the BeesonOrders database. Set up
query.php for this website so I can use PEAR-DB to access my database. Asked Frank
to set up this database on sequoia.pacweb.com. Set up beeson@pacweb.com in Outlook Express
and asked Frank to forward email from support, sales, and feedback@HelpWithMath.com to
that address.
How do I call an exe file from PHP? I need to do that to implement getTrialSerialNumber and
getSerialNumber. Answer from the Web: use exec(). Implemented this in getSerialNumber.php.
As of noon, it is working; so page download2.php is working, fetching fresh serial numbers from
GenerateSerialNumber.exe and incrementing Nused in the database correctly. Hurray.
Modified the GenerateSerialNumbers code so that it never generates serial numbers containing 1,I,0,O.
Now to implement an order form.
1.18.05 Wells Fargo requires the following pages:
a. Home Page
b. Product/Pricing Page
c. Order Page
d. Contact Us Page
e. Customer Service Return Policy Page
1.21.05 debugged order.php and purchase.php. But, in order.php, we want to start using the database.
I created a dummy Customer record and stored $_SESSION['CustomerID']. We can thus store
a dummy Order and the actual OrderDetails, before moving on to Order2.php where the Customer
and Order data will be filled in.
But: suppose they flake out and don't complete this order. When do we get to
clean up the database? Anyway, on the next page Order2.php, we'll fill in the Customer and Order data.
I suppose we could at any time delete Orders with status "fresh" and OrderDate older than yesterday, along
with any OrderDetails attached to that Order. That would still leave a Customer record with no orders.
That's not a problem per se, but if there's no data in the Customer record except CustomerID, it's garbage.
Then again, there's the problem of identifying the customer if they are already in the database. This way,
we'll have a different entry for each order they place.
We'll need more "products": Upgrade from Algebra to Precalculus
Upgrade from Precalculus to Calculus
Upgrade from Algebra to Calculus
and we'll need "class discounts" for students in a class for which a lab license has been purchased.
Perhaps the best way is to offer a "Student Pack" of up to 35 CDs for wholesale price (35% off). We could
offer this independently of whether they have a lab license.
Now, however, the number of "products" is getting unwieldy: it is 12.
So maybe we SHOULD have a "shopping cart". With regard to the databae, the "cart" is just the
temporary Order object, and its contents are the associated OrderDetails objects.
1.23.05 Implemented order.php.
1.24.05 Implemented dates.php and order2.php, and modified order.p. Now, at the end of order2.php, we have
a complete customer record in the database, and we know in session variables what the payment method
will be and what "customer type" we have (individual or company); and then we redirect to order3.php,
where we will collect and store a complete order record.
1.27.05 Modifed order.php to collect ShipDiff and ShippingMethodID. Then they go to order2 where we collect
customer information. Then they go to either ShipInfo or PaymentInfo, depending if $ShipDiff is "different"
or "same". Payment will have to present the invoice, and collect the payment info, i.e.
credit card or po number, then send them to Authorize.php, where they will submit to the payment gateway.
After the payment gateway authorizes them, we give them a serial number and let them download.
Wrote ShipInfo.php. So the two pathways, where the shipping info is or is not the same as billing info,
come together again at PaymentInfo.php; but at 2:42 am I gave up on PaymentInfo.php; it seems that
my OrderDetails table is trashed, so I can't present the order to the user.
1.28.05 Fixed that problem. Added code to Order and Order2 to prevent individual
orders from choosing "Purchase Order" and the Payment Method. Finished PaymentInfo.php--
it just needs to have $AuthorizationPage initialized at the top to the correct https link.
1.29.05 removed $ShipDiff entirely; now, on any shipping method but "download only", you will go to the
shipping info page, but it will be pre-filled in with the billing info. Removed ShipDiff from
the Orders table in the database and adjusted indices after SELECT calls to that table.
Created `Registered` table in the database; when we give out a serial number then we can
register it to the customer who paid for it.
This lets us handle a new choice on Download.php (not implemented yet):
"I already have a valid serial number". If the user then enters a serial number and it's in
the registered table, and the CustomerID for that serial number has an Order associated with it
whose status is "authorized" (rather than "shipped") then the user can download (and won't get
told they are getting a trial version). As soon as their purchase is authorized, we'll change
the status from "fresh" to "authorized" and give them their serial number both on-screen and
by email. Then, if anything goes wrong with the download, they can come back again; or they
can order and pay, and have their son download the product at his house for their grandson.
1.30.05 Authorize.Net:
Merchant Name: Help With Math
Merchant Account Number: 481307642993
Your Login name: hel481307642
Your Password: u0LuIqnExsa (original password)
changed to : towardthe1
Receipt URL: http://www.HelpWithMath.com/AfterTransaction.php configured to POST the data.
(I think this doesn't have to be a secure page. Anyway no sensitive data such as credit card numbers will go here.)
I will need an SSL certificate to post credit card numbers to Authorize.Net. That might be a shared certificate
or one I purchase, for example from
http://www.geotrust.com/web_security/index.htm
2.1.05 changed shipinfo.php and Orders.sql to use ShipLastName and ShipFirstName instead of just ShipName.
Attempted to buy an SSL certificate, but it needs my ISP to generate a CSR (Certificate Signing Request);
so I asked Frank to do that.
Made a makefile for GenerateSerialNumbers.exe and changed that project until it will compile without Windows,
and moved it to PacWeb's server.
2.2.05 Successfully tested GenerateSerialNumbers on PacWeb's server.
2.3.05 Worked on PaymentInfo.php which will submit data to the payment gateway. Set it all up properly
except for date_selector which needs to put an expiration date in x_exp_date in format MMYYYY for example;
but I want to use two SELECT elements for selecting the month and year. And I don't want to assume that
the user has Javascript. (If they don't, what is my site going to look like anyway?? Maybe I've already
assumed they have Javascript.) Googled up "Javascript Form Validation" to find out dos and donts.
Fixed date_selector and learned about cURL and wrote my script in cURL.
2.4.05 improved data validation to disallow commas, since the gateway's response will be comma-delimited by default.
Added validate_email in order2.c.
2.8.05 Installed Flash MX. Spent some time evaluating possible methods of converting Powerpoint to Flash.
Free methods don't work (don't handle animations, convert everything to png); powerconverter works ok but they
want $500 for it. Besides, the demo I include with MathXpert is meant to teach how to use it, rather than to
show what it can do, so I don't want exactly that same demo on the website.
2.15,16,17,18 added more HTML and php files; gave up on Flash for now as I must get something up immediately.
2.18.05 Put all existing files to PacWeb's server between 11 am and noon. We're on the Internet now!
Debugged several problems: on Unix, my_sql is case-sensitive for field names. Had trouble running
mysql commands (see computers.txt for details how to do this). Several case-sensitivity bugs in the
links on the site. On PacWeb's server you MUST explicitly use $_GET['include'], not rely on an
automatically-created $include.
2.27.05 worked on checkSN.php, modifying it so the option to download choosing "I already have a serial number"
works correctly.
4.16.05 Goal: get credit cards enabled.
4.16.05 From order2.php, submit goes to PaymentInfo.php but the billing information
does not show. The cause of this is some kind of variable masking problem--I had set $cid = $_SESSION['CustomerID']
and also used $cid as a formal parameter for a function display_billing_info. I'm not sure why this doesn't work in
PHP. Anyway, it works now.
4.16.05 date_selector (in dates.php) does not work when called from PaymentInfo.php. Part of the problem was
$monthnames($i) instead of $monthnames[$i]. This caused no error message, just termination of execution
of the function. But the selection fields aren't filled out, maybe because the variables are defined at file scope
in dates.php instead of within the function?
4.17.05 Yep, see pp. 64-65 of the PHP book. You have to re-declare the file-scope variables with the keyword "global"
within the function scope. Now date_selector works. Ready to test the payment gateway. Oops, not yet, shipping
cost is not correctly calculated. It is stored in the database in order.php with the value 0.0; and it should be
set in order2.php but the variable $FreightCharge in order2.php is never initialized. Postponing that problem for now.
I fixed a number of errors in PaymentInfo.ini, and verified that the array $data is properly prepared by prepareGatewayData,
and passed to PostGateway. That function, in PostToPaymentGateway.php, can't be correct as it never does anything with the
$request string that it constructs.
4.18.05 $AuthorizationPage needs to be declared 'global'. After that fix, finally we do connect to the payment gateway,
but we get an error message: (92) The gateway no longer supports the requested method of integration.
I got help from Authorize.Net, which operates an online-chat system for help. They told me to include the name-value pair
x-relay-response=false. After that, I do get a normal response from the gateway, and after fixing one or two minor things,
I get "transaction approved". Hurray, we move on to page AfterTransaction.php, which still has to be written.
Then I added more code (optional) billing and shipping information to the gateway, so that it will appear in the confirming
emails sent by the gateway. That's working, but I've neglected the "company" field, which would probably appear when
MathXpert is ordered by a school.
4.24.05 I decided to calculate shipping charges in a PHP page. It is easier to change prices in PHP code than
in the database, although the prices of the products are stored in the database now, so putting shipping charges
in PHP code means I have an inconsistent design. Ah well. Indeed I've already written FreightCharge in
ShipInfo.php. Fixed the code in PaymentInfo.php that fetches the FreightCharge out of the database.
Wrote AfterTransaction.php. Fixed validateExpirationDate and moved it to dates.php; it is working now.
Modified the Payments table in Orders.sql, to split the name field into first and last names, and change TransactionCode
to TransactionID to match the authorize.net documentation. Also added "e-check" as a valid payment method,
and uploaded the new Orders.sql and ran it on sequoia and tested that you still can make a purchase.
Remember that the password for logging into sequoia is "webmates04".
Wrote SQL code in PaymentInfo.p to store a Payment record in the database after the transaction is approved, and
change the status of the order to "authorized."
Turned off test mode at authorize.NET at 3:14 am 4.25. We are live!
4.25.05 Oops, I forgot to deliver a serial number and allow them to download after the transaction is approved!
Wrote code in AfterTransaction.php to perform these tasks. Modified AfterTransaction.php to get the OrderID from
$_SESSION rather than by $_GET, to prevent someone from entering there own $_GET parameter and retreiving
serial numbers already registered to other customers.
4.26.05 Added code in AfterTransaction.php to send the customer their serial number(s) in an email, as well as
present them on the web page. Added code in PaymentInfo.php to get the customer email and set the transaction to
test mode if the email is beeson@cruzio.com. Tested AfterTransaction. It seems to work fine, except: if you go to
the download page and then use the back button to try to go back to AfterTransaction, you get a database error.
The cause of that problem is that there is a primary key in the Registered table, so only one serial number per
customerID can be entered. That will cause a problem if you try to buy two items, too. So I
removed PRIMARY_KEY from the Registered table, changed the start index for HelpWithMath to 10, put Ocasio's data
in the Customers table initialization, updated Orders.sql on the server and ran it. Changed AfterTransaction.php
to use if-else to set $WhichDisks[$nitems], since the ?: code was not working correctly though it appeared to be right.
Corrected 'nojunkmail' to 'Nojunkmail' on the field names in order2.php. We collect and store this information, but
it is just for future use, in case I should contemplate using a mailing list of customers.
I tested whether we can buy something with PurchaseOrder for the payment method. Indeed it tries to submit it as a
credit card purchase with credit card type PurchaseOrder. Oops. After fixing, it now just tells the customer that
we can't yet process purchase orders online, so please email sales@HelpWithMath.com.
For future reference: Here's the command to run on sequoia to remake the database:
mysql -p -u beeson BeesonOrders < Orders.sql
5.15.05 modified counter.php but did not upload it.
Modified index.php to set $_SESSION['ReferringPage'],
and modified AfterTransaction.php to use it to send an email to sales@HelpWithMath.com
notifying us of the sale and including the referring page, so we can pay MathWare.
However, this doesn't seem to be working. Although an echo command shows that
$_SESSION['ReferringPage'] gets set properly at index.php, it doesn't come out
in the email sent from AfterTransaction.php. Darn.
5.18.05 added a call to 'mail' in download2.php to send myself an email when someone
downloads the trial version.
5.22.05 removed the GET parameter from the link in download2.php to SaveOrRun.html as
it is not used, and also not in a usable format anyway. Problem: the server is issuing
the same trial-version serial number over and over.
5.23.05
My customer in Ecuador gets his credit card declined. Why? Answer:
Address Verification System (AVS) is a feature available to Authorize.Net merchants that compares the address and zip code
submitted with a transaction to the billing address stored at the credit card issuing bank.
Bankcard processors provide the Address Verification System to aid in the detection of fraud.
The AVS settings from B, E, G, R, S, U, and N are the default settings for all merchants using our system.
However, if your business handles international transactions you may want to consider changing your AVS settings.
Most international orders will receive response codes of "G", "U" and "S".
Most international orders will not receive one of the No Match/Match AVS responses as the majority of foreign banks
do not support the AVS system. Authorize.net recommends that you employ your default settings, however it does not work for all business models.
Please be aware that if you change these settings address verification will not be done on these transactions.
Address Verification System settings can be changed by following these steps:
- Log into the Merchant Menu https://secure.authorize.net/
- Click "Settings and Profile"
- Click "Address Verification" (under the Security section)
- Select/Deselect the AVS codes you wish to automatically reject/accept
- Click on "Submit" when finished
I made changes and after this, my customer from Ecuador was able to purchase.
6.24.05 Added include/essay.html and a link to it in about.html. (This is the essay that originally was
the preface of the manual.)
7.14.05 modified AfterTransaction.php so it has the correct path to GenerateSerialNumbers, also for
purchases (not only for downloads). This explains why I had to send one customer a serial number by email!
But it's still unexplained why it generates duplicate serial numbers for trial versions.
7.20.05 Wrote sales.php and cleaned up my database using cleanup_database and delete_beeson.
10.9.05 Modified GetSerialNumber.php so getStartIndex returns 0 if this is the first time
for this value of $days (not null).
10.9.05 Modified GetSerialNumber.php so getTrialSerialNumber has another ../ in the exec call,
since it's now going to be called from one directory down.
10.9.05 Created SaveOrRun.php in the Install folder. Modified download2.php to require the user
to enter an email address. If it's a valid email address, redirect to SaveOrRun.php, where a
trial serial number is issued and sent by email to entered email address. I can't call getTrialSerialNumber
from download2.php (and then send the email from there) since headers have to start before that call,
I guess because there's the possibility of an error message about failed connections in query.php.
10.9.05 Changed the trial period to 14 days in getTrialSerialNumber, and three places changed "30"
to "14" in download.php. Now the changes seem to be working correctly: I arrive at the download page,
and I get the correct emails (one to beeson@cruzio.com with the serial number, one to sales@HelpWithMath.com
with the report of the download).
10.9.05 However, I still have the problem that it issues the same serial number repeatedly. It's high
time to fix that! Modified getStartIndex in GetSerialNumber.php and tested it by having StartIndex
emailed to me in SaveOrRun.php. It's working, but I'm still getting the same serial number, so
getStartIndex wasn't the only flaw. That's reasonable as that flaw only showed up because I changed
from 30 to 14. I've verified that getTrialSerialNumber is calling GenerateSerialNumbers with the correct arguments,
e.g. GenerateSerialNumbers/GenerateSerialNumbers HelpWithMath 7 14 1 5. So it seems that C program must have a bug.
10.9.05 Modified CheckSN.php so it ALWAYS lets them download, but sends me an email when they do, and
modified download3.php to collect an email address from those who choose "Download | I already have a serial number".
Sindbad File Manager Version 1.0, Coded By Sindbad EG ~ The Terrorists