Own shopping cart...good idea?

[VigilanteNighthawk]

Is programming your own shopping cart mechanism in php too risky or potentially too insecure? It does not seem to be something that, with proper time and research, should be too difficult to accomplish.

These are some of the steps I would take.

1) use ssl (obviously)
2) query for prices at from database into application at checkout
3) store minimal personal info in sessions...user id, browser info (to help prevent session highjacking), unique session password generated at login (again to protect session integrity), product info (may limit to product id's if queries to database do not require too much overhead)
4) encrypt passwords with sha1(), use mcrypt functions of encrypt all personal information in the database (must research use of mcrypt functions, any good books/links would be appreciated)
5)personal information will decrypted at runtime in the application on
6) have found a script that uses memory tables to replace php's native sessions, preventing info from being readable to anyone on host. Once I have looked through it I will decide whether or not it's secure enough.

that is all I have so far. I have some experience programming such as developing user accounts, but I have yet to deploy one on an actual site (one that is in development right now should be ready within a month).

[Rellizate]

It's SQL, not SSL.
:-)

Well, it depends how good you are at php. If you have been doing it for a while, and you can code things like forums, then it is a cool idea. But if you are just starting PHP, you should start with something more basic... Like a shoutbox.

[Claxor]

At 4/15/06 04:45 AM, Rellizate wrote: It's SQL, not SSL.

-)

Maybe he meant secure sockets layer?
:)

[CyberLemming]

At 4/15/06 04:45 AM, Rellizate wrote: It's SQL, not SSL.

-)

he quite obviously meant SSL as in Secure Sockets Layer, twerp. He talks about databases, all along, SQL is implied. No, he meant SSL, one of the methods of encrytion used when the protocol is HTTPS.

[AlternateAccount]

At 4/15/06 06:17 AM, CyberLemming wrote:

At 4/15/06 04:45 AM, Rellizate wrote: It's SQL, not SSL.

-)

he quite obviously meant SSL as in Secure Sockets Layer, twerp. He talks about databases, all along, SQL is implied. No, he meant SSL, one of the methods of encrytion used when the protocol is HTTPS.

IAWTC

[PONGpaddle]

As to answering the topic creator's question to do with security instead of bickering about someone who doesn't know what SSL is....

It is quite secure as long as you take precautions. I suggest that you read up on possible attacks through CGI and/or PHP programs, especially SQL injections, as they are common and easy to do (but also easy to stop -- see mysql_real_escape_string and mysqli_real_escape_string). Try and keep as much data on the server. Only store a unique session ID on the user's computer, and preferably one that changes every time a request is made to the server. I also suggest that you cookie functions instead of sessions functions, as they give you more control over sessions.

[PONGpaddle]

At 4/15/06 11:10 AM, TheDrunkMonkey wrote: Try and keep as much data on the server.

That's, "Try and keep as much data as possible on the server."

[Rellizate]

Ok sorry. No need to flame me for making a small mistake...

[Afro-Ninja]

you could always set up a page with a paypal system, they'll take care of the transactions for you