#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    21
    Rep Power
    0

    Perl Shopping Cart and SSL Issue


    I've developed a shopping cart in Perl which works fine on my non-secure host account. However, now I want to add SSL to the ordering process so that the transaction is secure. However, my cart uses, and reuses, simple text files to hold customer order info (price, quantity,description) and personal info (name, address, credit card number) during the ordering process, and then finally creates one master file at the end when customer submits the order for fulfillment. Since all of this activity takes place in directories on my host account's non-secure space, how would SSL work with what I've described. What I mean is, since SSL is a secure area and separate from my business account's space, how can I still use my cart with SSL. My cart needs to be able to allow a customer to change his mind and add, delete, or update information as he's ordering and prior to final order submission. This means reading/writing back to the text files that have been assigned for his ordering session(based on IP address of visitor). Wouldn't SSL interfere with this process? How would I communicate with text files between 2 different server areas: mine and the SSL's? Any guidance would be much appreciated.
  2. #2
  3. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2001
    Location
    Manchester, UK
    Posts
    80
    Rep Power
    14
    How many sessions will you have? If it is a low number, why not do the whole thing via SSL?

    I think you may need to rethink your entire design to make it a little more robust. Think about a customer using an ISP that does the decent thing and attempts to cache pages, graphics whatever and also dynamically assigns IP addresses to the client at connect time (with a lease that could in theory expire during the session). What if the customer looses their connection and has to re-dial, the web session could be intact but the IP address will likely change.

    Also why use two files not one? In fact take a look at this link for a slightly better alternative.

    SSL will not interfere with the client IP address it will simply mean that they will be connecting with the server on a different port (typically 443).

    Are you managing the SSL? Are you the only one with access to this server? Storing this kind of information on a shared server could get you into some hot water

    What about hidden <input>'s? What about a temporary directory name to be passed via a URL (very highly unsecure indeeeeeeed!) What about cookies as a last resort?

    There are lots of ways to address the problem you seem to have with the files but IMHO you have some more serious issues to address first.
    Robert.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    21
    Rep Power
    0
    How many sessions will you have? If it is a low number, why not do the whole thing via SSL?

    >>I'm guessing 3-5 might be active at any one time.

    I think you may need to rethink your entire design to make it a little more robust. Think about a customer using an ISP that does the decent thing and attempts to cache pages, graphics whatever and also dynamically assigns IP addresses to the client at connect time (with a lease that could in theory expire during the session). What if the customer looses their connection and has to re-dial, the web session could be intact but the IP address will likely change.

    >>Caching won't matter, as everything takes place at the server. If they lose their connection, they reconnect, but must start over if assigned a new IP address. Since many are using DSL and Cable Internet Lan lines, disconnects should be less frequent in the near future. No one wants to use a 56kbs connection anymore.

    Also why use two files not one? In fact take a look at this link for a slightly better alternative.

    >> I use two files to better manage the process. The two files are related by the IP address. Plus, these files get loaded to a Mysql database.

    SSL will not interfere with the client IP address it will simply mean that they will be connecting with the server on a different port (typically 443).

    >> So what you are saying is everything the cart program is currently doing can take place the way it is currently set up, it wil just be the port number that's different. Great!

    Are you managing the SSL? Are you the only one with access to this server? Storing this kind of information on a shared server could get you into some hot water

    >> Not sure what this means, but our web host is giving us SSL capabilities for our e-commerce account. So, we are using my Web Host's service.

    What about hidden <input>'s? What about a temporary directory name to be passed via a URL (very highly unsecure indeeeeeeed!) What about cookies as a last resort?

    There are lots of ways to address the problem you seem to have with the files but IMHO you have some more serious issues to address first.

    >>Thanks for the critique. I will visit the above link you listed. If you'd like to see our site's cart in action visit http://www.topsecretspydevices.com and try "buying" something. The site is not active, but feel free to put in some fake info so that you get an order generated. Let me know what you think. If all goes well you'll get an email confirmation sent back to you. We are still working on the site layout so please excuse some of the graphics, or lack thereof. Thanks again.
  6. #4
  7. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2001
    Location
    Manchester, UK
    Posts
    80
    Rep Power
    14
    tbonds,

    if you only have 3-5 sessions, do the whole lot on an SSL session, it will be slower for the user but i am sure anyone buying from your site will not need to be informed of the benefits of a secure link

    As for disconnecting, I use a broadband circuit and can re-connect several times a day, often getting a different IP address, personally I wouldn't rely on this method of identification.

    I am unclear about your SSL setup but if you go with my suggestion for an entirely secure connection, you won't have a problem. As for using flat files then sending the data to a MySQL DB - why? Why not put the data into the tables directly? Surely your current approach must be shed loads more work?

    I took a look at your site, not sure I would have done it how you did but it works and if your customers buy stuff then all the better.
    Robert.
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    21
    Rep Power
    0
    I use flat files first because I don't want any data loaded to my database until the order has been completed. What happens if the customer decides to make changes, adds, deletes, or simply wants to forget about ordering all together? Then I simply have to clean up some flat files that have been abandoned in a directory, and not have to clean up my tables. Also, reading and manipulating flat files with Perl is much quicker than using Mysql and an ODBC connection, so this is why I chose my methodology.

    I like the IP approach over cookies and javascript as many times cookies and javascript aren't enabled. I tried to build my cart assuming the worst on the client browser end.


    Thanks for the feedback on the cart program. I'm sure it will be a work in progress.

IMN logo majestic logo threadwatch logo seochat tools logo