('binary' encoding is not supported, stored as-is) In-Reply-To: <068b01c1874a$7b1296b0$cb9c2bd5@ts> The cart_id is a highly filtered variable, and has been from the start of this shopping cart. Some folks were concerned about the Cross Site Scripting Vulnerability (CSS) that have been talked about so often over the last year or so and how it related to agora.cgi. That, combined with the desire to track errors in coding of web pages in web site development, led us to add diagnostics in version 4.0x to display artificial changes in the cart_id that showed when the site was in debug mode. The vulnerability did not exist, as far as we can tell, at any time in a live store running in non-debug, or normal, mode. In debug mode, the offending javascript is displayed to the browser exactly as given to the site but has been escaped to the log file for security reasons. We are probably going to escape out the javascript display even in debug mode on 4.0e. We want to balance the needs of debug mode, where we show inner workings to a developer, with the needs to be as secure as possible. The current release version, 4.0d, needs to have debug mode on in the manager and an internal cart_id tracking variable turned on explicitly to see the javascript issue. The web site store version 4.0c displayed the javascript, as it was in debug mode and had that cart_id variable turned on. The original post said it was version 3.3e, but the actual cart used must have been 4.0x as 'stock' version 3.3e did not have the diagnostic code installed. The best thing to do is have debug mode turned off on a live store, for this or any issue in fact. Debug mode is there to assist developers by showing errors on the browser (instead of having to hunt for them in the log file) but by its nature can give up some level of security, as well as make a site look and feel less attractive.
This archive was generated by hypermail 2b30 : Thu Jan 24 2002 - 13:13:43 PST