Re: StoreBuilder (retitled)

This WebDNA talk-list message is from

2002

It keeps the original formatting. numero = 44638
interpreted = N
texte = >>- The StoreBuilder store made no provision for a transition >from an insecure protocol to a secure protocol on going to checkout. >The store in question prominently displayed its Verisign certificate >and a link to Verisign to verify it, but there was no indication any >transaction through the store (of which there were several thousand >over several years) had ever been made via SSL.One simply fix will do.. Either access the entire storefront via a secure URL (that's what we do) or use BBEdit to search for form actions' and hypertext links to checkout.tpl and change them use the secure URL that is already part of the prefs.>>- The StoreBuilder store stored credit card data entirely >unencrypted on the server. It also accumulated that order data >indefinitely, so there was a very large order table that included >the unencrypted credit card data from all the orders the store had >ever taken. I would think this would be a RAM issue as well. >(Perhaps there are some order archiving features somewhere that were >unused, but I didn't see them.)While encrypting CC numbers was always a good idea, it was never required until recently. You can't really blame 5 year old code for not doing things the right way in the year 2002. Again.. simple fix. Use BBEdit (or someother batch search editor) and find all the places where the CC field is referenced and wrap it with an [encrypt] or [decrypt] context. As to the RAM usage, that's a non-issue. Unless I'm mistaken carts are kept in the the carts folder as individual files.... one per order. So while one might argue that they are taking up valuable disk space, I'm pretty sure they are not taking up RAM. The two clients who use storebuilder carts have not had enough experience to tell whether this is a problem or not. Also...I seem to remember some kind of sweeping that goes one. Maybe someone else has more information. Either way a daily template that sweeps the carts folder and deletes or archives old carts would be trivial to implement.>>- The StoreBuilder store appeared to send an email to the >customer containing an unencrypted credit card #, although the email >sent to accounting appeared to have the credit card # masked.Not true. Below is a snippet of the receipt e-mail sent to me after placing a test order: Shipping: _ Source: email: joedan@west21.com payment: AC account: ************1111 expMonth: 1 expYear: 3I suspect that the storebuilder that you have taken over responsibility for has been modified.>>- The generated pages did not appear to have doctype >declarations, an HTML namespace, or standard meta tags.Easy fix. Come on....>>If I have misunderstood or misinterpreted these things, I'd like to >know about it. For a developer who knows what he or she is doing, of >course all these problems can be fixed (as can the in my view rather >pathetic appearance of the generated store). But I think this >promotes the possibility of stores being opened without these >problems being fixed, which doesn't seem like a good thing to me.Hey I'm no SmithMico supporter... check the archives... but I think your criticisms are not fair. I think that the storebuilder templates are a starting point. The only 2 real security issues that I see are the secure page for checkout and encrypting CC data stored in the database. Both easily fixed.As to appearance... well it would be impossible to create a beautiful store builder storefront and please everyone. That's one of the things I like about storebuilder... I can change a little code in brief.inc for example, and change the entire appearance of the storefront.I don't know that anyone else want to jump in on the defense of storebuilder here, but I've seen some beautiful storefronts built with storebuilder. Anyone?One more thing... Since I use the database helper frequently, I was always coming up against the same things that I didn't like in it. So I spent about an hour and I listed all the things I hated about database helper. (no begins with as a search parameter, for example). Then I spent another three hours going through the database helper builder code and modified it to work the way I want. Now when I build a database it's just the way I want it. All things considered, a half a day is not a lot of time to perfect a tool that I'll use often. I think that if I used storebuilder more, I'd do the same.~j>>Best,>Velma>>-------------------------------------------------------------------------->Velma Kahn>Glory Day Software Company>200 Tanager Ln NW, Floyd, Virginia 24091, U.S.A.>phone: 540-745-6469 * fax: 651-321-4884>email: vkahn@glorydaysoftware.com>www.glorydaysoftware.com>>>------------------------------------------------------------->This message is sent to you because you are subscribed to> the mailing list .>To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to >>Web Archive of this list is at: http://search.smithmicro.com/-- ____________________________________________________________Joseph D'Andrea ~ http://www.west21.com/ ~ JoeDan@West21.com WEST21.com Internet services for the 21st Century webhosting ~ co-location ~ wireless access WebCat and MGI database programming____________________________________________________________-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Re: StoreBuilder (retitled) (Joe D'Andrea 2002)
Re: StoreBuilder (retitled) (Velma Kahn 2002)

>>- The StoreBuilder store made no provision for a transition >from an insecure protocol to a secure protocol on going to checkout. >The store in question prominently displayed its Verisign certificate >and a link to Verisign to verify it, but there was no indication any >transaction through the store (of which there were several thousand >over several years) had ever been made via SSL.One simply fix will do.. Either access the entire storefront via a secure URL (that's what we do) or use BBEdit to search for form actions' and hypertext links to checkout.tpl and change them use the secure URL that is already part of the prefs.>>- The StoreBuilder store stored credit card data entirely >unencrypted on the server. It also accumulated that order data >indefinitely, so there was a very large order table that included >the unencrypted credit card data from all the orders the store had >ever taken. I would think this would be a RAM issue as well. >(Perhaps there are some order archiving features somewhere that were >unused, but I didn't see them.)While encrypting CC numbers was always a good idea, it was never required until recently. You can't really blame 5 year old code for not doing things the right way in the year 2002. Again.. simple fix. Use BBEdit (or someother batch search editor) and find all the places where the CC field is referenced and wrap it with an [encrypt] or [decrypt] context. As to the RAM usage, that's a non-issue. Unless I'm mistaken carts are kept in the the carts folder as individual files.... one per order. So while one might argue that they are taking up valuable disk space, I'm pretty sure they are not taking up RAM. The two clients who use storebuilder carts have not had enough experience to tell whether this is a problem or not. Also...I seem to remember some kind of sweeping that goes one. Maybe someone else has more information. Either way a daily template that sweeps the carts folder and deletes or archives old carts would be trivial to implement.>>- The StoreBuilder store appeared to send an email to the >customer containing an unencrypted credit card #, although the email >sent to accounting appeared to have the credit card # masked.Not true. Below is a snippet of the receipt e-mail sent to me after placing a test order: Shipping: _ Source: email: joedan@west21.com payment: AC account: ************1111 expMonth: 1 expYear: 3I suspect that the storebuilder that you have taken over responsibility for has been modified.>>- The generated pages did not appear to have doctype >declarations, an HTML namespace, or standard meta tags.Easy fix. Come on....>>If I have misunderstood or misinterpreted these things, I'd like to >know about it. For a developer who knows what he or she is doing, of >course all these problems can be fixed (as can the in my view rather >pathetic appearance of the generated store). But I think this >promotes the possibility of stores being opened without these >problems being fixed, which doesn't seem like a good thing to me.Hey I'm no SmithMico supporter... check the archives... but I think your criticisms are not fair. I think that the storebuilder templates are a starting point. The only 2 real security issues that I see are the secure page for checkout and encrypting CC data stored in the database. Both easily fixed.As to appearance... well it would be impossible to create a beautiful store builder storefront and please everyone. That's one of the things I like about storebuilder... I can change a little code in brief.inc for example, and change the entire appearance of the storefront.I don't know that anyone else want to jump in on the defense of storebuilder here, but I've seen some beautiful storefronts built with storebuilder. Anyone?One more thing... Since I use the database helper frequently, I was always coming up against the same things that I didn't like in it. So I spent about an hour and I listed all the things I hated about database helper. (no begins with as a search parameter, for example). Then I spent another three hours going through the database helper builder code and modified it to work the way I want. Now when I build a database it's just the way I want it. All things considered, a half a day is not a lot of time to perfect a tool that I'll use often. I think that if I used storebuilder more, I'd do the same.~j>>Best,>Velma>>-------------------------------------------------------------------------->Velma Kahn>Glory Day Software Company>200 Tanager Ln NW, Floyd, Virginia 24091, U.S.A.>phone: 540-745-6469 * fax: 651-321-4884>email: vkahn@glorydaysoftware.com>www.glorydaysoftware.com>>>------------------------------------------------------------->This message is sent to you because you are subscribed to> the mailing list .>To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to >>Web Archive of this list is at: http://search.smithmicro.com/-- ____________________________________________________________Joseph D'Andrea ~ http://www.west21.com/ ~ JoeDan@West21.com WEST21.com Internet services for the 21st Century webhosting ~ co-location ~ wireless access WebCat and MGI database programming____________________________________________________________-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Joe D'Andrea

DOWNLOAD WEBDNA NOW!

Re: StoreBuilder (retitled)

2002

Top Articles:

Related Readings: