Thanks for the reply.  It would still be nice to check for an alpha immediately *before* the "on" string, but I understand that with the replace function that wouldn't be the most straightforward thing in the world.

At least I understand what's going on now ... at first it was certainly a little puzzling, until I found the filtering functions in your asps.  Since "apps come and go (or at least change), but data lasts forever" (somebody else's line), I would welcome any changes in future versions that might lead to the unencoded storage of such data through a safe mechanism.  Just my 0.02 ... I've work with lots - probably over 100 - of third-party apps, and for every app we install it seems that there is always a group of users with a legitimate need to do reporting through Crystal or Access or some other such tool.  This will complicate those reports, as we will have to replicate the decoding functionality someplace else, that's all.

I do appreciate your response, though, and I think you really have a wonderful product.  I am not losing site of the fact that this small issue is due to the fact that you are doing an excellent job scrubbing and protecting your data.  Thanks for all the good work, but please consider my comments.

Sincerely,
Chris

My name is Chris Leonard, and I am evaluating Web Wiz Forums for possible integration into my site (http://www.databaseguy.com - forums not yet publicly viewable).  If I enter Chris Leonard as my real name in the Web interface, the column tblAuthor.Real_name stores the value as Chris Leonard.  Looking through register.asp and other related files, I see that the string "on" is being filtered out, because it could be part of malicious code.  But (of course) this makes any reporting queries against the database backend rather awkward if I don't go through the un-editing proce supplied with Web Wiz that would reverse the editing process.  So here's my question:  Is there any reason those Replace function calls in functions_filters.asp couldn't check to make sure that the characters "on" (and other tokens) don't have alphanumeric characters immediately before or after them?  I understand wanting to play it safe, and this is certainly not a complaint, and I think that it's great that this parsing is being done in your code; however, if it was possible to determine that there was an immediately preceding or trailing alphanumeric value before one of the malicious tokens, then it's not really a malicious token, right?  Could this be considered as a modification for a future release?

Thanks for any reply,
Chris