Re: Encrypt & SetHeader Length Problem
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 36141
interpreted = N
texte = >We have decided to encrypt all credit card data just in case someone is able >to break into our server (nothing is ever 100% secure). Of course, they can >read the templates to get the encryption seed but we'll also encrypt the >templates to prevent this. > >I was URLing the encrypted data to avoid interpretation problems with the WC >commands. For example, if the encrypted data had a & code in it, this >would prematurely end the data portion of an assignment operator. I'm not >sure if this could occur, but it seems possible given that the encrypt >command could return any 8-bit value. So I figured that URLing the data >would prevent this from occuring. If I'm wrong, it wouldn't be the first >time. You are correct, but this issue of webcatalog *changing* your formatted value before storing it in the order file is nothing new ...For example, when you try to store a value in the expMonth field with a leading zero, such as 08, you will see that webcatalog will NOT store the leading zero like you tried to get it to. Instead, it strips off the leading zero without warning, resulting in a stored value of 8. There is nothing you can do to change this ...Basically, WebCatalog is programmed to *change* our formatted data when it doesn't fit webcat's idea of what that data is supposed to look like. Granted, this does not occur in all order file fields, but it should not occur in ANY of them, because it forces webcat's very limited internal formatting on us, even when we need a different format for our data ... :(This specific behavior occurs in both the expMonth and expYear fields. Webcat can also do screwy things with the values you try to store in the accountNum field when it doesn't like the format you give it. It seems you have discovered this 'feature' by trying to store values it doesn't like in that field ...WebCat may also change other order file field values as well, but SM has ignored me every time I asked them for a list of *all* the fields which are subject to this kind of internal 'behind-the-scenes' data manipulation. So I guess this is just another one of those 'secrets' that they would rather keep from us than to share openly ... :(Fortunately we have a work-around which you have already discovered -- the header fields. Using these fields is the only guaranteed way to prevent webcat's internal code from changing our formatted values. It seems that webcat doesn't know what kind of data you're going to store in these fields, so it must 'leave it alone' instead of mucking with it.Kinda makes you wonder why 'features' like this have been built into webcat for years, yet they are still never mentioned in the docs, right?As far as I am concerned, webcat should NEVER muck with the data I tell it to store for me, it should always store *exactly* what I tell it to store, without changing anything. But if it's going to muck with something anyways (as it does) then SM should *document* this potentially problematic behavior, instead of keeping it a secret from us until it creates problems.:( ================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- 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:
>We have decided to encrypt all credit card data just in case someone is able >to break into our server (nothing is ever 100% secure). Of course, they can >read the templates to get the encryption seed but we'll also encrypt the >templates to prevent this. > >I was URLing the encrypted data to avoid interpretation problems with the WC >commands. For example, if the encrypted data had a & code in it, this >would prematurely end the data portion of an assignment operator. I'm not >sure if this could occur, but it seems possible given that the encrypt >command could return any 8-bit value. So I figured that URLing the data >would prevent this from occuring. If I'm wrong, it wouldn't be the first >time. You are correct, but this issue of webcatalog *changing* your formatted value before storing it in the order file is nothing new ...For example, when you try to store a value in the expMonth field with a leading zero, such as 08, you will see that webcatalog will NOT store the leading zero like you tried to get it to. Instead, it strips off the leading zero without warning, resulting in a stored value of 8. There is nothing you can do to change this ...Basically, WebCatalog is programmed to *change* our formatted data when it doesn't fit webcat's idea of what that data is supposed to look like. Granted, this does not occur in all order file fields, but it should not occur in ANY of them, because it forces webcat's very limited internal formatting on us, even when we need a different format for our data ... :(This specific behavior occurs in both the expMonth and expYear fields. Webcat can also do screwy things with the values you try to store in the accountNum field when it doesn't like the format you give it. It seems you have discovered this 'feature' by trying to store values it doesn't like in that field ...WebCat may also change other order file field values as well, but SM has ignored me every time I asked them for a list of *all* the fields which are subject to this kind of internal 'behind-the-scenes' data manipulation. So I guess this is just another one of those 'secrets' that they would rather keep from us than to share openly ... :(Fortunately we have a work-around which you have already discovered -- the header fields. Using these fields is the only guaranteed way to prevent webcat's internal code from changing our formatted values. It seems that webcat doesn't know what kind of data you're going to store in these fields, so it must 'leave it alone' instead of mucking with it.Kinda makes you wonder why 'features' like this have been built into webcat for years, yet they are still never mentioned in the docs, right?As far as I am concerned, webcat should NEVER muck with the data I tell it to store for me, it should always store *exactly* what I tell it to store, without changing anything. But if it's going to muck with something anyways (as it does) then SM should *document* this potentially problematic behavior, instead of keeping it a secret from us until it creates problems.:( ================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- 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/
Kenneth Grome
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Fwd: FW: Purchase Command error (1997)
PIXO support (1997)
Re1000001: Setting up shop (1997)
One other big addition... (1997)
Running 2 two WebCatalog.acgi's (1996)
Preserving form data (1999)
Setting up shop (1997)
[WriteFile] problems (1997)
Sample Tearoom Search Error - Solved! (1997)
chat opinion ... (2002)
RE: Error reading data -1 (1997)
Secure server question (1997)
sendmail spaces (1997)
Setting up shop (1997)
Safari browser and WebDNA set-cookies (2003)
browser info.txt and SSL (1997)
Bug or syntax error on my part? (1997)
Running 2 two WebCatalog.acgi's (1996)
breaking & sorting (2000)
$flushdatabases question ... (1998)