You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(20) |
Aug
(21) |
Sep
(12) |
Oct
(2) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(3) |
Feb
(46) |
Mar
(65) |
Apr
(49) |
May
(33) |
Jun
(5) |
Jul
(79) |
Aug
(228) |
Sep
(347) |
Oct
(272) |
Nov
(270) |
Dec
(424) |
2005 |
Jan
(549) |
Feb
(232) |
Mar
(134) |
Apr
(103) |
May
(57) |
Jun
(74) |
Jul
(67) |
Aug
(45) |
Sep
(99) |
Oct
(187) |
Nov
(238) |
Dec
(127) |
2006 |
Jan
(81) |
Feb
(137) |
Mar
(46) |
Apr
(55) |
May
(62) |
Jun
(152) |
Jul
(137) |
Aug
(154) |
Sep
(176) |
Oct
(104) |
Nov
(65) |
Dec
(64) |
2007 |
Jan
(56) |
Feb
(303) |
Mar
(88) |
Apr
(80) |
May
(72) |
Jun
(20) |
Jul
(47) |
Aug
(28) |
Sep
(113) |
Oct
(49) |
Nov
(89) |
Dec
(24) |
2008 |
Jan
(24) |
Feb
(61) |
Mar
(43) |
Apr
(51) |
May
(12) |
Jun
(10) |
Jul
(49) |
Aug
(26) |
Sep
(7) |
Oct
(50) |
Nov
(19) |
Dec
(15) |
2009 |
Jan
(87) |
Feb
(144) |
Mar
(54) |
Apr
(72) |
May
(32) |
Jun
(23) |
Jul
(27) |
Aug
(90) |
Sep
(349) |
Oct
(174) |
Nov
(320) |
Dec
(110) |
2010 |
Jan
(162) |
Feb
(39) |
Mar
(80) |
Apr
(126) |
May
(45) |
Jun
(44) |
Jul
(75) |
Aug
(32) |
Sep
(100) |
Oct
(57) |
Nov
(49) |
Dec
(125) |
2011 |
Jan
(72) |
Feb
(41) |
Mar
(63) |
Apr
(18) |
May
(123) |
Jun
(100) |
Jul
(96) |
Aug
(84) |
Sep
(83) |
Oct
(39) |
Nov
(166) |
Dec
(103) |
2012 |
Jan
(158) |
Feb
(148) |
Mar
(77) |
Apr
(43) |
May
(126) |
Jun
(82) |
Jul
(67) |
Aug
(28) |
Sep
(109) |
Oct
(30) |
Nov
(23) |
Dec
(34) |
2013 |
Jan
(14) |
Feb
(16) |
Mar
(7) |
Apr
(79) |
May
(76) |
Jun
(13) |
Jul
(76) |
Aug
(36) |
Sep
(22) |
Oct
(35) |
Nov
(167) |
Dec
(93) |
2014 |
Jan
(64) |
Feb
(14) |
Mar
(57) |
Apr
(63) |
May
(60) |
Jun
(15) |
Jul
(24) |
Aug
(19) |
Sep
(56) |
Oct
(70) |
Nov
(45) |
Dec
(52) |
2015 |
Jan
(56) |
Feb
(73) |
Mar
(34) |
Apr
(11) |
May
(24) |
Jun
(19) |
Jul
(11) |
Aug
(8) |
Sep
(25) |
Oct
(22) |
Nov
(38) |
Dec
(7) |
2016 |
Jan
(7) |
Feb
(34) |
Mar
(17) |
Apr
(10) |
May
(17) |
Jun
(7) |
Jul
(17) |
Aug
(31) |
Sep
(3) |
Oct
(34) |
Nov
(5) |
Dec
(2) |
2017 |
Jan
|
Feb
(4) |
Mar
(18) |
Apr
(6) |
May
(10) |
Jun
(13) |
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(1) |
2018 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(10) |
May
(5) |
Jun
|
Jul
(7) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(2) |
2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(6) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
|
Dec
(3) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2022 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(30) |
Nov
|
Dec
(2) |
From: ExsonQu <hex...@gm...> - 2013-12-01 09:49:04
|
*Hi, Phil,* Thank you for your hardworking and expertise and leadership! And thanks for the great contribution from Jo, Rafael, Richard, Thumb. Your contribution become better and better. Best regards! Exson -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/New-version-4-11-2-tp4657012p4657014.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
From: Phil D. <ph...@lo...> - 2013-12-01 07:58:15
|
In keeping with the more regular release policy, I have just rolled up a new release with all the latest bug fixes and one or two new areas of functionality. This release includes nice contributions from Ricard, Thumb, Rafael and icedlava - with Exson always in support and Paul squashing the odd bug too. Thanks to all those who contributed. Thumb extended the salesman login functionality to ensure she is restricted to her own customers/orders. He and Exson also added the Chinese SQL option and modifications to the installer to use this as well as a number of bug fixes. Rafael, made it so when selecting a language - the language description appears in the characters/language of the translation so they can actually read it! Also some improvements to the Form Designer. Ricard made it so users need to have authority to act on specific bank account - with a new form to all users rights to be defined by bank account. icedlava made a nice facility to clone an existing item to a new item I made a new purchasing script to show a grid of all the items that a selected supplier sells that allows quantities to be entered for placing purchase orders to the users's default inventory location and I modified the purchase invoice entry to allow modification of PO line prices and quantites invoiced in a grid format rather than individual selections. There are a few bugs squashed with this release too. The full change log follows: 30/11/13 Ricard: Added user permissions by bank account so only certain users can see and create payments/receipts on bank accounts selected. 30/11/13 rchacon: Includes supplier-code, currency-code, and currency-name-from-CurrenciesArray.php in SelectSupplier.php. 2013/11/30 Thumb: Add salesman constraint to show salesperson's own sales orders invoice, customer etc in DailySalesInquiry.php,PDFDeliveryDifferences.php,PDFOrdersInvoiced.php,PDFOrderStatus.php,PDFPickingList.php,SalesByTypePeriodInquiry.php,SalesInquiry.php,SelectCompletedOrder.php. 28/11/13 Phil: Apply Tim's idea for stripping slashes from incorrectly displayed items PO_Items.php and DeliveryDetails.php 28/11/13 Thumb: Add salesman constraints to ConfirmDispatch_Invoice.php to ensure that sales can only print his own sales orders' invoice. 28/11/13 Thumb: Add constraints to salesman that he can only print his own sales orders in PrintCustOrder_generic.php 28/11/13 Thumb: Add constraints to salesman that he can only print his own sales orders in PrintCustOrder.php 28/11/13 Thumb: Add salesman login constraint to only their own customers available in SelectOrderItems.php and fixed SQL error of customers login. 27/11/13 Thumb: Add create new scripts to import Customers and Debtors. 26/11/13 Phil: Supplier invoice entry now allows modification of invoice quantities and prices for multiple goods received lines in line rather than having to go into each line to modify individually. 20/11/13 rchacon: Translate the name of each language to the name in their respective language. 20/11/13 Phil: Payments.php FunctionalExchangeRate was not defaulted appropriately when entering a supplier payment in FX from a bank account of the same currency selected and the transaction was posted immediately without update first. Fixed 19/11/13 Thumb/CQZ: Add webERP Chinese country sql including Chinese COA, currency, role,tax, transaction type etc which should be localized. 19/11/13 Thumb: Add '-' to telephone no pattern in CustomerBranches.php and WWW_Users.php. 19/11/13 Thumb: Correct translation of customer text and customer code in CustomerReceipt.php of locale file. 19/11/13 Thumb: Text 'settled transaction' position adjusted to proper position in PrintCustStatements.php. 18/11/13 Exson: Make inventory it as default to show inventory serial no in ConfirmDispatchControlled_Invoice.php. 18/11/13 Exson Make company name client side requirements consistent with server side in CompanyPreferences.php. 16/11/13 rchacon: Improves translation and format in PaymentMethods.php. 16/11/13 Phil: MacPhotoBiker reported shipment charges html5 type=number removed to use the class=number javascript' 12/11/13 rchacon: Allow translation of the subkey name in FormDesigner.php. 07/11/13 rchacon: Allow translation of the key name in FormDesigner.php. 7/11/13 Exson: Add check box to allow user to decide weather raw material is sellable or not. 7/11/13 Exson Revise the bin definition to NOT NULL DEFAULT '' as suggest by Tim to make it more ISO compatible. 06/11/13 rchacon: Allow multiline printing of salesorderdetails.narrative in quotations. 5/11/13 Phil: Fixed the warning error in GLAccountInquiry.php add change variable type to array to make min() and max() reasonable. Reported by Jo 04/11/13 icedlava: change insert new clone stock event to transaction as in Stocks.php for new item. 03/11/13 rchacon: Allow translate the name of the currency on CompanyPreferences.php. 3/11/13 Exson fixed the bug that discount id for category cannot be set and add an error message when there is no stockid set for the respective category. 03/11/13 Exson: Fi3/11/13 Exson: fixed bug by removing pattern and add no-illegal-chars to stockid in StockReorderLevel.php.xed bug in MiscFunctions.js allow '0' input as number. 01/11/13 rchacon: Allow translate the name of the currency on Currencies.php. 31/10/13 rchacon: Allow translate the name of the currency on CustomerReceipt.php and Payments.php. 30/10/13 rchacon: Allow insert different data on banktrans.ref and gltrans.narrative for the bank account on CustomerReceipt.php. Match the page_title_text with the MainMenuLinksArray option for Bank Account Payments Entry and Bank Account Receipts Entry. Regroup the General Ledger Transactions menu. 30/10/13 Exson: Add required attribute for Z_MakeNewCompany.php to avoid file void error and make it more user friendly. 30/10/13: Exson modify the locstock table change the bin to NULL to avoid stick sql standard constraint failed for those items without bin. 30/10/13 Exson: Modify the the insert new stocks event to transaction. 24/10/13 MailingGroupMaintenance.php, minor tag and other formatting corrections. 20/10/13 icedlava: Add StockClone.php script to create a new item with the same properties, image, cost, purchasing and pricing data as the selected item, and allow modification of image and general item details before cloning. 18/10/13 Paul T: ManualSecuritySchema.html, add missing tr tags, reduced doubled-closing td tags to one, and changed & to & for HTML. 18/10/13 Paul T: ManualInventory.html, add bracket to complete closing h3 tag. 15/10/13 Paul T: GoodsReceived.php, change variable name from OrderNumber to OrderNo. 11/10/13 Tim: Links for manual internal transfers and supplier payment link to allocations 9/10/13 Exson: commit the fixed "Unable to Locate Purchase Order Number" error when the PO is created by SO interface. Fixed provided by Tim and reported by Merci from webERP forum. 6/10/13 Phil: New script to show a grid of items by preferred supplier for placing purchase orders to the users's default inventory location - orders will be authorised if the user has authority and the auto-authorise config option is enabled. 3/10/13 icedlava: PO_Items.php with non-stock items still require GL Code in case of modified order at invoice time else SQL error is generated due to invalid GL Code. 2/10/13 David Lynn: Added new field url to suppliers modified SelectSupplier.php and Suppliers.php 28/9/13 wh_hsn: help with regular expression to trap quotes and backslashes for data-type="no-illegal-chars" 28/9/13 Phil: Followed Exson's example to set pattern to prevent dodgy characters in other scripts that were using a pattern that only allowed [a-zA-Z0-9] thus making it impossible to enter non latin characters. 11/9/13 icedlava: SelectCompletedOrder.php Fix SQL typo. 7/9/13 Exson: using javascript to set the pattern attribute based on a new attribute data-type and first script Stocks.php 7/9/13 icedlava: Fix PrintStatements.php to allow selection of alphanumeric customer codes in length to match database definition. 7/9/13 icedlava: StockStatus.php Allow dash in stock code again. -- Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz |
From: Phil D. <ph...@lo...> - 2013-11-29 23:03:35
|
Sorry just looked now.... All looks good to me - see attached - I can only suggest a re-check out. | svn: E175013: Access to '/p/web-erp/code/!svn/me' forbidden This doesn't look like the right path to me? Just cutting and pasting the checkout command: svn checkout --username=daintree svn+ssh://dai...@sv.../p/web-erp/code/trunk webERP so svn.code.sf.net/p/web-erp/code/trunk should do it - maybe !svn/me is causing an issue - not seen this before? Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 29/11/13 21:52, Tim Schofield wrote: > Phil: Have you had a chance to look at my svn access? > > Thanks > Tim > > On 28/11/2013, Tim Schofield <tim...@gm...> wrote: >> svn: E175013: Commit failed (details follow): >> svn: E175013: Access to '/p/web-erp/code/!svn/me' forbidden >> >> I have checked the correct ssh key is in sourceforge. >> >> Tim >> >> On 28 November 2013 08:08, Phil Daintree <ph...@lo...> wrote: >>> What is the issue with your svn access Tim? Let me know if I need to >>> look at it. >>> >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd - +64 (0)275 567890 >>> http://www.logicworks.co.nz >>> >>> On 28/11/13 05:21, Tim Schofield wrote: >>>> Ah yes, the deliver to name? >>>> >>>> Anyone know of any others? It seems I can't update svn but these >>>> changes are very simple. >>>> >>>> Thanks >>>> Tim >>>> >>>> On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: >>>>> I can verify that this issue is still there. >>>>> >>>>> I have a customer's company name has the word Hug's. >>>>> It will come up Hug/////s >>>>> >>>>> THis is customer customer name. So my invoices are all like this. >>>>> Same with customer addresses. >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html >>>>> Sent from the web-ERP-developers mailing list archive at Nabble.com. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>> organizations don't have a clear picture of how application performance >>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>> your >>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>> AppDynamics Pro! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into >>> your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >>> Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> -- >> Course View Towers, >> Plot 21 Yusuf Lule Road, >> Kampala >> T +256 (0) 312 314 418 >> M +256 (0) 752 963 325 >> www.weberpafrica.com >> Twitter: @TimSchofield2 >> Blog: http://weberpafrica.blogspot.co.uk/ >> > |
From: Phil D. <ph...@lo...> - 2013-11-29 22:51:02
|
We are collating country specific SQL databases - Exson has done one for Chinese already and it would be cool if we could get a couple more. We have them as SQL dump files under sql/mysql/country_sql Exson has modified the installer so a base database that contains appropriate base info. You can create one using the webERP/build/make_release.sh If you use linux (you may need to make it executable first) and replace all occurences of weberpdemo with the database name where you have a localised version of webERP populated. The new database at webERP/sql/mysql/country_sql/default.sql will contain no private data only the core tables and the structure for the remaining tables to be populated with the country data. Only the data from the following tables will be in the resulting database: accountgroups \ bankaccounts \ chartmaster \ companies \ cogsglpostings \ currencies \ holdreasons \ locations \ paymentterms \ reportlinks \ salesglpostings \ systypes \ taxauthorities \ taxgroups \ taxauthrates \ taxcategories \ taxprovinces \ www_users \ edi_orders_segs \ edi_orders_seg_groups \ config \ unitsofmeasure \ paymentmethods \ scripts \ securitygroups \ securitytokens \ securityroles \ accountsection \ of course you can have a look through the resulting file sql/mysql/country_sql/default.sql can be examined and edited to be sure there is nothing sensitive to your business. If you could compress and send to sub...@we... that would be great. -- Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz |
From: Tim S. <tim...@gm...> - 2013-11-29 08:52:20
|
Phil: Have you had a chance to look at my svn access? Thanks Tim On 28/11/2013, Tim Schofield <tim...@gm...> wrote: > svn: E175013: Commit failed (details follow): > svn: E175013: Access to '/p/web-erp/code/!svn/me' forbidden > > I have checked the correct ssh key is in sourceforge. > > Tim > > On 28 November 2013 08:08, Phil Daintree <ph...@lo...> wrote: >> What is the issue with your svn access Tim? Let me know if I need to >> look at it. >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890 >> http://www.logicworks.co.nz >> >> On 28/11/13 05:21, Tim Schofield wrote: >>> Ah yes, the deliver to name? >>> >>> Anyone know of any others? It seems I can't update svn but these >>> changes are very simple. >>> >>> Thanks >>> Tim >>> >>> On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: >>>> I can verify that this issue is still there. >>>> >>>> I have a customer's company name has the word Hug's. >>>> It will come up Hug/////s >>>> >>>> THis is customer customer name. So my invoices are all like this. >>>> Same with customer addresses. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html >>>> Sent from the web-ERP-developers mailing list archive at Nabble.com. >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>> organizations don't have a clear picture of how application performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>> your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>> AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into >> your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > -- > Course View Towers, > Plot 21 Yusuf Lule Road, > Kampala > T +256 (0) 312 314 418 > M +256 (0) 752 963 325 > www.weberpafrica.com > Twitter: @TimSchofield2 > Blog: http://weberpafrica.blogspot.co.uk/ > -- Course View Towers, Plot 21 Yusuf Lule Road, Kampala T +256 (0) 312 314 418 M +256 (0) 752 963 325 www.weberpafrica.com Twitter: @TimSchofield2 Blog: http://weberpafrica.blogspot.co.uk/ |
From: Tim S. <tim...@gm...> - 2013-11-28 10:04:56
|
Hi, it is intentional that these strings be "escaped" on saving to the database, and they should automatically be "unescaped" when webERP extracts them from the DB. They should show normally in the web interface. Tim On 28 November 2013 09:40, Nikolai <nn...@fr...> wrote: > help > > > On Wed, Nov 27, 2013 at 6:34 PM, > <web...@li...> wrote: >> >> Send Web-erp-developers mailing list submissions to >> web...@li... >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> or, via email, send a message with subject or body 'help' to >> web...@li... >> >> You can reach the person managing the list at >> web...@li... >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Web-erp-developers digest..." >> >> >> Today's Topics: >> >> 1. Re: Replicating slashes problem - escaping special chars for >> database insertion or HTML (ronwong) >> 2. Re: Replicating slashes problem - escaping special chars for >> database insertion or HTML (Tim Schofield) >> 3. Re: Replicating slashes problem - escaping special chars for >> database insertion or HTML (icedlava) >> 4. Re: Replicating slashes problem - escaping special chars for >> database insertion or HTML (icedlava) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 27 Nov 2013 07:42:34 -0800 (PST) >> From: ronwong <rwp...@rw...> >> Subject: Re: [WebERP-developers] Replicating slashes problem - >> escaping special chars for database insertion or HTML >> To: web...@li... >> Message-ID: <138...@n4...> >> Content-Type: text/plain; charset=us-ascii >> >> I can verify that this issue is still there. >> >> I have a customer's company name has the word Hug's. >> It will come up Hug/////s >> >> THis is customer customer name. So my invoices are all like this. >> Same with customer addresses. >> >> >> >> -- >> View this message in context: >> http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html >> Sent from the web-ERP-developers mailing list archive at Nabble.com. >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 27 Nov 2013 16:21:49 +0000 >> From: Tim Schofield <tim...@gm...> >> Subject: Re: [WebERP-developers] Replicating slashes problem - >> escaping special chars for database insertion or HTML >> To: webERP Developers <web...@li...> >> Message-ID: >> >> <CAB...@ma...> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Ah yes, the deliver to name? >> >> Anyone know of any others? It seems I can't update svn but these >> changes are very simple. >> >> Thanks >> Tim >> >> On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: >> > I can verify that this issue is still there. >> > >> > I have a customer's company name has the word Hug's. >> > It will come up Hug/////s >> > >> > THis is customer customer name. So my invoices are all like this. >> > Same with customer addresses. >> > >> > >> > >> > -- >> > View this message in context: >> > http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html >> > Sent from the web-ERP-developers mailing list archive at Nabble.com. >> > >> > >> > ------------------------------------------------------------------------------ >> > Rapidly troubleshoot problems before they affect your business. Most IT >> > organizations don't have a clear picture of how application performance >> > affects their revenue. With AppDynamics, you get 100% visibility into >> > your >> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> > AppDynamics Pro! >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > Web-erp-developers mailing list >> > Web...@li... >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> -- >> Course View Towers, >> Plot 21 Yusuf Lule Road, >> Kampala >> T +256 (0) 312 314 418 >> M +256 (0) 752 963 325 >> www.weberpafrica.com >> Twitter: @TimSchofield2 >> Blog: http://weberpafrica.blogspot.co.uk/ >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 28 Nov 2013 03:01:01 +1030 >> From: icedlava <ice...@gm...> >> Subject: Re: [WebERP-developers] Replicating slashes problem - >> escaping special chars for database insertion or HTML >> To: "webERP Developers" <web...@li...> >> Message-ID: <5BE...@gm...> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi Tim, >> >> Yes I agree there are some instances that we dealt with specifically but >> the problem remains and is more than just slashes replicating and is across >> the codebase in many fields. >> >> session.inc assumes all post, get and session vars are for the database >> and escape them via the db_escape function (and actually turns everything to >> entities as well for the db!). When the vars are not for the database at >> first instance, it causes problems. Try your test with Purchase order not >> sales order which we did fix in most parts. Here we also 'fill in a form' >> and the item is posted causing special char issues.They also come out on >> documentation that goes to customers. >> >> There are many other parts of the code base where special chars in general >> are not processed properly or also entities are not processed properly or >> doubly processed and saved in the database. >> >> *** we end up with entities in the database (which should not happen) >> causing display issues when output. *** >> >> *** we end up with special char issues like the multiplying slashes with >> each db save *** >> >> As you mentioned, the code in session.inc was written many years ago. It >> still uses magic quote calls (deprecated way back in php 5.3 2009) known not >> to be good solution for security although of course we try to support still >> all those on old php. >> >> It does not mean we cannot use best practice for handling data going into >> the database or out to display. >> >> It would be wonderful to have a system wide consistent solution to fix the >> entity issues in our database, that also will fix the escaping of data meant >> for display. It is better than just patching instances, and stripslashes() >> itself is not a full solution. I know it might be some work but happy to do >> it if we come up with agreed method - it would certainly fix a lot of >> customer complaint with display issues for me too :) >> >> I will think on some possible alternatives but i'm sure there are those >> out there with good solutions already. >> >> Thanks for all the useful comments! >> >> >> >> On 28 Nov 2013, at 0:57, Tim Schofield wrote: >> >> > Hi Jo, >> > >> > I meant I thought we had dealt with most instances. For instance >> > creating a sales order for smith's crisps does not generate this >> > error. I think the overwhelming majority of webERP scripts are of the >> > type: "Fill in a form, submit it and update the database". Fixing this >> > *seems* to be just a case of using stripslashes() on the item >> > description in the PO_Items.php script. >> > >> > This code in session.inc came about after a security review by Steve >> > Lord many years ago, and I would be very nervous about taking it out. >> > >> > Thanks >> > Tim >> > >> > On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: >> >> Hi Tim, >> >> >> >>> thought we had caught and dealt with these >> >> >> >> We caught an instance but I knew at the time it required a broader fix >> >> but was unable to identify best way ahead for it. >> >> >> >> I have raised the issue some time ago with Phil but not had time until >> >> now to look at the code and had a better look today. >> >> >> >>> Can you give some >> >>> examples of where it is still happening? >> >> >> >> Perhaps you can try replicate - it could be text with special char in >> >> any text field that is submitted in a form, a displayed value or input >> >> value that has some e.g. post var, get var or session var submitted to >> >> the database (some specific instances in the code have been addressed >> >> and fixed like you mentioned). >> >> >> >> I will try and provide an example: >> >> >> >> 1. Create an item with an item description such as "Smith's Chips" >> >> 2. Place a purchase order and select the item for your order. >> >> 3. At the PO_items.php function, with the line item for the order >> >> selected, click on Update Order lines and watch the description. You >> >> should get more slashes each time you click the Update Order lines >> >> button. >> >> >> >> I think, that we cannot assume in the sessions.inc file that we are >> >> going to add/update a post or get or session var to a database at first >> >> instance - it could be displayed only, it could be used in an input >> >> post >> >> field etc >> >> >> >> - when we save to the database call the relevant function e.g. >> >> mysqli_real_escape_string on non-html entity string (in weberp this is >> >> the DB_escape_string function but should be nonentity string e.g. use >> >> htmlspecialchars_decode not htmlspecialchars). >> >> >> >> - when we display in HTML use htmlspecialchar call to encode to >> >> entities >> >> where relevant. >> >> >> >> Anyway this is just some issue i came across a while ago and now >> >> revisiting in hope we can squash it for good - maybe someone has a >> >> solution already. >> >> >> >> Cheers! >> >> >> >> >> >> >> >> >> >> On 27 Nov 2013, at 18:57, Tim Schofield wrote: >> >> >> >>> Hi Jo, >> >>> >> >>> I thought we had caught and dealt with these. Can you give some >> >>> examples of where it is still happening? >> >>> >> >>> Thanks >> >>> Tim >> >>> >> >>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >> >>>> Currently we have sessions.inc processing all session, post and get >> >>>> vars in >> >>>> the same way. >> >>>> >> >>>> We make a big assumption here with DB_escape_string at line 59 and 66 >> >>>> (for >> >>>> single var and slightly different for arrays): >> >>>> >> >>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >> >>>> >> >>>> This assumes that we know what a function will do with the >> >>>> post/get/sessions >> >>>> vars and that they are going to be inserted/updated to a database. >> >>>> They are >> >>>> passed to the DB_escape_string function which returns (for mysqli): >> >>>> >> >>>> mysqli_real_escape_string($db, htmlspecialchars($String, >> >>>> ENT_COMPAT,'utf-8', >> >>>> false)); >> >>>> >> >>>> This is causing exponential slash addition to variables which are not >> >>>> entered to a database but instead posted to a HTML field value. Each >> >>>> time >> >>>> the field is updated the value is saved in the database with extra >> >>>> slashes >> >>>> when escaping a special char like a single quote. >> >>>> >> >>>> If we do actually need to do this variable processing in sessions.inc >> >>>> then >> >>>> perhaps we could decide what is more common displaying the var or >> >>>> insert/updating to a db. >> >>>> >> >>>> If we chose for example that displaying the var on the page is more >> >>>> common >> >>>> then we should change sessions inc for example on this line: >> >>>> >> >>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >> >>>> >> >>>> to >> >>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >> >>>> ENT_QUOTES,'UTF-8'); >> >>>> >> >>>> and for this case in DB_escape_string from: >> >>>> >> >>>> return mysqli_real_escape_string($db, htmlspecialchars($String, >> >>>> ENT_COMPAT,'utf-8', false)); >> >>>> to >> >>>> >> >>>> return mysqli_real_escape_string($db, >> >>>> htmlspecialchars_decode($String, >> >>>> ENT_COMPAT)); >> >>>> >> >>>> >> >>>> Then we need to call DB_escape_string on vars before we send to any >> >>>> insert >> >>>> or edit for database. >> >>>> >> >>>> On the other hand - we need to do the opposite if we assume it is >> >>>> more >> >>>> likely to post to the database. >> >>>> >> >>>> Perhaps there is another 3rd way to handle it? >> >>>> >> >>>> Thanks to all in advance for any feedback!! >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> ------------------------------------------------------------------------------ >> >>>> Rapidly troubleshoot problems before they affect your business. Most >> >>>> IT >> >>>> organizations don't have a clear picture of how application >> >>>> performance >> >>>> affects their revenue. With AppDynamics, you get 100% visibility into >> >>>> your >> >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> >>>> AppDynamics >> >>>> Pro! >> >>>> >> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> >>>> _______________________________________________ >> >>>> Web-erp-developers mailing list >> >>>> Web...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Course View Towers, >> >>> Plot 21 Yusuf Lule Road, >> >>> Kampala >> >>> T +256 (0) 312 314 418 >> >>> M +256 (0) 752 963 325 >> >>> www.weberpafrica.com >> >>> Twitter: @TimSchofield2 >> >>> Blog: http://weberpafrica.blogspot.co.uk/ >> >>> >> >>> >> >>> ------------------------------------------------------------------------------ >> >>> Rapidly troubleshoot problems before they affect your business. Most >> >>> IT >> >>> organizations don't have a clear picture of how application >> >>> performance >> >>> affects their revenue. With AppDynamics, you get 100% visibility into >> >>> your >> >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> >>> AppDynamics Pro! >> >>> >> >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> >>> _______________________________________________ >> >>> Web-erp-developers mailing list >> >>> Web...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Rapidly troubleshoot problems before they affect your business. Most IT >> >> organizations don't have a clear picture of how application performance >> >> affects their revenue. With AppDynamics, you get 100% visibility into >> >> your >> >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> >> AppDynamics Pro! >> >> >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> >> Web-erp-developers mailing list >> >> Web...@li... >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > >> > >> > >> > -- >> > Course View Towers, >> > Plot 21 Yusuf Lule Road, >> > Kampala >> > T +256 (0) 312 314 418 >> > M +256 (0) 752 963 325 >> > www.weberpafrica.com >> > Twitter: @TimSchofield2 >> > Blog: http://weberpafrica.blogspot.co.uk/ >> > >> > >> > ------------------------------------------------------------------------------ >> > Rapidly troubleshoot problems before they affect your business. Most IT >> > organizations don't have a clear picture of how application performance >> > affects their revenue. With AppDynamics, you get 100% visibility into >> > your >> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> > AppDynamics Pro! >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > Web-erp-developers mailing list >> > Web...@li... >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: signature.asc >> Type: application/pgp-signature >> Size: 535 bytes >> Desc: OpenPGP digital signature >> >> ------------------------------ >> >> Message: 4 >> Date: Thu, 28 Nov 2013 03:03:47 +1030 >> From: icedlava <ice...@gm...> >> Subject: Re: [WebERP-developers] Replicating slashes problem - >> escaping special chars for database insertion or HTML >> To: "webERP Developers" <web...@li...> >> Message-ID: <B6D...@gm...> >> Content-Type: text/plain; charset="us-ascii" >> >> There are many - also with entities saving in db and display issues caused >> by very same session.inc var processing. Those with special chars or >> entities in data will see it most in item names, customer or supplier names, >> text fields or anywhere there is data with entities or special chars. >> >> On 28 Nov 2013, at 2:51, Tim Schofield wrote: >> >> > Ah yes, the deliver to name? >> > >> > Anyone know of any others? It seems I can't update svn but these >> > changes are very simple. >> > >> > Thanks >> > Tim >> > >> > On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: >> >> I can verify that this issue is still there. >> >> >> >> I have a customer's company name has the word Hug's. >> >> It will come up Hug/////s >> >> >> >> THis is customer customer name. So my invoices are all like this. >> >> Same with customer addresses. >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> >> http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html >> >> Sent from the web-ERP-developers mailing list archive at Nabble.com. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Rapidly troubleshoot problems before they affect your business. Most IT >> >> organizations don't have a clear picture of how application performance >> >> affects their revenue. With AppDynamics, you get 100% visibility into >> >> your >> >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> >> AppDynamics Pro! >> >> >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> >> Web-erp-developers mailing list >> >> Web...@li... >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > >> > >> > >> > -- >> > Course View Towers, >> > Plot 21 Yusuf Lule Road, >> > Kampala >> > T +256 (0) 312 314 418 >> > M +256 (0) 752 963 325 >> > www.weberpafrica.com >> > Twitter: @TimSchofield2 >> > Blog: http://weberpafrica.blogspot.co.uk/ >> > >> > >> > ------------------------------------------------------------------------------ >> > Rapidly troubleshoot problems before they affect your business. Most IT >> > organizations don't have a clear picture of how application performance >> > affects their revenue. With AppDynamics, you get 100% visibility into >> > your >> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> > AppDynamics Pro! >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > Web-erp-developers mailing list >> > Web...@li... >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: signature.asc >> Type: application/pgp-signature >> Size: 535 bytes >> Desc: OpenPGP digital signature >> >> ------------------------------ >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> >> ------------------------------ >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> End of Web-erp-developers Digest, Vol 90, Issue 41 >> ************************************************** >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > -- Course View Towers, Plot 21 Yusuf Lule Road, Kampala T +256 (0) 312 314 418 M +256 (0) 752 963 325 www.weberpafrica.com Twitter: @TimSchofield2 Blog: http://weberpafrica.blogspot.co.uk/ |
From: Nikolai <nn...@fr...> - 2013-11-28 09:40:29
|
help On Wed, Nov 27, 2013 at 6:34 PM, < web...@li...> wrote: > Send Web-erp-developers mailing list submissions to > web...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > or, via email, send a message with subject or body 'help' to > web...@li... > > You can reach the person managing the list at > web...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Web-erp-developers digest..." > > > Today's Topics: > > 1. Re: Replicating slashes problem - escaping special chars for > database insertion or HTML (ronwong) > 2. Re: Replicating slashes problem - escaping special chars for > database insertion or HTML (Tim Schofield) > 3. Re: Replicating slashes problem - escaping special chars for > database insertion or HTML (icedlava) > 4. Re: Replicating slashes problem - escaping special chars for > database insertion or HTML (icedlava) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Nov 2013 07:42:34 -0800 (PST) > From: ronwong <rwp...@rw...> > Subject: Re: [WebERP-developers] Replicating slashes problem - > escaping special chars for database insertion or HTML > To: web...@li... > Message-ID: <138...@n4...> > Content-Type: text/plain; charset=us-ascii > > I can verify that this issue is still there. > > I have a customer's company name has the word Hug's. > It will come up Hug/////s > > THis is customer customer name. So my invoices are all like this. > Same with customer addresses. > > > > -- > View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 2 > Date: Wed, 27 Nov 2013 16:21:49 +0000 > From: Tim Schofield <tim...@gm...> > Subject: Re: [WebERP-developers] Replicating slashes problem - > escaping special chars for database insertion or HTML > To: webERP Developers <web...@li...> > Message-ID: > < > CAB...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > Ah yes, the deliver to name? > > Anyone know of any others? It seems I can't update svn but these > changes are very simple. > > Thanks > Tim > > On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: > > I can verify that this issue is still there. > > > > I have a customer's company name has the word Hug's. > > It will come up Hug/////s > > > > THis is customer customer name. So my invoices are all like this. > > Same with customer addresses. > > > > > > > > -- > > View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html > > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > > > > ------------------------------------------------------------------------------ > > Rapidly troubleshoot problems before they affect your business. Most IT > > organizations don't have a clear picture of how application performance > > affects their revenue. With AppDynamics, you get 100% visibility into > your > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > > > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > -- > Course View Towers, > Plot 21 Yusuf Lule Road, > Kampala > T +256 (0) 312 314 418 > M +256 (0) 752 963 325 > www.weberpafrica.com > Twitter: @TimSchofield2 > Blog: http://weberpafrica.blogspot.co.uk/ > > > > ------------------------------ > > Message: 3 > Date: Thu, 28 Nov 2013 03:01:01 +1030 > From: icedlava <ice...@gm...> > Subject: Re: [WebERP-developers] Replicating slashes problem - > escaping special chars for database insertion or HTML > To: "webERP Developers" <web...@li...> > Message-ID: <5BE...@gm...> > Content-Type: text/plain; charset="us-ascii" > > Hi Tim, > > Yes I agree there are some instances that we dealt with specifically but > the problem remains and is more than just slashes replicating and is across > the codebase in many fields. > > session.inc assumes all post, get and session vars are for the database > and escape them via the db_escape function (and actually turns everything > to entities as well for the db!). When the vars are not for the database at > first instance, it causes problems. Try your test with Purchase order not > sales order which we did fix in most parts. Here we also 'fill in a form' > and the item is posted causing special char issues.They also come out on > documentation that goes to customers. > > There are many other parts of the code base where special chars in general > are not processed properly or also entities are not processed properly or > doubly processed and saved in the database. > > *** we end up with entities in the database (which should not happen) > causing display issues when output. *** > > *** we end up with special char issues like the multiplying slashes with > each db save *** > > As you mentioned, the code in session.inc was written many years ago. It > still uses magic quote calls (deprecated way back in php 5.3 2009) known > not to be good solution for security although of course we try to support > still all those on old php. > > It does not mean we cannot use best practice for handling data going into > the database or out to display. > > It would be wonderful to have a system wide consistent solution to fix the > entity issues in our database, that also will fix the escaping of data > meant for display. It is better than just patching instances, and > stripslashes() itself is not a full solution. I know it might be some work > but happy to do it if we come up with agreed method - it would certainly > fix a lot of customer complaint with display issues for me too :) > > I will think on some possible alternatives but i'm sure there are those > out there with good solutions already. > > Thanks for all the useful comments! > > > > On 28 Nov 2013, at 0:57, Tim Schofield wrote: > > > Hi Jo, > > > > I meant I thought we had dealt with most instances. For instance > > creating a sales order for smith's crisps does not generate this > > error. I think the overwhelming majority of webERP scripts are of the > > type: "Fill in a form, submit it and update the database". Fixing this > > *seems* to be just a case of using stripslashes() on the item > > description in the PO_Items.php script. > > > > This code in session.inc came about after a security review by Steve > > Lord many years ago, and I would be very nervous about taking it out. > > > > Thanks > > Tim > > > > On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: > >> Hi Tim, > >> > >>> thought we had caught and dealt with these > >> > >> We caught an instance but I knew at the time it required a broader fix > >> but was unable to identify best way ahead for it. > >> > >> I have raised the issue some time ago with Phil but not had time until > >> now to look at the code and had a better look today. > >> > >>> Can you give some > >>> examples of where it is still happening? > >> > >> Perhaps you can try replicate - it could be text with special char in > >> any text field that is submitted in a form, a displayed value or input > >> value that has some e.g. post var, get var or session var submitted to > >> the database (some specific instances in the code have been addressed > >> and fixed like you mentioned). > >> > >> I will try and provide an example: > >> > >> 1. Create an item with an item description such as "Smith's Chips" > >> 2. Place a purchase order and select the item for your order. > >> 3. At the PO_items.php function, with the line item for the order > >> selected, click on Update Order lines and watch the description. You > >> should get more slashes each time you click the Update Order lines > >> button. > >> > >> I think, that we cannot assume in the sessions.inc file that we are > >> going to add/update a post or get or session var to a database at first > >> instance - it could be displayed only, it could be used in an input post > >> field etc > >> > >> - when we save to the database call the relevant function e.g. > >> mysqli_real_escape_string on non-html entity string (in weberp this is > >> the DB_escape_string function but should be nonentity string e.g. use > >> htmlspecialchars_decode not htmlspecialchars). > >> > >> - when we display in HTML use htmlspecialchar call to encode to entities > >> where relevant. > >> > >> Anyway this is just some issue i came across a while ago and now > >> revisiting in hope we can squash it for good - maybe someone has a > >> solution already. > >> > >> Cheers! > >> > >> > >> > >> > >> On 27 Nov 2013, at 18:57, Tim Schofield wrote: > >> > >>> Hi Jo, > >>> > >>> I thought we had caught and dealt with these. Can you give some > >>> examples of where it is still happening? > >>> > >>> Thanks > >>> Tim > >>> > >>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: > >>>> Currently we have sessions.inc processing all session, post and get > >>>> vars in > >>>> the same way. > >>>> > >>>> We make a big assumption here with DB_escape_string at line 59 and 66 > >>>> (for > >>>> single var and slightly different for arrays): > >>>> > >>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); > >>>> > >>>> This assumes that we know what a function will do with the > >>>> post/get/sessions > >>>> vars and that they are going to be inserted/updated to a database. > >>>> They are > >>>> passed to the DB_escape_string function which returns (for mysqli): > >>>> > >>>> mysqli_real_escape_string($db, htmlspecialchars($String, > >>>> ENT_COMPAT,'utf-8', > >>>> false)); > >>>> > >>>> This is causing exponential slash addition to variables which are not > >>>> entered to a database but instead posted to a HTML field value. Each > >>>> time > >>>> the field is updated the value is saved in the database with extra > >>>> slashes > >>>> when escaping a special char like a single quote. > >>>> > >>>> If we do actually need to do this variable processing in sessions.inc > >>>> then > >>>> perhaps we could decide what is more common displaying the var or > >>>> insert/updating to a db. > >>>> > >>>> If we chose for example that displaying the var on the page is more > >>>> common > >>>> then we should change sessions inc for example on this line: > >>>> > >>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) > >>>> > >>>> to > >>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, > >>>> ENT_QUOTES,'UTF-8'); > >>>> > >>>> and for this case in DB_escape_string from: > >>>> > >>>> return mysqli_real_escape_string($db, htmlspecialchars($String, > >>>> ENT_COMPAT,'utf-8', false)); > >>>> to > >>>> > >>>> return mysqli_real_escape_string($db, > >>>> htmlspecialchars_decode($String, > >>>> ENT_COMPAT)); > >>>> > >>>> > >>>> Then we need to call DB_escape_string on vars before we send to any > >>>> insert > >>>> or edit for database. > >>>> > >>>> On the other hand - we need to do the opposite if we assume it is > >>>> more > >>>> likely to post to the database. > >>>> > >>>> Perhaps there is another 3rd way to handle it? > >>>> > >>>> Thanks to all in advance for any feedback!! > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Rapidly troubleshoot problems before they affect your business. Most > >>>> IT > >>>> organizations don't have a clear picture of how application > >>>> performance > >>>> affects their revenue. With AppDynamics, you get 100% visibility into > >>>> your > >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > >>>> AppDynamics > >>>> Pro! > >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > >>>> _______________________________________________ > >>>> Web-erp-developers mailing list > >>>> Web...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>> > >>> > >>> > >>> > >>> -- > >>> Course View Towers, > >>> Plot 21 Yusuf Lule Road, > >>> Kampala > >>> T +256 (0) 312 314 418 > >>> M +256 (0) 752 963 325 > >>> www.weberpafrica.com > >>> Twitter: @TimSchofield2 > >>> Blog: http://weberpafrica.blogspot.co.uk/ > >>> > >>> > ------------------------------------------------------------------------------ > >>> Rapidly troubleshoot problems before they affect your business. Most > >>> IT > >>> organizations don't have a clear picture of how application > >>> performance > >>> affects their revenue. With AppDynamics, you get 100% visibility into > >>> your > >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > >>> AppDynamics Pro! > >>> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > >>> _______________________________________________ > >>> Web-erp-developers mailing list > >>> Web...@li... > >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >> > >> > ------------------------------------------------------------------------------ > >> Rapidly troubleshoot problems before they affect your business. Most IT > >> organizations don't have a clear picture of how application performance > >> affects their revenue. With AppDynamics, you get 100% visibility into > your > >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > >> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Web-erp-developers mailing list > >> Web...@li... > >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > -- > > Course View Towers, > > Plot 21 Yusuf Lule Road, > > Kampala > > T +256 (0) 312 314 418 > > M +256 (0) 752 963 325 > > www.weberpafrica.com > > Twitter: @TimSchofield2 > > Blog: http://weberpafrica.blogspot.co.uk/ > > > > > ------------------------------------------------------------------------------ > > Rapidly troubleshoot problems before they affect your business. Most IT > > organizations don't have a clear picture of how application performance > > affects their revenue. With AppDynamics, you get 100% visibility into > your > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > > > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 535 bytes > Desc: OpenPGP digital signature > > ------------------------------ > > Message: 4 > Date: Thu, 28 Nov 2013 03:03:47 +1030 > From: icedlava <ice...@gm...> > Subject: Re: [WebERP-developers] Replicating slashes problem - > escaping special chars for database insertion or HTML > To: "webERP Developers" <web...@li...> > Message-ID: <B6D...@gm...> > Content-Type: text/plain; charset="us-ascii" > > There are many - also with entities saving in db and display issues caused > by very same session.inc var processing. Those with special chars or > entities in data will see it most in item names, customer or supplier > names, text fields or anywhere there is data with entities or special chars. > > On 28 Nov 2013, at 2:51, Tim Schofield wrote: > > > Ah yes, the deliver to name? > > > > Anyone know of any others? It seems I can't update svn but these > > changes are very simple. > > > > Thanks > > Tim > > > > On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: > >> I can verify that this issue is still there. > >> > >> I have a customer's company name has the word Hug's. > >> It will come up Hug/////s > >> > >> THis is customer customer name. So my invoices are all like this. > >> Same with customer addresses. > >> > >> > >> > >> -- > >> View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html > >> Sent from the web-ERP-developers mailing list archive at Nabble.com. > >> > >> > ------------------------------------------------------------------------------ > >> Rapidly troubleshoot problems before they affect your business. Most IT > >> organizations don't have a clear picture of how application performance > >> affects their revenue. With AppDynamics, you get 100% visibility into > your > >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > >> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Web-erp-developers mailing list > >> Web...@li... > >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > -- > > Course View Towers, > > Plot 21 Yusuf Lule Road, > > Kampala > > T +256 (0) 312 314 418 > > M +256 (0) 752 963 325 > > www.weberpafrica.com > > Twitter: @TimSchofield2 > > Blog: http://weberpafrica.blogspot.co.uk/ > > > > > ------------------------------------------------------------------------------ > > Rapidly troubleshoot problems before they affect your business. Most IT > > organizations don't have a clear picture of how application performance > > affects their revenue. With AppDynamics, you get 100% visibility into > your > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > > > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 535 bytes > Desc: OpenPGP digital signature > > ------------------------------ > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > > ------------------------------ > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > End of Web-erp-developers Digest, Vol 90, Issue 41 > ************************************************** > > |
From: Tim S. <tim...@gm...> - 2013-11-28 09:28:53
|
svn: E175013: Commit failed (details follow): svn: E175013: Access to '/p/web-erp/code/!svn/me' forbidden I have checked the correct ssh key is in sourceforge. Tim On 28 November 2013 08:08, Phil Daintree <ph...@lo...> wrote: > What is the issue with your svn access Tim? Let me know if I need to > look at it. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 28/11/13 05:21, Tim Schofield wrote: >> Ah yes, the deliver to name? >> >> Anyone know of any others? It seems I can't update svn but these >> changes are very simple. >> >> Thanks >> Tim >> >> On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: >>> I can verify that this issue is still there. >>> >>> I have a customer's company name has the word Hug's. >>> It will come up Hug/////s >>> >>> THis is customer customer name. So my invoices are all like this. >>> Same with customer addresses. >>> >>> >>> >>> -- >>> View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html >>> Sent from the web-ERP-developers mailing list archive at Nabble.com. >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers -- Course View Towers, Plot 21 Yusuf Lule Road, Kampala T +256 (0) 312 314 418 M +256 (0) 752 963 325 www.weberpafrica.com Twitter: @TimSchofield2 Blog: http://weberpafrica.blogspot.co.uk/ |
From: icedlava <ice...@gm...> - 2013-11-28 08:56:10
|
> Yes there is a real risk with this work... Yes definitely and that is why I have not attempted to add a quick solution - it needs thought and agreement and unfortunately most likely a lot of repetitive work. I'm usually pretty good at doing those boring chores :) I also agree that indeed Tim is correct on stripslashes - i wasn't clear in my last post - it fixes that immediate problem which many probably will need. I will try and find a solution that we can all be confident with, and that we can handle in terms of work - unless someone has that solution already we can borrow :) Again, thanks to everyone for the useful feedback. Best! On 28 Nov 2013, at 18:39, Phil Daintree wrote: > Yes there is a real risk with this work... > > On the one hand I know the real solution is to deal with the SQL at the > point of the SQL .... but on the other hand there is one heck of a lot > of it and what we have works mostly. > > A good solution would be most welcome :-) > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 28/11/13 05:49, Tim Schofield wrote: >> Hi Jo, I guess what I don't understand is what changing the code will >> give us? At the moment we have a solution that works (albeit the >> occasional change to remove the slashes, but most of these have been >> done) and has passed the security audits we have had done. I am not >> wedded to the current solution, it's more a case of "if it ain't broke >> why fix it?". >> >> Tim >> >> On 27 November 2013 16:43, icedlava <ice...@gm...> wrote: >>> Tim, >>> using stripslahes with our current code covers up the problem, but doesn't fix the root issue. >>> >>> I'm happy to do the work to fix it if it will give us a clean solution. >>> >>> On 28 Nov 2013, at 3:11, Tim Schofield wrote: >>> >>>> Hi Jo, yes I did try it with purchase orders and see the problem. >>>> Doesn't changing line 741 to >>>> >>>> <td><input type="text" name="ItemDescription' . $POLine->LineNo . '" >>>> size="30" value="' . stripslashes($POLine->ItemDescription) . '" >>>> /></td> >>>> >>>> fix the problem? >>>> >>>> Likewise in DeliveryDetails.php changing line 998 to >>>> >>>> >>>> <td><input type="text" autofocus="autofocus" >>>> required="required" size="42" maxlength="40" name="DeliverTo" value="' >>>> . stripslashes($_SESSION['Items'.$identifier]->DeliverTo) . '" >>>> title="' . _('Enter the name of the customer to deliver this order >>>> to') . '" /></td> >>>> >>>> >>>> I may be missing something. There are actually only a few scripts >>>> where the POST data isn't immediately posted to the DB. >>>> >>>> thanks >>>> Tim >>>> >>>> >>>> >>>> On 27 November 2013 16:31, icedlava <ice...@gm...> wrote: >>>>> Hi Tim, >>>>> >>>>> Yes I agree there are some instances that we dealt with specifically but the problem remains and is more than just slashes replicating and is across the codebase in many fields. >>>>> >>>>> session.inc assumes all post, get and session vars are for the database and escape them via the db_escape function (and actually turns everything to entities as well for the db!). When the vars are not for the database at first instance, it causes problems. Try your test with Purchase order not sales order which we did fix in most parts. Here we also 'fill in a form' and the item is posted causing special char issues.They also come out on documentation that goes to customers. >>>>> >>>>> There are many other parts of the code base where special chars in general are not processed properly or also entities are not processed properly or doubly processed and saved in the database. >>>>> >>>>> *** we end up with entities in the database (which should not happen) causing display issues when output. *** >>>>> >>>>> *** we end up with special char issues like the multiplying slashes with each db save *** >>>>> >>>>> As you mentioned, the code in session.inc was written many years ago. It still uses magic quote calls (deprecated way back in php 5.3 2009) known not to be good solution for security although of course we try to support still all those on old php. >>>>> >>>>> It does not mean we cannot use best practice for handling data going into the database or out to display. >>>>> >>>>> It would be wonderful to have a system wide consistent solution to fix the entity issues in our database, that also will fix the escaping of data meant for display. It is better than just patching instances, and stripslashes() itself is not a full solution. I know it might be some work but happy to do it if we come up with agreed method - it would certainly fix a lot of customer complaint with display issues for me too :) >>>>> >>>>> I will think on some possible alternatives but i'm sure there are those out there with good solutions already. >>>>> >>>>> Thanks for all the useful comments! >>>>> >>>>> >>>>> >>>>> On 28 Nov 2013, at 0:57, Tim Schofield wrote: >>>>> >>>>>> Hi Jo, >>>>>> >>>>>> I meant I thought we had dealt with most instances. For instance >>>>>> creating a sales order for smith's crisps does not generate this >>>>>> error. I think the overwhelming majority of webERP scripts are of the >>>>>> type: "Fill in a form, submit it and update the database". Fixing this >>>>>> *seems* to be just a case of using stripslashes() on the item >>>>>> description in the PO_Items.php script. >>>>>> >>>>>> This code in session.inc came about after a security review by Steve >>>>>> Lord many years ago, and I would be very nervous about taking it out. >>>>>> >>>>>> Thanks >>>>>> Tim >>>>>> >>>>>> On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: >>>>>>> Hi Tim, >>>>>>> >>>>>>>> thought we had caught and dealt with these >>>>>>> We caught an instance but I knew at the time it required a broader fix >>>>>>> but was unable to identify best way ahead for it. >>>>>>> >>>>>>> I have raised the issue some time ago with Phil but not had time until >>>>>>> now to look at the code and had a better look today. >>>>>>> >>>>>>>> Can you give some >>>>>>>> examples of where it is still happening? >>>>>>> Perhaps you can try replicate - it could be text with special char in >>>>>>> any text field that is submitted in a form, a displayed value or input >>>>>>> value that has some e.g. post var, get var or session var submitted to >>>>>>> the database (some specific instances in the code have been addressed >>>>>>> and fixed like you mentioned). >>>>>>> >>>>>>> I will try and provide an example: >>>>>>> >>>>>>> 1. Create an item with an item description such as "Smith's Chips" >>>>>>> 2. Place a purchase order and select the item for your order. >>>>>>> 3. At the PO_items.php function, with the line item for the order >>>>>>> selected, click on Update Order lines and watch the description. You >>>>>>> should get more slashes each time you click the Update Order lines >>>>>>> button. >>>>>>> >>>>>>> I think, that we cannot assume in the sessions.inc file that we are >>>>>>> going to add/update a post or get or session var to a database at first >>>>>>> instance - it could be displayed only, it could be used in an input post >>>>>>> field etc >>>>>>> >>>>>>> - when we save to the database call the relevant function e.g. >>>>>>> mysqli_real_escape_string on non-html entity string (in weberp this is >>>>>>> the DB_escape_string function but should be nonentity string e.g. use >>>>>>> htmlspecialchars_decode not htmlspecialchars). >>>>>>> >>>>>>> - when we display in HTML use htmlspecialchar call to encode to entities >>>>>>> where relevant. >>>>>>> >>>>>>> Anyway this is just some issue i came across a while ago and now >>>>>>> revisiting in hope we can squash it for good - maybe someone has a >>>>>>> solution already. >>>>>>> >>>>>>> Cheers! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 27 Nov 2013, at 18:57, Tim Schofield wrote: >>>>>>> >>>>>>>> Hi Jo, >>>>>>>> >>>>>>>> I thought we had caught and dealt with these. Can you give some >>>>>>>> examples of where it is still happening? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Tim >>>>>>>> >>>>>>>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >>>>>>>>> Currently we have sessions.inc processing all session, post and get >>>>>>>>> vars in >>>>>>>>> the same way. >>>>>>>>> >>>>>>>>> We make a big assumption here with DB_escape_string at line 59 and 66 >>>>>>>>> (for >>>>>>>>> single var and slightly different for arrays): >>>>>>>>> >>>>>>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >>>>>>>>> >>>>>>>>> This assumes that we know what a function will do with the >>>>>>>>> post/get/sessions >>>>>>>>> vars and that they are going to be inserted/updated to a database. >>>>>>>>> They are >>>>>>>>> passed to the DB_escape_string function which returns (for mysqli): >>>>>>>>> >>>>>>>>> mysqli_real_escape_string($db, htmlspecialchars($String, >>>>>>>>> ENT_COMPAT,'utf-8', >>>>>>>>> false)); >>>>>>>>> >>>>>>>>> This is causing exponential slash addition to variables which are not >>>>>>>>> entered to a database but instead posted to a HTML field value. Each >>>>>>>>> time >>>>>>>>> the field is updated the value is saved in the database with extra >>>>>>>>> slashes >>>>>>>>> when escaping a special char like a single quote. >>>>>>>>> >>>>>>>>> If we do actually need to do this variable processing in sessions.inc >>>>>>>>> then >>>>>>>>> perhaps we could decide what is more common displaying the var or >>>>>>>>> insert/updating to a db. >>>>>>>>> >>>>>>>>> If we chose for example that displaying the var on the page is more >>>>>>>>> common >>>>>>>>> then we should change sessions inc for example on this line: >>>>>>>>> >>>>>>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >>>>>>>>> >>>>>>>>> to >>>>>>>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >>>>>>>>> ENT_QUOTES,'UTF-8'); >>>>>>>>> >>>>>>>>> and for this case in DB_escape_string from: >>>>>>>>> >>>>>>>>> return mysqli_real_escape_string($db, htmlspecialchars($String, >>>>>>>>> ENT_COMPAT,'utf-8', false)); >>>>>>>>> to >>>>>>>>> >>>>>>>>> return mysqli_real_escape_string($db, >>>>>>>>> htmlspecialchars_decode($String, >>>>>>>>> ENT_COMPAT)); >>>>>>>>> >>>>>>>>> >>>>>>>>> Then we need to call DB_escape_string on vars before we send to any >>>>>>>>> insert >>>>>>>>> or edit for database. >>>>>>>>> >>>>>>>>> On the other hand - we need to do the opposite if we assume it is >>>>>>>>> more >>>>>>>>> likely to post to the database. >>>>>>>>> >>>>>>>>> Perhaps there is another 3rd way to handle it? >>>>>>>>> >>>>>>>>> Thanks to all in advance for any feedback!! >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>>>>>> IT >>>>>>>>> organizations don't have a clear picture of how application >>>>>>>>> performance >>>>>>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>>>>>> your >>>>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>>>>>> AppDynamics >>>>>>>>> Pro! >>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>>>>> _______________________________________________ >>>>>>>>> Web-erp-developers mailing list >>>>>>>>> Web...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Course View Towers, >>>>>>>> Plot 21 Yusuf Lule Road, >>>>>>>> Kampala >>>>>>>> T +256 (0) 312 314 418 >>>>>>>> M +256 (0) 752 963 325 >>>>>>>> www.weberpafrica.com >>>>>>>> Twitter: @TimSchofield2 >>>>>>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>>>>> IT >>>>>>>> organizations don't have a clear picture of how application >>>>>>>> performance >>>>>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>>>>> your >>>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>>>>> AppDynamics Pro! >>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>>>> _______________________________________________ >>>>>>>> Web-erp-developers mailing list >>>>>>>> Web...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>>>> organizations don't have a clear picture of how application performance >>>>>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Web-erp-developers mailing list >>>>>>> Web...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>> >>>>>> >>>>>> -- >>>>>> Course View Towers, >>>>>> Plot 21 Yusuf Lule Road, >>>>>> Kampala >>>>>> T +256 (0) 312 314 418 >>>>>> M +256 (0) 752 963 325 >>>>>> www.weberpafrica.com >>>>>> Twitter: @TimSchofield2 >>>>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>>> organizations don't have a clear picture of how application performance >>>>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> ------------------------------------------------------------------------------ >>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>> organizations don't have a clear picture of how application performance >>>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>> >>>> >>>> -- >>>> Course View Towers, >>>> Plot 21 Yusuf Lule Road, >>>> Kampala >>>> T +256 (0) 312 314 418 >>>> M +256 (0) 752 963 325 >>>> www.weberpafrica.com >>>> Twitter: @TimSchofield2 >>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>> organizations don't have a clear picture of how application performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >> >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: icedlava <ice...@gm...> - 2013-11-28 08:42:47
|
Hi Phil, Thanks for your ideas on the GL entry creation currently in place. From first looks I believe there are bugs in some cases (depending on GL on/off for CR or DR) on creation of the bank transaction/journals. Sometimes in fact it 'works' properly as you had previously described, other cases not- and (perhaps it was too late at night for me ..) it seems it might be dependent on type of account used in e.g. the receipting. In any case I will go through code rigourously for all the points you mention before I touch any code there. I will still have concern for any dependencies on the sys type apart from the obvious in General Ledger and the Receipts/Payments menus. Others might now of cases. Many thanks to all for the feedback! On 28 Nov 2013, at 18:49, Phil Daintree wrote: > You are right - there is no need to make the GL entries creation contingent on the integration with debtors or creditors flags being enabled. Perhaps we could just remove those. However, some may just not want any GL and want to use the bank functionality without the GL. I assumed that if the creditors integration was off then no bank payments should create GL journals and likewise for debtors and bank receipts. This assumption may not be valid - happy if you think it is better to take this check out. > > It could be that transfers are created with a systype=12 rather than 2 and that could be causing the trouble as there is some interesting code to bring up the customer's name when the receipt is a customer receipt - and equivalent code to bring up the supplier when it is an AP payment. I am sure this will just be a display issue with that script. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 28/11/13 01:43, icedlava wrote: >>> I think the fix needs to be in the GLJournalInquiry.php so it shows the journals created correctly. >> OK i'll look. >> >> But why is it we need GL on to make a GL transaction for bank accounts through General Ledger - bank receipt/payment, but do not need GL on to make a GL transaction in the journal area? >> If we go through the General Ledger menu then for consistency should not a transaction result in a GL entry in gltrans with or without GL switch on - this would be consistent instead of one doing so and one not doing so? >> >> Then, I could also fix the GLJournalInquiry if we can as you pointed out discriminate between GL payments and receipts and other bank transactions it should not be too difficult (i.e. 1 for GL payments, 2 for GL receipts). >> >> Thanks for your help! >> >> >> >> >> >> On 27 Nov 2013, at 17:25, Phil Daintree wrote: >> >>> I think the fix needs to be in the GLJournalInquiry.php so it shows the journals created correctly. >>> >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd - +64 (0)275 567890 >>> http://www.logicworks.co.nz >>> >>> On 27/11/13 19:52, iced lava wrote: >>>>> It is not necessary to modify the transaction type in the gltrans table. >>>> To see the bank transactions in the general journal enquiries we do. >>>> >>>>> Can you point me to where the manual said the integration should be off when taking on GL balances? >>>> I will take another look and let you know - i know i found it confusing when i first used webERP and went on a google hunt. It's been some time since i looked at that part of the manual and i've always turned on GL for bank transactions and off for everything else added through the General Ledger menu. >>>> >>>>> Which listings are you not able to see the balances ... script names ideally please >>>> GLJournalInquiry.php - will not display bank transaction journals. >>>> >>>> And yes, trial balance shows balances correctly :) >>>> >>>> Thanks for taking a look. >>>> >>>> >>>> On Wed, Nov 27, 2013 at 5:09 PM, Phil Daintree <ph...@lo... <mailto:ph...@lo...>> wrote: >>>> >>>> It is not necessary to modify the transaction type in the gltrans >>>> table. >>>> Can you point me to where the manual said the integration should >>>> be off when taking on GL balances? I can see where it says this in >>>> relation to setting up debtors and creditors balances i.e the open >>>> items in the sub-ledgers. >>>> Which listings are you not able to see the balances ... script >>>> names ideally please. Maybe this is where the problem lies - >>>> assuming the trial balance shows the balances correctly! >>>> >>>> >>>> Phil >>>> >>>> Phil Daintree >>>> Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> >>>> http://www.logicworks.co.nz >>>> >>>> On 27/11/13 15:23, iced lava wrote: >>>>> Provisos and issue remaining: >>>>> >>>>> 1. The opening balance transaction in the example with GL trans >>>>> should occur with GL turned off (if instructions in manual are >>>>> correct) >>>>> >>>>> 2. The behaviour cannot be applied generally to transactions >>>>> through General Ledger unless the these transactions are >>>>> displayed, such as bank fees, in the bank reconcilliation >>>>> listings. They do not display when type is set to 0 (general >>>>> journal) in the gltrans table and so fix should be determined for >>>>> the reconcilliation functions. >>>>> >>>>> Comments appreciated. >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> On Wed, Nov 27, 2013 at 12:44 PM, iced lava <ice...@gm... >>>>> <mailto:ice...@gm...>> wrote: >>>>> >>>>> As an example: >>>>> I note that if I enter the bank balances at 30 June with GL >>>>> on, I can change the Type of transaction in the gltrans table >>>>> to 0 (general journal). Appropriate [next] incremented >>>>> general journal numbers a can provided to these transactions >>>>> by editing as well [and systype incremented accordingly and >>>>> chart detail also adjusted]. >>>>> >>>>> If this is done then the year closing journals appear as >>>>> required in the journal listings, on the trial balance and >>>>> the bank listings and reports also seem correct (transactions >>>>> are left untouched in banktrans table). >>>>> >>>>> >>>>> This is as expected for the entry made through General Ledger >>>>> bank receipts. >>>>> >>>>> >>>>> Is this a bug? >>>>> Should this behaviour also happen for other bank receipts and >>>>> payments made through General Ledger option? I would think so. >>>>> >>>>> I can fix if required. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Nov 27, 2013 at 12:04 PM, iced lava >>>>> <ice...@gm... <mailto:ice...@gm...>> wrote: >>>>> >>>>> Could I have confirmation on what should happen when bank >>>>> account balances are entered in for end of year closing >>>>> balances eg at 30 June. >>>>> >>>>> Here is the current behaviour I see in latest webERP. >>>>> Note that usually according to documentation year end >>>>> balances should be done with GL integration off. >>>>> >>>>> 1. With GL integration turned off, the bank balances are >>>>> taken on at 30 June by entering a receipt (General Ledger >>>>> - Bank account receipt entry). >>>>> >>>>> * This transaction only appears as a single entry in >>>>> the banktrans table - nowhere else >>>>> * there is no corresponding balancing transaction - it >>>>> would have to be made manually >>>>> * as such the bank account balances do not appear in >>>>> any 30 June trial balance >>>>> * a listing of 30 June journal entries does not show >>>>> any 30 June entries for any bank accounts GL accounts >>>>> * trial balance as a consequence does not have any >>>>> entries for these bank transactions >>>>> >>>>> >>>>> 2. With the GL integration turned on - if the bank >>>>> balances are taken on at 30 June by entering a receipt >>>>> (General Ledger - Bank account receipt entry) >>>>> >>>>> * The transaction appears as an entry in the banktrans >>>>> table >>>>> * there is a corresponding transaction in the gltrans >>>>> table and the balancing transaction(s) >>>>> * the chartdetails table has entries for these transactions >>>>> * trial balance shows an entry for these bank accounts >>>>> * the listing of 30 June journal entries does not show >>>>> anything for the bank accounts >>>>> * the type in the gltrans table is type 12 - bank >>>>> transaction, not 0 for general journal >>>>> >>>>> >>>>> This is causing confusing with customer. >>>>> >>>>> The behaviour I thought would happen is that any bank >>>>> transactions entered through the General Ledger - Bank >>>>> account [receipt/payment] should in fact have entries in >>>>> gltrans table and subsequent entries in the chart >>>>> details. They then should appear in journal reports. >>>>> >>>>> This would be in contrast to payments/receipts made via >>>>> the Payments and Receipts menus for debtors and creditors. >>>>> >>>>> However, for bank fees and such which must be entered >>>>> through General Ledger payment (not a creditor), this >>>>> poses a problem as the amounts will show in bank account >>>>> transaction listings/reconcilliations - as they should. >>>>> Howevrer they will never show as a general journal or >>>>> reports as such (they are trans 12 not 0). >>>>> >>>>> Thanks in advance for any advice. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>> organizations don't have a clear picture of how application performance >>>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>> >>>>> >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... <mailto:Web...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. >>>> Most IT >>>> organizations don't have a clear picture of how application >>>> performance >>>> affects their revenue. With AppDynamics, you get 100% visibility >>>> into your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>> AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> <mailto:Web...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>> organizations don't have a clear picture of how application performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> >>>> >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> >>> >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: Phil D. <ph...@lo...> - 2013-11-28 08:19:50
|
You are right - there is no need to make the GL entries creation contingent on the integration with debtors or creditors flags being enabled. Perhaps we could just remove those. However, some may just not want any GL and want to use the bank functionality without the GL. I assumed that if the creditors integration was off then no bank payments should create GL journals and likewise for debtors and bank receipts. This assumption may not be valid - happy if you think it is better to take this check out. It could be that transfers are created with a systype=12 rather than 2 and that could be causing the trouble as there is some interesting code to bring up the customer's name when the receipt is a customer receipt - and equivalent code to bring up the supplier when it is an AP payment. I am sure this will just be a display issue with that script. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/11/13 01:43, icedlava wrote: >> I think the fix needs to be in the GLJournalInquiry.php so it shows the journals created correctly. > OK i'll look. > > But why is it we need GL on to make a GL transaction for bank accounts through General Ledger - bank receipt/payment, but do not need GL on to make a GL transaction in the journal area? > If we go through the General Ledger menu then for consistency should not a transaction result in a GL entry in gltrans with or without GL switch on - this would be consistent instead of one doing so and one not doing so? > > Then, I could also fix the GLJournalInquiry if we can as you pointed out discriminate between GL payments and receipts and other bank transactions it should not be too difficult (i.e. 1 for GL payments, 2 for GL receipts). > > Thanks for your help! > > > > > > On 27 Nov 2013, at 17:25, Phil Daintree wrote: > >> I think the fix needs to be in the GLJournalInquiry.php so it shows the journals created correctly. >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890 >> http://www.logicworks.co.nz >> >> On 27/11/13 19:52, iced lava wrote: >>>> It is not necessary to modify the transaction type in the gltrans table. >>> To see the bank transactions in the general journal enquiries we do. >>> >>>> Can you point me to where the manual said the integration should be off when taking on GL balances? >>> I will take another look and let you know - i know i found it confusing when i first used webERP and went on a google hunt. It's been some time since i looked at that part of the manual and i've always turned on GL for bank transactions and off for everything else added through the General Ledger menu. >>> >>>> Which listings are you not able to see the balances ... script names ideally please >>> GLJournalInquiry.php - will not display bank transaction journals. >>> >>> And yes, trial balance shows balances correctly :) >>> >>> Thanks for taking a look. >>> >>> >>> On Wed, Nov 27, 2013 at 5:09 PM, Phil Daintree <ph...@lo... <mailto:ph...@lo...>> wrote: >>> >>> It is not necessary to modify the transaction type in the gltrans >>> table. >>> Can you point me to where the manual said the integration should >>> be off when taking on GL balances? I can see where it says this in >>> relation to setting up debtors and creditors balances i.e the open >>> items in the sub-ledgers. >>> Which listings are you not able to see the balances ... script >>> names ideally please. Maybe this is where the problem lies - >>> assuming the trial balance shows the balances correctly! >>> >>> >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> >>> http://www.logicworks.co.nz >>> >>> On 27/11/13 15:23, iced lava wrote: >>>> Provisos and issue remaining: >>>> >>>> 1. The opening balance transaction in the example with GL trans >>>> should occur with GL turned off (if instructions in manual are >>>> correct) >>>> >>>> 2. The behaviour cannot be applied generally to transactions >>>> through General Ledger unless the these transactions are >>>> displayed, such as bank fees, in the bank reconcilliation >>>> listings. They do not display when type is set to 0 (general >>>> journal) in the gltrans table and so fix should be determined for >>>> the reconcilliation functions. >>>> >>>> Comments appreciated. >>>> >>>> Thanks, >>>> >>>> >>>> >>>> On Wed, Nov 27, 2013 at 12:44 PM, iced lava <ice...@gm... >>>> <mailto:ice...@gm...>> wrote: >>>> >>>> As an example: >>>> I note that if I enter the bank balances at 30 June with GL >>>> on, I can change the Type of transaction in the gltrans table >>>> to 0 (general journal). Appropriate [next] incremented >>>> general journal numbers a can provided to these transactions >>>> by editing as well [and systype incremented accordingly and >>>> chart detail also adjusted]. >>>> >>>> If this is done then the year closing journals appear as >>>> required in the journal listings, on the trial balance and >>>> the bank listings and reports also seem correct (transactions >>>> are left untouched in banktrans table). >>>> >>>> >>>> This is as expected for the entry made through General Ledger >>>> bank receipts. >>>> >>>> >>>> Is this a bug? >>>> Should this behaviour also happen for other bank receipts and >>>> payments made through General Ledger option? I would think so. >>>> >>>> I can fix if required. >>>> >>>> Thanks. >>>> >>>> >>>> >>>> >>>> On Wed, Nov 27, 2013 at 12:04 PM, iced lava >>>> <ice...@gm... <mailto:ice...@gm...>> wrote: >>>> >>>> Could I have confirmation on what should happen when bank >>>> account balances are entered in for end of year closing >>>> balances eg at 30 June. >>>> >>>> Here is the current behaviour I see in latest webERP. >>>> Note that usually according to documentation year end >>>> balances should be done with GL integration off. >>>> >>>> 1. With GL integration turned off, the bank balances are >>>> taken on at 30 June by entering a receipt (General Ledger >>>> - Bank account receipt entry). >>>> >>>> * This transaction only appears as a single entry in >>>> the banktrans table - nowhere else >>>> * there is no corresponding balancing transaction - it >>>> would have to be made manually >>>> * as such the bank account balances do not appear in >>>> any 30 June trial balance >>>> * a listing of 30 June journal entries does not show >>>> any 30 June entries for any bank accounts GL accounts >>>> * trial balance as a consequence does not have any >>>> entries for these bank transactions >>>> >>>> >>>> 2. With the GL integration turned on - if the bank >>>> balances are taken on at 30 June by entering a receipt >>>> (General Ledger - Bank account receipt entry) >>>> >>>> * The transaction appears as an entry in the banktrans >>>> table >>>> * there is a corresponding transaction in the gltrans >>>> table and the balancing transaction(s) >>>> * the chartdetails table has entries for these transactions >>>> * trial balance shows an entry for these bank accounts >>>> * the listing of 30 June journal entries does not show >>>> anything for the bank accounts >>>> * the type in the gltrans table is type 12 - bank >>>> transaction, not 0 for general journal >>>> >>>> >>>> This is causing confusing with customer. >>>> >>>> The behaviour I thought would happen is that any bank >>>> transactions entered through the General Ledger - Bank >>>> account [receipt/payment] should in fact have entries in >>>> gltrans table and subsequent entries in the chart >>>> details. They then should appear in journal reports. >>>> >>>> This would be in contrast to payments/receipts made via >>>> the Payments and Receipts menus for debtors and creditors. >>>> >>>> However, for bank fees and such which must be entered >>>> through General Ledger payment (not a creditor), this >>>> poses a problem as the amounts will show in bank account >>>> transaction listings/reconcilliations - as they should. >>>> Howevrer they will never show as a general journal or >>>> reports as such (they are trans 12 not 0). >>>> >>>> Thanks in advance for any advice. >>>> >>>> Cheers, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>> organizations don't have a clear picture of how application performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> >>>> >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... <mailto:Web...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. >>> Most IT >>> organizations don't have a clear picture of how application >>> performance >>> affects their revenue. With AppDynamics, you get 100% visibility >>> into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>> AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> <mailto:Web...@li...> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> >>> >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: Phil D. <ph...@lo...> - 2013-11-28 08:10:18
|
Yes there is a real risk with this work... On the one hand I know the real solution is to deal with the SQL at the point of the SQL .... but on the other hand there is one heck of a lot of it and what we have works mostly. A good solution would be most welcome :-) Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/11/13 05:49, Tim Schofield wrote: > Hi Jo, I guess what I don't understand is what changing the code will > give us? At the moment we have a solution that works (albeit the > occasional change to remove the slashes, but most of these have been > done) and has passed the security audits we have had done. I am not > wedded to the current solution, it's more a case of "if it ain't broke > why fix it?". > > Tim > > On 27 November 2013 16:43, icedlava <ice...@gm...> wrote: >> Tim, >> using stripslahes with our current code covers up the problem, but doesn't fix the root issue. >> >> I'm happy to do the work to fix it if it will give us a clean solution. >> >> On 28 Nov 2013, at 3:11, Tim Schofield wrote: >> >>> Hi Jo, yes I did try it with purchase orders and see the problem. >>> Doesn't changing line 741 to >>> >>> <td><input type="text" name="ItemDescription' . $POLine->LineNo . '" >>> size="30" value="' . stripslashes($POLine->ItemDescription) . '" >>> /></td> >>> >>> fix the problem? >>> >>> Likewise in DeliveryDetails.php changing line 998 to >>> >>> >>> <td><input type="text" autofocus="autofocus" >>> required="required" size="42" maxlength="40" name="DeliverTo" value="' >>> . stripslashes($_SESSION['Items'.$identifier]->DeliverTo) . '" >>> title="' . _('Enter the name of the customer to deliver this order >>> to') . '" /></td> >>> >>> >>> I may be missing something. There are actually only a few scripts >>> where the POST data isn't immediately posted to the DB. >>> >>> thanks >>> Tim >>> >>> >>> >>> On 27 November 2013 16:31, icedlava <ice...@gm...> wrote: >>>> Hi Tim, >>>> >>>> Yes I agree there are some instances that we dealt with specifically but the problem remains and is more than just slashes replicating and is across the codebase in many fields. >>>> >>>> session.inc assumes all post, get and session vars are for the database and escape them via the db_escape function (and actually turns everything to entities as well for the db!). When the vars are not for the database at first instance, it causes problems. Try your test with Purchase order not sales order which we did fix in most parts. Here we also 'fill in a form' and the item is posted causing special char issues.They also come out on documentation that goes to customers. >>>> >>>> There are many other parts of the code base where special chars in general are not processed properly or also entities are not processed properly or doubly processed and saved in the database. >>>> >>>> *** we end up with entities in the database (which should not happen) causing display issues when output. *** >>>> >>>> *** we end up with special char issues like the multiplying slashes with each db save *** >>>> >>>> As you mentioned, the code in session.inc was written many years ago. It still uses magic quote calls (deprecated way back in php 5.3 2009) known not to be good solution for security although of course we try to support still all those on old php. >>>> >>>> It does not mean we cannot use best practice for handling data going into the database or out to display. >>>> >>>> It would be wonderful to have a system wide consistent solution to fix the entity issues in our database, that also will fix the escaping of data meant for display. It is better than just patching instances, and stripslashes() itself is not a full solution. I know it might be some work but happy to do it if we come up with agreed method - it would certainly fix a lot of customer complaint with display issues for me too :) >>>> >>>> I will think on some possible alternatives but i'm sure there are those out there with good solutions already. >>>> >>>> Thanks for all the useful comments! >>>> >>>> >>>> >>>> On 28 Nov 2013, at 0:57, Tim Schofield wrote: >>>> >>>>> Hi Jo, >>>>> >>>>> I meant I thought we had dealt with most instances. For instance >>>>> creating a sales order for smith's crisps does not generate this >>>>> error. I think the overwhelming majority of webERP scripts are of the >>>>> type: "Fill in a form, submit it and update the database". Fixing this >>>>> *seems* to be just a case of using stripslashes() on the item >>>>> description in the PO_Items.php script. >>>>> >>>>> This code in session.inc came about after a security review by Steve >>>>> Lord many years ago, and I would be very nervous about taking it out. >>>>> >>>>> Thanks >>>>> Tim >>>>> >>>>> On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: >>>>>> Hi Tim, >>>>>> >>>>>>> thought we had caught and dealt with these >>>>>> We caught an instance but I knew at the time it required a broader fix >>>>>> but was unable to identify best way ahead for it. >>>>>> >>>>>> I have raised the issue some time ago with Phil but not had time until >>>>>> now to look at the code and had a better look today. >>>>>> >>>>>>> Can you give some >>>>>>> examples of where it is still happening? >>>>>> Perhaps you can try replicate - it could be text with special char in >>>>>> any text field that is submitted in a form, a displayed value or input >>>>>> value that has some e.g. post var, get var or session var submitted to >>>>>> the database (some specific instances in the code have been addressed >>>>>> and fixed like you mentioned). >>>>>> >>>>>> I will try and provide an example: >>>>>> >>>>>> 1. Create an item with an item description such as "Smith's Chips" >>>>>> 2. Place a purchase order and select the item for your order. >>>>>> 3. At the PO_items.php function, with the line item for the order >>>>>> selected, click on Update Order lines and watch the description. You >>>>>> should get more slashes each time you click the Update Order lines >>>>>> button. >>>>>> >>>>>> I think, that we cannot assume in the sessions.inc file that we are >>>>>> going to add/update a post or get or session var to a database at first >>>>>> instance - it could be displayed only, it could be used in an input post >>>>>> field etc >>>>>> >>>>>> - when we save to the database call the relevant function e.g. >>>>>> mysqli_real_escape_string on non-html entity string (in weberp this is >>>>>> the DB_escape_string function but should be nonentity string e.g. use >>>>>> htmlspecialchars_decode not htmlspecialchars). >>>>>> >>>>>> - when we display in HTML use htmlspecialchar call to encode to entities >>>>>> where relevant. >>>>>> >>>>>> Anyway this is just some issue i came across a while ago and now >>>>>> revisiting in hope we can squash it for good - maybe someone has a >>>>>> solution already. >>>>>> >>>>>> Cheers! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 27 Nov 2013, at 18:57, Tim Schofield wrote: >>>>>> >>>>>>> Hi Jo, >>>>>>> >>>>>>> I thought we had caught and dealt with these. Can you give some >>>>>>> examples of where it is still happening? >>>>>>> >>>>>>> Thanks >>>>>>> Tim >>>>>>> >>>>>>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >>>>>>>> Currently we have sessions.inc processing all session, post and get >>>>>>>> vars in >>>>>>>> the same way. >>>>>>>> >>>>>>>> We make a big assumption here with DB_escape_string at line 59 and 66 >>>>>>>> (for >>>>>>>> single var and slightly different for arrays): >>>>>>>> >>>>>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >>>>>>>> >>>>>>>> This assumes that we know what a function will do with the >>>>>>>> post/get/sessions >>>>>>>> vars and that they are going to be inserted/updated to a database. >>>>>>>> They are >>>>>>>> passed to the DB_escape_string function which returns (for mysqli): >>>>>>>> >>>>>>>> mysqli_real_escape_string($db, htmlspecialchars($String, >>>>>>>> ENT_COMPAT,'utf-8', >>>>>>>> false)); >>>>>>>> >>>>>>>> This is causing exponential slash addition to variables which are not >>>>>>>> entered to a database but instead posted to a HTML field value. Each >>>>>>>> time >>>>>>>> the field is updated the value is saved in the database with extra >>>>>>>> slashes >>>>>>>> when escaping a special char like a single quote. >>>>>>>> >>>>>>>> If we do actually need to do this variable processing in sessions.inc >>>>>>>> then >>>>>>>> perhaps we could decide what is more common displaying the var or >>>>>>>> insert/updating to a db. >>>>>>>> >>>>>>>> If we chose for example that displaying the var on the page is more >>>>>>>> common >>>>>>>> then we should change sessions inc for example on this line: >>>>>>>> >>>>>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >>>>>>>> >>>>>>>> to >>>>>>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >>>>>>>> ENT_QUOTES,'UTF-8'); >>>>>>>> >>>>>>>> and for this case in DB_escape_string from: >>>>>>>> >>>>>>>> return mysqli_real_escape_string($db, htmlspecialchars($String, >>>>>>>> ENT_COMPAT,'utf-8', false)); >>>>>>>> to >>>>>>>> >>>>>>>> return mysqli_real_escape_string($db, >>>>>>>> htmlspecialchars_decode($String, >>>>>>>> ENT_COMPAT)); >>>>>>>> >>>>>>>> >>>>>>>> Then we need to call DB_escape_string on vars before we send to any >>>>>>>> insert >>>>>>>> or edit for database. >>>>>>>> >>>>>>>> On the other hand - we need to do the opposite if we assume it is >>>>>>>> more >>>>>>>> likely to post to the database. >>>>>>>> >>>>>>>> Perhaps there is another 3rd way to handle it? >>>>>>>> >>>>>>>> Thanks to all in advance for any feedback!! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>>>>> IT >>>>>>>> organizations don't have a clear picture of how application >>>>>>>> performance >>>>>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>>>>> your >>>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>>>>> AppDynamics >>>>>>>> Pro! >>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>>>> _______________________________________________ >>>>>>>> Web-erp-developers mailing list >>>>>>>> Web...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Course View Towers, >>>>>>> Plot 21 Yusuf Lule Road, >>>>>>> Kampala >>>>>>> T +256 (0) 312 314 418 >>>>>>> M +256 (0) 752 963 325 >>>>>>> www.weberpafrica.com >>>>>>> Twitter: @TimSchofield2 >>>>>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>>>> IT >>>>>>> organizations don't have a clear picture of how application >>>>>>> performance >>>>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>>>> your >>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>>>> AppDynamics Pro! >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Web-erp-developers mailing list >>>>>>> Web...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>> ------------------------------------------------------------------------------ >>>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>>> organizations don't have a clear picture of how application performance >>>>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>>> >>>>> -- >>>>> Course View Towers, >>>>> Plot 21 Yusuf Lule Road, >>>>> Kampala >>>>> T +256 (0) 312 314 418 >>>>> M +256 (0) 752 963 325 >>>>> www.weberpafrica.com >>>>> Twitter: @TimSchofield2 >>>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>> organizations don't have a clear picture of how application performance >>>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>> organizations don't have a clear picture of how application performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>> >>> >>> -- >>> Course View Towers, >>> Plot 21 Yusuf Lule Road, >>> Kampala >>> T +256 (0) 312 314 418 >>> M +256 (0) 752 963 325 >>> www.weberpafrica.com >>> Twitter: @TimSchofield2 >>> Blog: http://weberpafrica.blogspot.co.uk/ >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > |
From: Phil D. <ph...@lo...> - 2013-11-28 08:08:27
|
What is the issue with your svn access Tim? Let me know if I need to look at it. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/11/13 05:21, Tim Schofield wrote: > Ah yes, the deliver to name? > > Anyone know of any others? It seems I can't update svn but these > changes are very simple. > > Thanks > Tim > > On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: >> I can verify that this issue is still there. >> >> I have a customer's company name has the word Hug's. >> It will come up Hug/////s >> >> THis is customer customer name. So my invoices are all like this. >> Same with customer addresses. >> >> >> >> -- >> View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html >> Sent from the web-ERP-developers mailing list archive at Nabble.com. >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > |
From: Tim S. <tim...@gm...> - 2013-11-27 16:49:26
|
Hi Jo, I guess what I don't understand is what changing the code will give us? At the moment we have a solution that works (albeit the occasional change to remove the slashes, but most of these have been done) and has passed the security audits we have had done. I am not wedded to the current solution, it's more a case of "if it ain't broke why fix it?". Tim On 27 November 2013 16:43, icedlava <ice...@gm...> wrote: > Tim, > using stripslahes with our current code covers up the problem, but doesn't fix the root issue. > > I'm happy to do the work to fix it if it will give us a clean solution. > > On 28 Nov 2013, at 3:11, Tim Schofield wrote: > >> Hi Jo, yes I did try it with purchase orders and see the problem. >> Doesn't changing line 741 to >> >> <td><input type="text" name="ItemDescription' . $POLine->LineNo . '" >> size="30" value="' . stripslashes($POLine->ItemDescription) . '" >> /></td> >> >> fix the problem? >> >> Likewise in DeliveryDetails.php changing line 998 to >> >> >> <td><input type="text" autofocus="autofocus" >> required="required" size="42" maxlength="40" name="DeliverTo" value="' >> . stripslashes($_SESSION['Items'.$identifier]->DeliverTo) . '" >> title="' . _('Enter the name of the customer to deliver this order >> to') . '" /></td> >> >> >> I may be missing something. There are actually only a few scripts >> where the POST data isn't immediately posted to the DB. >> >> thanks >> Tim >> >> >> >> On 27 November 2013 16:31, icedlava <ice...@gm...> wrote: >>> Hi Tim, >>> >>> Yes I agree there are some instances that we dealt with specifically but the problem remains and is more than just slashes replicating and is across the codebase in many fields. >>> >>> session.inc assumes all post, get and session vars are for the database and escape them via the db_escape function (and actually turns everything to entities as well for the db!). When the vars are not for the database at first instance, it causes problems. Try your test with Purchase order not sales order which we did fix in most parts. Here we also 'fill in a form' and the item is posted causing special char issues.They also come out on documentation that goes to customers. >>> >>> There are many other parts of the code base where special chars in general are not processed properly or also entities are not processed properly or doubly processed and saved in the database. >>> >>> *** we end up with entities in the database (which should not happen) causing display issues when output. *** >>> >>> *** we end up with special char issues like the multiplying slashes with each db save *** >>> >>> As you mentioned, the code in session.inc was written many years ago. It still uses magic quote calls (deprecated way back in php 5.3 2009) known not to be good solution for security although of course we try to support still all those on old php. >>> >>> It does not mean we cannot use best practice for handling data going into the database or out to display. >>> >>> It would be wonderful to have a system wide consistent solution to fix the entity issues in our database, that also will fix the escaping of data meant for display. It is better than just patching instances, and stripslashes() itself is not a full solution. I know it might be some work but happy to do it if we come up with agreed method - it would certainly fix a lot of customer complaint with display issues for me too :) >>> >>> I will think on some possible alternatives but i'm sure there are those out there with good solutions already. >>> >>> Thanks for all the useful comments! >>> >>> >>> >>> On 28 Nov 2013, at 0:57, Tim Schofield wrote: >>> >>>> Hi Jo, >>>> >>>> I meant I thought we had dealt with most instances. For instance >>>> creating a sales order for smith's crisps does not generate this >>>> error. I think the overwhelming majority of webERP scripts are of the >>>> type: "Fill in a form, submit it and update the database". Fixing this >>>> *seems* to be just a case of using stripslashes() on the item >>>> description in the PO_Items.php script. >>>> >>>> This code in session.inc came about after a security review by Steve >>>> Lord many years ago, and I would be very nervous about taking it out. >>>> >>>> Thanks >>>> Tim >>>> >>>> On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: >>>>> Hi Tim, >>>>> >>>>>> thought we had caught and dealt with these >>>>> >>>>> We caught an instance but I knew at the time it required a broader fix >>>>> but was unable to identify best way ahead for it. >>>>> >>>>> I have raised the issue some time ago with Phil but not had time until >>>>> now to look at the code and had a better look today. >>>>> >>>>>> Can you give some >>>>>> examples of where it is still happening? >>>>> >>>>> Perhaps you can try replicate - it could be text with special char in >>>>> any text field that is submitted in a form, a displayed value or input >>>>> value that has some e.g. post var, get var or session var submitted to >>>>> the database (some specific instances in the code have been addressed >>>>> and fixed like you mentioned). >>>>> >>>>> I will try and provide an example: >>>>> >>>>> 1. Create an item with an item description such as "Smith's Chips" >>>>> 2. Place a purchase order and select the item for your order. >>>>> 3. At the PO_items.php function, with the line item for the order >>>>> selected, click on Update Order lines and watch the description. You >>>>> should get more slashes each time you click the Update Order lines >>>>> button. >>>>> >>>>> I think, that we cannot assume in the sessions.inc file that we are >>>>> going to add/update a post or get or session var to a database at first >>>>> instance - it could be displayed only, it could be used in an input post >>>>> field etc >>>>> >>>>> - when we save to the database call the relevant function e.g. >>>>> mysqli_real_escape_string on non-html entity string (in weberp this is >>>>> the DB_escape_string function but should be nonentity string e.g. use >>>>> htmlspecialchars_decode not htmlspecialchars). >>>>> >>>>> - when we display in HTML use htmlspecialchar call to encode to entities >>>>> where relevant. >>>>> >>>>> Anyway this is just some issue i came across a while ago and now >>>>> revisiting in hope we can squash it for good - maybe someone has a >>>>> solution already. >>>>> >>>>> Cheers! >>>>> >>>>> >>>>> >>>>> >>>>> On 27 Nov 2013, at 18:57, Tim Schofield wrote: >>>>> >>>>>> Hi Jo, >>>>>> >>>>>> I thought we had caught and dealt with these. Can you give some >>>>>> examples of where it is still happening? >>>>>> >>>>>> Thanks >>>>>> Tim >>>>>> >>>>>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >>>>>>> Currently we have sessions.inc processing all session, post and get >>>>>>> vars in >>>>>>> the same way. >>>>>>> >>>>>>> We make a big assumption here with DB_escape_string at line 59 and 66 >>>>>>> (for >>>>>>> single var and slightly different for arrays): >>>>>>> >>>>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >>>>>>> >>>>>>> This assumes that we know what a function will do with the >>>>>>> post/get/sessions >>>>>>> vars and that they are going to be inserted/updated to a database. >>>>>>> They are >>>>>>> passed to the DB_escape_string function which returns (for mysqli): >>>>>>> >>>>>>> mysqli_real_escape_string($db, htmlspecialchars($String, >>>>>>> ENT_COMPAT,'utf-8', >>>>>>> false)); >>>>>>> >>>>>>> This is causing exponential slash addition to variables which are not >>>>>>> entered to a database but instead posted to a HTML field value. Each >>>>>>> time >>>>>>> the field is updated the value is saved in the database with extra >>>>>>> slashes >>>>>>> when escaping a special char like a single quote. >>>>>>> >>>>>>> If we do actually need to do this variable processing in sessions.inc >>>>>>> then >>>>>>> perhaps we could decide what is more common displaying the var or >>>>>>> insert/updating to a db. >>>>>>> >>>>>>> If we chose for example that displaying the var on the page is more >>>>>>> common >>>>>>> then we should change sessions inc for example on this line: >>>>>>> >>>>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >>>>>>> >>>>>>> to >>>>>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >>>>>>> ENT_QUOTES,'UTF-8'); >>>>>>> >>>>>>> and for this case in DB_escape_string from: >>>>>>> >>>>>>> return mysqli_real_escape_string($db, htmlspecialchars($String, >>>>>>> ENT_COMPAT,'utf-8', false)); >>>>>>> to >>>>>>> >>>>>>> return mysqli_real_escape_string($db, >>>>>>> htmlspecialchars_decode($String, >>>>>>> ENT_COMPAT)); >>>>>>> >>>>>>> >>>>>>> Then we need to call DB_escape_string on vars before we send to any >>>>>>> insert >>>>>>> or edit for database. >>>>>>> >>>>>>> On the other hand - we need to do the opposite if we assume it is >>>>>>> more >>>>>>> likely to post to the database. >>>>>>> >>>>>>> Perhaps there is another 3rd way to handle it? >>>>>>> >>>>>>> Thanks to all in advance for any feedback!! >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>>>> IT >>>>>>> organizations don't have a clear picture of how application >>>>>>> performance >>>>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>>>> your >>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>>>> AppDynamics >>>>>>> Pro! >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Web-erp-developers mailing list >>>>>>> Web...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Course View Towers, >>>>>> Plot 21 Yusuf Lule Road, >>>>>> Kampala >>>>>> T +256 (0) 312 314 418 >>>>>> M +256 (0) 752 963 325 >>>>>> www.weberpafrica.com >>>>>> Twitter: @TimSchofield2 >>>>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>>> IT >>>>>> organizations don't have a clear picture of how application >>>>>> performance >>>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>>> your >>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>>> AppDynamics Pro! >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>> organizations don't have a clear picture of how application performance >>>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>>> >>>> >>>> -- >>>> Course View Towers, >>>> Plot 21 Yusuf Lule Road, >>>> Kampala >>>> T +256 (0) 312 314 418 >>>> M +256 (0) 752 963 325 >>>> www.weberpafrica.com >>>> Twitter: @TimSchofield2 >>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>> organizations don't have a clear picture of how application performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >> >> >> >> -- >> Course View Towers, >> Plot 21 Yusuf Lule Road, >> Kampala >> T +256 (0) 312 314 418 >> M +256 (0) 752 963 325 >> www.weberpafrica.com >> Twitter: @TimSchofield2 >> Blog: http://weberpafrica.blogspot.co.uk/ >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > -- Course View Towers, Plot 21 Yusuf Lule Road, Kampala T +256 (0) 312 314 418 M +256 (0) 752 963 325 www.weberpafrica.com Twitter: @TimSchofield2 Blog: http://weberpafrica.blogspot.co.uk/ |
From: icedlava <ice...@gm...> - 2013-11-27 16:43:51
|
Tim, using stripslahes with our current code covers up the problem, but doesn't fix the root issue. I'm happy to do the work to fix it if it will give us a clean solution. On 28 Nov 2013, at 3:11, Tim Schofield wrote: > Hi Jo, yes I did try it with purchase orders and see the problem. > Doesn't changing line 741 to > > <td><input type="text" name="ItemDescription' . $POLine->LineNo . '" > size="30" value="' . stripslashes($POLine->ItemDescription) . '" > /></td> > > fix the problem? > > Likewise in DeliveryDetails.php changing line 998 to > > > <td><input type="text" autofocus="autofocus" > required="required" size="42" maxlength="40" name="DeliverTo" value="' > . stripslashes($_SESSION['Items'.$identifier]->DeliverTo) . '" > title="' . _('Enter the name of the customer to deliver this order > to') . '" /></td> > > > I may be missing something. There are actually only a few scripts > where the POST data isn't immediately posted to the DB. > > thanks > Tim > > > > On 27 November 2013 16:31, icedlava <ice...@gm...> wrote: >> Hi Tim, >> >> Yes I agree there are some instances that we dealt with specifically but the problem remains and is more than just slashes replicating and is across the codebase in many fields. >> >> session.inc assumes all post, get and session vars are for the database and escape them via the db_escape function (and actually turns everything to entities as well for the db!). When the vars are not for the database at first instance, it causes problems. Try your test with Purchase order not sales order which we did fix in most parts. Here we also 'fill in a form' and the item is posted causing special char issues.They also come out on documentation that goes to customers. >> >> There are many other parts of the code base where special chars in general are not processed properly or also entities are not processed properly or doubly processed and saved in the database. >> >> *** we end up with entities in the database (which should not happen) causing display issues when output. *** >> >> *** we end up with special char issues like the multiplying slashes with each db save *** >> >> As you mentioned, the code in session.inc was written many years ago. It still uses magic quote calls (deprecated way back in php 5.3 2009) known not to be good solution for security although of course we try to support still all those on old php. >> >> It does not mean we cannot use best practice for handling data going into the database or out to display. >> >> It would be wonderful to have a system wide consistent solution to fix the entity issues in our database, that also will fix the escaping of data meant for display. It is better than just patching instances, and stripslashes() itself is not a full solution. I know it might be some work but happy to do it if we come up with agreed method - it would certainly fix a lot of customer complaint with display issues for me too :) >> >> I will think on some possible alternatives but i'm sure there are those out there with good solutions already. >> >> Thanks for all the useful comments! >> >> >> >> On 28 Nov 2013, at 0:57, Tim Schofield wrote: >> >>> Hi Jo, >>> >>> I meant I thought we had dealt with most instances. For instance >>> creating a sales order for smith's crisps does not generate this >>> error. I think the overwhelming majority of webERP scripts are of the >>> type: "Fill in a form, submit it and update the database". Fixing this >>> *seems* to be just a case of using stripslashes() on the item >>> description in the PO_Items.php script. >>> >>> This code in session.inc came about after a security review by Steve >>> Lord many years ago, and I would be very nervous about taking it out. >>> >>> Thanks >>> Tim >>> >>> On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: >>>> Hi Tim, >>>> >>>>> thought we had caught and dealt with these >>>> >>>> We caught an instance but I knew at the time it required a broader fix >>>> but was unable to identify best way ahead for it. >>>> >>>> I have raised the issue some time ago with Phil but not had time until >>>> now to look at the code and had a better look today. >>>> >>>>> Can you give some >>>>> examples of where it is still happening? >>>> >>>> Perhaps you can try replicate - it could be text with special char in >>>> any text field that is submitted in a form, a displayed value or input >>>> value that has some e.g. post var, get var or session var submitted to >>>> the database (some specific instances in the code have been addressed >>>> and fixed like you mentioned). >>>> >>>> I will try and provide an example: >>>> >>>> 1. Create an item with an item description such as "Smith's Chips" >>>> 2. Place a purchase order and select the item for your order. >>>> 3. At the PO_items.php function, with the line item for the order >>>> selected, click on Update Order lines and watch the description. You >>>> should get more slashes each time you click the Update Order lines >>>> button. >>>> >>>> I think, that we cannot assume in the sessions.inc file that we are >>>> going to add/update a post or get or session var to a database at first >>>> instance - it could be displayed only, it could be used in an input post >>>> field etc >>>> >>>> - when we save to the database call the relevant function e.g. >>>> mysqli_real_escape_string on non-html entity string (in weberp this is >>>> the DB_escape_string function but should be nonentity string e.g. use >>>> htmlspecialchars_decode not htmlspecialchars). >>>> >>>> - when we display in HTML use htmlspecialchar call to encode to entities >>>> where relevant. >>>> >>>> Anyway this is just some issue i came across a while ago and now >>>> revisiting in hope we can squash it for good - maybe someone has a >>>> solution already. >>>> >>>> Cheers! >>>> >>>> >>>> >>>> >>>> On 27 Nov 2013, at 18:57, Tim Schofield wrote: >>>> >>>>> Hi Jo, >>>>> >>>>> I thought we had caught and dealt with these. Can you give some >>>>> examples of where it is still happening? >>>>> >>>>> Thanks >>>>> Tim >>>>> >>>>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >>>>>> Currently we have sessions.inc processing all session, post and get >>>>>> vars in >>>>>> the same way. >>>>>> >>>>>> We make a big assumption here with DB_escape_string at line 59 and 66 >>>>>> (for >>>>>> single var and slightly different for arrays): >>>>>> >>>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >>>>>> >>>>>> This assumes that we know what a function will do with the >>>>>> post/get/sessions >>>>>> vars and that they are going to be inserted/updated to a database. >>>>>> They are >>>>>> passed to the DB_escape_string function which returns (for mysqli): >>>>>> >>>>>> mysqli_real_escape_string($db, htmlspecialchars($String, >>>>>> ENT_COMPAT,'utf-8', >>>>>> false)); >>>>>> >>>>>> This is causing exponential slash addition to variables which are not >>>>>> entered to a database but instead posted to a HTML field value. Each >>>>>> time >>>>>> the field is updated the value is saved in the database with extra >>>>>> slashes >>>>>> when escaping a special char like a single quote. >>>>>> >>>>>> If we do actually need to do this variable processing in sessions.inc >>>>>> then >>>>>> perhaps we could decide what is more common displaying the var or >>>>>> insert/updating to a db. >>>>>> >>>>>> If we chose for example that displaying the var on the page is more >>>>>> common >>>>>> then we should change sessions inc for example on this line: >>>>>> >>>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >>>>>> >>>>>> to >>>>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >>>>>> ENT_QUOTES,'UTF-8'); >>>>>> >>>>>> and for this case in DB_escape_string from: >>>>>> >>>>>> return mysqli_real_escape_string($db, htmlspecialchars($String, >>>>>> ENT_COMPAT,'utf-8', false)); >>>>>> to >>>>>> >>>>>> return mysqli_real_escape_string($db, >>>>>> htmlspecialchars_decode($String, >>>>>> ENT_COMPAT)); >>>>>> >>>>>> >>>>>> Then we need to call DB_escape_string on vars before we send to any >>>>>> insert >>>>>> or edit for database. >>>>>> >>>>>> On the other hand - we need to do the opposite if we assume it is >>>>>> more >>>>>> likely to post to the database. >>>>>> >>>>>> Perhaps there is another 3rd way to handle it? >>>>>> >>>>>> Thanks to all in advance for any feedback!! >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>>> IT >>>>>> organizations don't have a clear picture of how application >>>>>> performance >>>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>>> your >>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>>> AppDynamics >>>>>> Pro! >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Course View Towers, >>>>> Plot 21 Yusuf Lule Road, >>>>> Kampala >>>>> T +256 (0) 312 314 418 >>>>> M +256 (0) 752 963 325 >>>>> www.weberpafrica.com >>>>> Twitter: @TimSchofield2 >>>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>> IT >>>>> organizations don't have a clear picture of how application >>>>> performance >>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>> your >>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>> AppDynamics Pro! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>> organizations don't have a clear picture of how application performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >>> >>> -- >>> Course View Towers, >>> Plot 21 Yusuf Lule Road, >>> Kampala >>> T +256 (0) 312 314 418 >>> M +256 (0) 752 963 325 >>> www.weberpafrica.com >>> Twitter: @TimSchofield2 >>> Blog: http://weberpafrica.blogspot.co.uk/ >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > > > -- > Course View Towers, > Plot 21 Yusuf Lule Road, > Kampala > T +256 (0) 312 314 418 > M +256 (0) 752 963 325 > www.weberpafrica.com > Twitter: @TimSchofield2 > Blog: http://weberpafrica.blogspot.co.uk/ > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: Tim S. <tim...@gm...> - 2013-11-27 16:41:32
|
Hi Jo, yes I did try it with purchase orders and see the problem. Doesn't changing line 741 to <td><input type="text" name="ItemDescription' . $POLine->LineNo . '" size="30" value="' . stripslashes($POLine->ItemDescription) . '" /></td> fix the problem? Likewise in DeliveryDetails.php changing line 998 to <td><input type="text" autofocus="autofocus" required="required" size="42" maxlength="40" name="DeliverTo" value="' . stripslashes($_SESSION['Items'.$identifier]->DeliverTo) . '" title="' . _('Enter the name of the customer to deliver this order to') . '" /></td> I may be missing something. There are actually only a few scripts where the POST data isn't immediately posted to the DB. thanks Tim On 27 November 2013 16:31, icedlava <ice...@gm...> wrote: > Hi Tim, > > Yes I agree there are some instances that we dealt with specifically but the problem remains and is more than just slashes replicating and is across the codebase in many fields. > > session.inc assumes all post, get and session vars are for the database and escape them via the db_escape function (and actually turns everything to entities as well for the db!). When the vars are not for the database at first instance, it causes problems. Try your test with Purchase order not sales order which we did fix in most parts. Here we also 'fill in a form' and the item is posted causing special char issues.They also come out on documentation that goes to customers. > > There are many other parts of the code base where special chars in general are not processed properly or also entities are not processed properly or doubly processed and saved in the database. > > *** we end up with entities in the database (which should not happen) causing display issues when output. *** > > *** we end up with special char issues like the multiplying slashes with each db save *** > > As you mentioned, the code in session.inc was written many years ago. It still uses magic quote calls (deprecated way back in php 5.3 2009) known not to be good solution for security although of course we try to support still all those on old php. > > It does not mean we cannot use best practice for handling data going into the database or out to display. > > It would be wonderful to have a system wide consistent solution to fix the entity issues in our database, that also will fix the escaping of data meant for display. It is better than just patching instances, and stripslashes() itself is not a full solution. I know it might be some work but happy to do it if we come up with agreed method - it would certainly fix a lot of customer complaint with display issues for me too :) > > I will think on some possible alternatives but i'm sure there are those out there with good solutions already. > > Thanks for all the useful comments! > > > > On 28 Nov 2013, at 0:57, Tim Schofield wrote: > >> Hi Jo, >> >> I meant I thought we had dealt with most instances. For instance >> creating a sales order for smith's crisps does not generate this >> error. I think the overwhelming majority of webERP scripts are of the >> type: "Fill in a form, submit it and update the database". Fixing this >> *seems* to be just a case of using stripslashes() on the item >> description in the PO_Items.php script. >> >> This code in session.inc came about after a security review by Steve >> Lord many years ago, and I would be very nervous about taking it out. >> >> Thanks >> Tim >> >> On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: >>> Hi Tim, >>> >>>> thought we had caught and dealt with these >>> >>> We caught an instance but I knew at the time it required a broader fix >>> but was unable to identify best way ahead for it. >>> >>> I have raised the issue some time ago with Phil but not had time until >>> now to look at the code and had a better look today. >>> >>>> Can you give some >>>> examples of where it is still happening? >>> >>> Perhaps you can try replicate - it could be text with special char in >>> any text field that is submitted in a form, a displayed value or input >>> value that has some e.g. post var, get var or session var submitted to >>> the database (some specific instances in the code have been addressed >>> and fixed like you mentioned). >>> >>> I will try and provide an example: >>> >>> 1. Create an item with an item description such as "Smith's Chips" >>> 2. Place a purchase order and select the item for your order. >>> 3. At the PO_items.php function, with the line item for the order >>> selected, click on Update Order lines and watch the description. You >>> should get more slashes each time you click the Update Order lines >>> button. >>> >>> I think, that we cannot assume in the sessions.inc file that we are >>> going to add/update a post or get or session var to a database at first >>> instance - it could be displayed only, it could be used in an input post >>> field etc >>> >>> - when we save to the database call the relevant function e.g. >>> mysqli_real_escape_string on non-html entity string (in weberp this is >>> the DB_escape_string function but should be nonentity string e.g. use >>> htmlspecialchars_decode not htmlspecialchars). >>> >>> - when we display in HTML use htmlspecialchar call to encode to entities >>> where relevant. >>> >>> Anyway this is just some issue i came across a while ago and now >>> revisiting in hope we can squash it for good - maybe someone has a >>> solution already. >>> >>> Cheers! >>> >>> >>> >>> >>> On 27 Nov 2013, at 18:57, Tim Schofield wrote: >>> >>>> Hi Jo, >>>> >>>> I thought we had caught and dealt with these. Can you give some >>>> examples of where it is still happening? >>>> >>>> Thanks >>>> Tim >>>> >>>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >>>>> Currently we have sessions.inc processing all session, post and get >>>>> vars in >>>>> the same way. >>>>> >>>>> We make a big assumption here with DB_escape_string at line 59 and 66 >>>>> (for >>>>> single var and slightly different for arrays): >>>>> >>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >>>>> >>>>> This assumes that we know what a function will do with the >>>>> post/get/sessions >>>>> vars and that they are going to be inserted/updated to a database. >>>>> They are >>>>> passed to the DB_escape_string function which returns (for mysqli): >>>>> >>>>> mysqli_real_escape_string($db, htmlspecialchars($String, >>>>> ENT_COMPAT,'utf-8', >>>>> false)); >>>>> >>>>> This is causing exponential slash addition to variables which are not >>>>> entered to a database but instead posted to a HTML field value. Each >>>>> time >>>>> the field is updated the value is saved in the database with extra >>>>> slashes >>>>> when escaping a special char like a single quote. >>>>> >>>>> If we do actually need to do this variable processing in sessions.inc >>>>> then >>>>> perhaps we could decide what is more common displaying the var or >>>>> insert/updating to a db. >>>>> >>>>> If we chose for example that displaying the var on the page is more >>>>> common >>>>> then we should change sessions inc for example on this line: >>>>> >>>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >>>>> >>>>> to >>>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >>>>> ENT_QUOTES,'UTF-8'); >>>>> >>>>> and for this case in DB_escape_string from: >>>>> >>>>> return mysqli_real_escape_string($db, htmlspecialchars($String, >>>>> ENT_COMPAT,'utf-8', false)); >>>>> to >>>>> >>>>> return mysqli_real_escape_string($db, >>>>> htmlspecialchars_decode($String, >>>>> ENT_COMPAT)); >>>>> >>>>> >>>>> Then we need to call DB_escape_string on vars before we send to any >>>>> insert >>>>> or edit for database. >>>>> >>>>> On the other hand - we need to do the opposite if we assume it is >>>>> more >>>>> likely to post to the database. >>>>> >>>>> Perhaps there is another 3rd way to handle it? >>>>> >>>>> Thanks to all in advance for any feedback!! >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Rapidly troubleshoot problems before they affect your business. Most >>>>> IT >>>>> organizations don't have a clear picture of how application >>>>> performance >>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>> your >>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>> AppDynamics >>>>> Pro! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>> >>>> >>>> >>>> -- >>>> Course View Towers, >>>> Plot 21 Yusuf Lule Road, >>>> Kampala >>>> T +256 (0) 312 314 418 >>>> M +256 (0) 752 963 325 >>>> www.weberpafrica.com >>>> Twitter: @TimSchofield2 >>>> Blog: http://weberpafrica.blogspot.co.uk/ >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most >>>> IT >>>> organizations don't have a clear picture of how application >>>> performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>> your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>> AppDynamics Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> -- >> Course View Towers, >> Plot 21 Yusuf Lule Road, >> Kampala >> T +256 (0) 312 314 418 >> M +256 (0) 752 963 325 >> www.weberpafrica.com >> Twitter: @TimSchofield2 >> Blog: http://weberpafrica.blogspot.co.uk/ >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > -- Course View Towers, Plot 21 Yusuf Lule Road, Kampala T +256 (0) 312 314 418 M +256 (0) 752 963 325 www.weberpafrica.com Twitter: @TimSchofield2 Blog: http://weberpafrica.blogspot.co.uk/ |
From: icedlava <ice...@gm...> - 2013-11-27 16:40:36
|
It is in essence very simple to do but requires some work to get a clean consistent solution through the code base. And we should not use addslahes() and stripslahes(). Search on google there are lots of references: eg http://stackoverflow.com/questions/568995/best-way-to-defend-against-mysql-injection-and-cross-site-scripting http://stackoverflow.com/questions/129677/whats-the-best-method-for-sanitizing-user-input-with-php http://stackoverflow.com/questions/6399833/is-there-a-reason-why-i-need-to-use-stripslashes-for-user-submitted-data On 28 Nov 2013, at 0:57, Tim Schofield wrote: > Hi Jo, > > I meant I thought we had dealt with most instances. For instance > creating a sales order for smith's crisps does not generate this > error. I think the overwhelming majority of webERP scripts are of the > type: "Fill in a form, submit it and update the database". Fixing this > *seems* to be just a case of using stripslashes() on the item > description in the PO_Items.php script. > > This code in session.inc came about after a security review by Steve > Lord many years ago, and I would be very nervous about taking it out. > > Thanks > Tim > > On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: >> Hi Tim, >> >>> thought we had caught and dealt with these >> >> We caught an instance but I knew at the time it required a broader fix >> but was unable to identify best way ahead for it. >> >> I have raised the issue some time ago with Phil but not had time until >> now to look at the code and had a better look today. >> >>> Can you give some >>> examples of where it is still happening? >> >> Perhaps you can try replicate - it could be text with special char in >> any text field that is submitted in a form, a displayed value or input >> value that has some e.g. post var, get var or session var submitted to >> the database (some specific instances in the code have been addressed >> and fixed like you mentioned). >> >> I will try and provide an example: >> >> 1. Create an item with an item description such as "Smith's Chips" >> 2. Place a purchase order and select the item for your order. >> 3. At the PO_items.php function, with the line item for the order >> selected, click on Update Order lines and watch the description. You >> should get more slashes each time you click the Update Order lines >> button. >> >> I think, that we cannot assume in the sessions.inc file that we are >> going to add/update a post or get or session var to a database at first >> instance - it could be displayed only, it could be used in an input post >> field etc >> >> - when we save to the database call the relevant function e.g. >> mysqli_real_escape_string on non-html entity string (in weberp this is >> the DB_escape_string function but should be nonentity string e.g. use >> htmlspecialchars_decode not htmlspecialchars). >> >> - when we display in HTML use htmlspecialchar call to encode to entities >> where relevant. >> >> Anyway this is just some issue i came across a while ago and now >> revisiting in hope we can squash it for good - maybe someone has a >> solution already. >> >> Cheers! >> >> >> >> >> On 27 Nov 2013, at 18:57, Tim Schofield wrote: >> >>> Hi Jo, >>> >>> I thought we had caught and dealt with these. Can you give some >>> examples of where it is still happening? >>> >>> Thanks >>> Tim >>> >>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >>>> Currently we have sessions.inc processing all session, post and get >>>> vars in >>>> the same way. >>>> >>>> We make a big assumption here with DB_escape_string at line 59 and 66 >>>> (for >>>> single var and slightly different for arrays): >>>> >>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >>>> >>>> This assumes that we know what a function will do with the >>>> post/get/sessions >>>> vars and that they are going to be inserted/updated to a database. >>>> They are >>>> passed to the DB_escape_string function which returns (for mysqli): >>>> >>>> mysqli_real_escape_string($db, htmlspecialchars($String, >>>> ENT_COMPAT,'utf-8', >>>> false)); >>>> >>>> This is causing exponential slash addition to variables which are not >>>> entered to a database but instead posted to a HTML field value. Each >>>> time >>>> the field is updated the value is saved in the database with extra >>>> slashes >>>> when escaping a special char like a single quote. >>>> >>>> If we do actually need to do this variable processing in sessions.inc >>>> then >>>> perhaps we could decide what is more common displaying the var or >>>> insert/updating to a db. >>>> >>>> If we chose for example that displaying the var on the page is more >>>> common >>>> then we should change sessions inc for example on this line: >>>> >>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >>>> >>>> to >>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >>>> ENT_QUOTES,'UTF-8'); >>>> >>>> and for this case in DB_escape_string from: >>>> >>>> return mysqli_real_escape_string($db, htmlspecialchars($String, >>>> ENT_COMPAT,'utf-8', false)); >>>> to >>>> >>>> return mysqli_real_escape_string($db, >>>> htmlspecialchars_decode($String, >>>> ENT_COMPAT)); >>>> >>>> >>>> Then we need to call DB_escape_string on vars before we send to any >>>> insert >>>> or edit for database. >>>> >>>> On the other hand - we need to do the opposite if we assume it is >>>> more >>>> likely to post to the database. >>>> >>>> Perhaps there is another 3rd way to handle it? >>>> >>>> Thanks to all in advance for any feedback!! >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most >>>> IT >>>> organizations don't have a clear picture of how application >>>> performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>> your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>> AppDynamics >>>> Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>> >>> >>> >>> -- >>> Course View Towers, >>> Plot 21 Yusuf Lule Road, >>> Kampala >>> T +256 (0) 312 314 418 >>> M +256 (0) 752 963 325 >>> www.weberpafrica.com >>> Twitter: @TimSchofield2 >>> Blog: http://weberpafrica.blogspot.co.uk/ >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most >>> IT >>> organizations don't have a clear picture of how application >>> performance >>> affects their revenue. With AppDynamics, you get 100% visibility into >>> your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>> AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > -- > Course View Towers, > Plot 21 Yusuf Lule Road, > Kampala > T +256 (0) 312 314 418 > M +256 (0) 752 963 325 > www.weberpafrica.com > Twitter: @TimSchofield2 > Blog: http://weberpafrica.blogspot.co.uk/ > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: icedlava <ice...@gm...> - 2013-11-27 16:34:04
|
There are many - also with entities saving in db and display issues caused by very same session.inc var processing. Those with special chars or entities in data will see it most in item names, customer or supplier names, text fields or anywhere there is data with entities or special chars. On 28 Nov 2013, at 2:51, Tim Schofield wrote: > Ah yes, the deliver to name? > > Anyone know of any others? It seems I can't update svn but these > changes are very simple. > > Thanks > Tim > > On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: >> I can verify that this issue is still there. >> >> I have a customer's company name has the word Hug's. >> It will come up Hug/////s >> >> THis is customer customer name. So my invoices are all like this. >> Same with customer addresses. >> >> >> >> -- >> View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html >> Sent from the web-ERP-developers mailing list archive at Nabble.com. >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > -- > Course View Towers, > Plot 21 Yusuf Lule Road, > Kampala > T +256 (0) 312 314 418 > M +256 (0) 752 963 325 > www.weberpafrica.com > Twitter: @TimSchofield2 > Blog: http://weberpafrica.blogspot.co.uk/ > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: icedlava <ice...@gm...> - 2013-11-27 16:31:17
|
Hi Tim, Yes I agree there are some instances that we dealt with specifically but the problem remains and is more than just slashes replicating and is across the codebase in many fields. session.inc assumes all post, get and session vars are for the database and escape them via the db_escape function (and actually turns everything to entities as well for the db!). When the vars are not for the database at first instance, it causes problems. Try your test with Purchase order not sales order which we did fix in most parts. Here we also 'fill in a form' and the item is posted causing special char issues.They also come out on documentation that goes to customers. There are many other parts of the code base where special chars in general are not processed properly or also entities are not processed properly or doubly processed and saved in the database. *** we end up with entities in the database (which should not happen) causing display issues when output. *** *** we end up with special char issues like the multiplying slashes with each db save *** As you mentioned, the code in session.inc was written many years ago. It still uses magic quote calls (deprecated way back in php 5.3 2009) known not to be good solution for security although of course we try to support still all those on old php. It does not mean we cannot use best practice for handling data going into the database or out to display. It would be wonderful to have a system wide consistent solution to fix the entity issues in our database, that also will fix the escaping of data meant for display. It is better than just patching instances, and stripslashes() itself is not a full solution. I know it might be some work but happy to do it if we come up with agreed method - it would certainly fix a lot of customer complaint with display issues for me too :) I will think on some possible alternatives but i'm sure there are those out there with good solutions already. Thanks for all the useful comments! On 28 Nov 2013, at 0:57, Tim Schofield wrote: > Hi Jo, > > I meant I thought we had dealt with most instances. For instance > creating a sales order for smith's crisps does not generate this > error. I think the overwhelming majority of webERP scripts are of the > type: "Fill in a form, submit it and update the database". Fixing this > *seems* to be just a case of using stripslashes() on the item > description in the PO_Items.php script. > > This code in session.inc came about after a security review by Steve > Lord many years ago, and I would be very nervous about taking it out. > > Thanks > Tim > > On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: >> Hi Tim, >> >>> thought we had caught and dealt with these >> >> We caught an instance but I knew at the time it required a broader fix >> but was unable to identify best way ahead for it. >> >> I have raised the issue some time ago with Phil but not had time until >> now to look at the code and had a better look today. >> >>> Can you give some >>> examples of where it is still happening? >> >> Perhaps you can try replicate - it could be text with special char in >> any text field that is submitted in a form, a displayed value or input >> value that has some e.g. post var, get var or session var submitted to >> the database (some specific instances in the code have been addressed >> and fixed like you mentioned). >> >> I will try and provide an example: >> >> 1. Create an item with an item description such as "Smith's Chips" >> 2. Place a purchase order and select the item for your order. >> 3. At the PO_items.php function, with the line item for the order >> selected, click on Update Order lines and watch the description. You >> should get more slashes each time you click the Update Order lines >> button. >> >> I think, that we cannot assume in the sessions.inc file that we are >> going to add/update a post or get or session var to a database at first >> instance - it could be displayed only, it could be used in an input post >> field etc >> >> - when we save to the database call the relevant function e.g. >> mysqli_real_escape_string on non-html entity string (in weberp this is >> the DB_escape_string function but should be nonentity string e.g. use >> htmlspecialchars_decode not htmlspecialchars). >> >> - when we display in HTML use htmlspecialchar call to encode to entities >> where relevant. >> >> Anyway this is just some issue i came across a while ago and now >> revisiting in hope we can squash it for good - maybe someone has a >> solution already. >> >> Cheers! >> >> >> >> >> On 27 Nov 2013, at 18:57, Tim Schofield wrote: >> >>> Hi Jo, >>> >>> I thought we had caught and dealt with these. Can you give some >>> examples of where it is still happening? >>> >>> Thanks >>> Tim >>> >>> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >>>> Currently we have sessions.inc processing all session, post and get >>>> vars in >>>> the same way. >>>> >>>> We make a big assumption here with DB_escape_string at line 59 and 66 >>>> (for >>>> single var and slightly different for arrays): >>>> >>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >>>> >>>> This assumes that we know what a function will do with the >>>> post/get/sessions >>>> vars and that they are going to be inserted/updated to a database. >>>> They are >>>> passed to the DB_escape_string function which returns (for mysqli): >>>> >>>> mysqli_real_escape_string($db, htmlspecialchars($String, >>>> ENT_COMPAT,'utf-8', >>>> false)); >>>> >>>> This is causing exponential slash addition to variables which are not >>>> entered to a database but instead posted to a HTML field value. Each >>>> time >>>> the field is updated the value is saved in the database with extra >>>> slashes >>>> when escaping a special char like a single quote. >>>> >>>> If we do actually need to do this variable processing in sessions.inc >>>> then >>>> perhaps we could decide what is more common displaying the var or >>>> insert/updating to a db. >>>> >>>> If we chose for example that displaying the var on the page is more >>>> common >>>> then we should change sessions inc for example on this line: >>>> >>>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >>>> >>>> to >>>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >>>> ENT_QUOTES,'UTF-8'); >>>> >>>> and for this case in DB_escape_string from: >>>> >>>> return mysqli_real_escape_string($db, htmlspecialchars($String, >>>> ENT_COMPAT,'utf-8', false)); >>>> to >>>> >>>> return mysqli_real_escape_string($db, >>>> htmlspecialchars_decode($String, >>>> ENT_COMPAT)); >>>> >>>> >>>> Then we need to call DB_escape_string on vars before we send to any >>>> insert >>>> or edit for database. >>>> >>>> On the other hand - we need to do the opposite if we assume it is >>>> more >>>> likely to post to the database. >>>> >>>> Perhaps there is another 3rd way to handle it? >>>> >>>> Thanks to all in advance for any feedback!! >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most >>>> IT >>>> organizations don't have a clear picture of how application >>>> performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>> your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>> AppDynamics >>>> Pro! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>> >>> >>> >>> -- >>> Course View Towers, >>> Plot 21 Yusuf Lule Road, >>> Kampala >>> T +256 (0) 312 314 418 >>> M +256 (0) 752 963 325 >>> www.weberpafrica.com >>> Twitter: @TimSchofield2 >>> Blog: http://weberpafrica.blogspot.co.uk/ >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most >>> IT >>> organizations don't have a clear picture of how application >>> performance >>> affects their revenue. With AppDynamics, you get 100% visibility into >>> your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>> AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > -- > Course View Towers, > Plot 21 Yusuf Lule Road, > Kampala > T +256 (0) 312 314 418 > M +256 (0) 752 963 325 > www.weberpafrica.com > Twitter: @TimSchofield2 > Blog: http://weberpafrica.blogspot.co.uk/ > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: Tim S. <tim...@gm...> - 2013-11-27 16:21:56
|
Ah yes, the deliver to name? Anyone know of any others? It seems I can't update svn but these changes are very simple. Thanks Tim On 27 November 2013 15:42, ronwong <rwp...@rw...> wrote: > I can verify that this issue is still there. > > I have a customer's company name has the word Hug's. > It will come up Hug/////s > > THis is customer customer name. So my invoices are all like this. > Same with customer addresses. > > > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers -- Course View Towers, Plot 21 Yusuf Lule Road, Kampala T +256 (0) 312 314 418 M +256 (0) 752 963 325 www.weberpafrica.com Twitter: @TimSchofield2 Blog: http://weberpafrica.blogspot.co.uk/ |
From: ronwong <rwp...@rw...> - 2013-11-27 16:00:00
|
I can verify that this issue is still there. I have a customer's company name has the word Hug's. It will come up Hug/////s THis is customer customer name. So my invoices are all like this. Same with customer addresses. -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Replicating-slashes-problem-escaping-special-chars-for-database-insertion-or-HTML-tp4656976p4656983.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
From: Tim S. <tim...@gm...> - 2013-11-27 14:27:53
|
Hi Jo, I meant I thought we had dealt with most instances. For instance creating a sales order for smith's crisps does not generate this error. I think the overwhelming majority of webERP scripts are of the type: "Fill in a form, submit it and update the database". Fixing this *seems* to be just a case of using stripslashes() on the item description in the PO_Items.php script. This code in session.inc came about after a security review by Steve Lord many years ago, and I would be very nervous about taking it out. Thanks Tim On 27 November 2013 12:30, icedlava <ice...@gm...> wrote: > Hi Tim, > >> thought we had caught and dealt with these > > We caught an instance but I knew at the time it required a broader fix > but was unable to identify best way ahead for it. > > I have raised the issue some time ago with Phil but not had time until > now to look at the code and had a better look today. > >> Can you give some >> examples of where it is still happening? > > Perhaps you can try replicate - it could be text with special char in > any text field that is submitted in a form, a displayed value or input > value that has some e.g. post var, get var or session var submitted to > the database (some specific instances in the code have been addressed > and fixed like you mentioned). > > I will try and provide an example: > > 1. Create an item with an item description such as "Smith's Chips" > 2. Place a purchase order and select the item for your order. > 3. At the PO_items.php function, with the line item for the order > selected, click on Update Order lines and watch the description. You > should get more slashes each time you click the Update Order lines > button. > > I think, that we cannot assume in the sessions.inc file that we are > going to add/update a post or get or session var to a database at first > instance - it could be displayed only, it could be used in an input post > field etc > > - when we save to the database call the relevant function e.g. > mysqli_real_escape_string on non-html entity string (in weberp this is > the DB_escape_string function but should be nonentity string e.g. use > htmlspecialchars_decode not htmlspecialchars). > > - when we display in HTML use htmlspecialchar call to encode to entities > where relevant. > > Anyway this is just some issue i came across a while ago and now > revisiting in hope we can squash it for good - maybe someone has a > solution already. > > Cheers! > > > > > On 27 Nov 2013, at 18:57, Tim Schofield wrote: > >> Hi Jo, >> >> I thought we had caught and dealt with these. Can you give some >> examples of where it is still happening? >> >> Thanks >> Tim >> >> On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >>> Currently we have sessions.inc processing all session, post and get >>> vars in >>> the same way. >>> >>> We make a big assumption here with DB_escape_string at line 59 and 66 >>> (for >>> single var and slightly different for arrays): >>> >>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >>> >>> This assumes that we know what a function will do with the >>> post/get/sessions >>> vars and that they are going to be inserted/updated to a database. >>> They are >>> passed to the DB_escape_string function which returns (for mysqli): >>> >>> mysqli_real_escape_string($db, htmlspecialchars($String, >>> ENT_COMPAT,'utf-8', >>> false)); >>> >>> This is causing exponential slash addition to variables which are not >>> entered to a database but instead posted to a HTML field value. Each >>> time >>> the field is updated the value is saved in the database with extra >>> slashes >>> when escaping a special char like a single quote. >>> >>> If we do actually need to do this variable processing in sessions.inc >>> then >>> perhaps we could decide what is more common displaying the var or >>> insert/updating to a db. >>> >>> If we chose for example that displaying the var on the page is more >>> common >>> then we should change sessions inc for example on this line: >>> >>> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >>> >>> to >>> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >>> ENT_QUOTES,'UTF-8'); >>> >>> and for this case in DB_escape_string from: >>> >>> return mysqli_real_escape_string($db, htmlspecialchars($String, >>> ENT_COMPAT,'utf-8', false)); >>> to >>> >>> return mysqli_real_escape_string($db, >>> htmlspecialchars_decode($String, >>> ENT_COMPAT)); >>> >>> >>> Then we need to call DB_escape_string on vars before we send to any >>> insert >>> or edit for database. >>> >>> On the other hand - we need to do the opposite if we assume it is >>> more >>> likely to post to the database. >>> >>> Perhaps there is another 3rd way to handle it? >>> >>> Thanks to all in advance for any feedback!! >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most >>> IT >>> organizations don't have a clear picture of how application >>> performance >>> affects their revenue. With AppDynamics, you get 100% visibility into >>> your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>> AppDynamics >>> Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >> >> >> >> -- >> Course View Towers, >> Plot 21 Yusuf Lule Road, >> Kampala >> T +256 (0) 312 314 418 >> M +256 (0) 752 963 325 >> www.weberpafrica.com >> Twitter: @TimSchofield2 >> Blog: http://weberpafrica.blogspot.co.uk/ >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most >> IT >> organizations don't have a clear picture of how application >> performance >> affects their revenue. With AppDynamics, you get 100% visibility into >> your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers -- Course View Towers, Plot 21 Yusuf Lule Road, Kampala T +256 (0) 312 314 418 M +256 (0) 752 963 325 www.weberpafrica.com Twitter: @TimSchofield2 Blog: http://weberpafrica.blogspot.co.uk/ |
From: icedlava <ice...@gm...> - 2013-11-27 12:43:47
|
> I think the fix needs to be in the GLJournalInquiry.php so it shows the journals created correctly. OK i'll look. But why is it we need GL on to make a GL transaction for bank accounts through General Ledger - bank receipt/payment, but do not need GL on to make a GL transaction in the journal area? If we go through the General Ledger menu then for consistency should not a transaction result in a GL entry in gltrans with or without GL switch on - this would be consistent instead of one doing so and one not doing so? Then, I could also fix the GLJournalInquiry if we can as you pointed out discriminate between GL payments and receipts and other bank transactions it should not be too difficult (i.e. 1 for GL payments, 2 for GL receipts). Thanks for your help! On 27 Nov 2013, at 17:25, Phil Daintree wrote: > I think the fix needs to be in the GLJournalInquiry.php so it shows the journals created correctly. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 27/11/13 19:52, iced lava wrote: >> > It is not necessary to modify the transaction type in the gltrans table. >> >> To see the bank transactions in the general journal enquiries we do. >> >> >Can you point me to where the manual said the integration should be off when taking on GL balances? >> I will take another look and let you know - i know i found it confusing when i first used webERP and went on a google hunt. It's been some time since i looked at that part of the manual and i've always turned on GL for bank transactions and off for everything else added through the General Ledger menu. >> >> > Which listings are you not able to see the balances ... script names ideally please >> GLJournalInquiry.php - will not display bank transaction journals. >> >> And yes, trial balance shows balances correctly :) >> >> Thanks for taking a look. >> >> >> On Wed, Nov 27, 2013 at 5:09 PM, Phil Daintree <ph...@lo... <mailto:ph...@lo...>> wrote: >> >> It is not necessary to modify the transaction type in the gltrans >> table. >> Can you point me to where the manual said the integration should >> be off when taking on GL balances? I can see where it says this in >> relation to setting up debtors and creditors balances i.e the open >> items in the sub-ledgers. >> Which listings are you not able to see the balances ... script >> names ideally please. Maybe this is where the problem lies - >> assuming the trial balance shows the balances correctly! >> >> >> Phil >> >> Phil Daintree >> Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> >> http://www.logicworks.co.nz >> >> On 27/11/13 15:23, iced lava wrote: >>> Provisos and issue remaining: >>> >>> 1. The opening balance transaction in the example with GL trans >>> should occur with GL turned off (if instructions in manual are >>> correct) >>> >>> 2. The behaviour cannot be applied generally to transactions >>> through General Ledger unless the these transactions are >>> displayed, such as bank fees, in the bank reconcilliation >>> listings. They do not display when type is set to 0 (general >>> journal) in the gltrans table and so fix should be determined for >>> the reconcilliation functions. >>> >>> Comments appreciated. >>> >>> Thanks, >>> >>> >>> >>> On Wed, Nov 27, 2013 at 12:44 PM, iced lava <ice...@gm... >>> <mailto:ice...@gm...>> wrote: >>> >>> As an example: >>> I note that if I enter the bank balances at 30 June with GL >>> on, I can change the Type of transaction in the gltrans table >>> to 0 (general journal). Appropriate [next] incremented >>> general journal numbers a can provided to these transactions >>> by editing as well [and systype incremented accordingly and >>> chart detail also adjusted]. >>> >>> If this is done then the year closing journals appear as >>> required in the journal listings, on the trial balance and >>> the bank listings and reports also seem correct (transactions >>> are left untouched in banktrans table). >>> >>> >>> This is as expected for the entry made through General Ledger >>> bank receipts. >>> >>> >>> Is this a bug? >>> Should this behaviour also happen for other bank receipts and >>> payments made through General Ledger option? I would think so. >>> >>> I can fix if required. >>> >>> Thanks. >>> >>> >>> >>> >>> On Wed, Nov 27, 2013 at 12:04 PM, iced lava >>> <ice...@gm... <mailto:ice...@gm...>> wrote: >>> >>> Could I have confirmation on what should happen when bank >>> account balances are entered in for end of year closing >>> balances eg at 30 June. >>> >>> Here is the current behaviour I see in latest webERP. >>> Note that usually according to documentation year end >>> balances should be done with GL integration off. >>> >>> 1. With GL integration turned off, the bank balances are >>> taken on at 30 June by entering a receipt (General Ledger >>> - Bank account receipt entry). >>> >>> * This transaction only appears as a single entry in >>> the banktrans table - nowhere else >>> * there is no corresponding balancing transaction - it >>> would have to be made manually >>> * as such the bank account balances do not appear in >>> any 30 June trial balance >>> * a listing of 30 June journal entries does not show >>> any 30 June entries for any bank accounts GL accounts >>> * trial balance as a consequence does not have any >>> entries for these bank transactions >>> >>> >>> 2. With the GL integration turned on - if the bank >>> balances are taken on at 30 June by entering a receipt >>> (General Ledger - Bank account receipt entry) >>> >>> * The transaction appears as an entry in the banktrans >>> table >>> * there is a corresponding transaction in the gltrans >>> table and the balancing transaction(s) >>> * the chartdetails table has entries for these transactions >>> * trial balance shows an entry for these bank accounts >>> * the listing of 30 June journal entries does not show >>> anything for the bank accounts >>> * the type in the gltrans table is type 12 - bank >>> transaction, not 0 for general journal >>> >>> >>> This is causing confusing with customer. >>> >>> The behaviour I thought would happen is that any bank >>> transactions entered through the General Ledger - Bank >>> account [receipt/payment] should in fact have entries in >>> gltrans table and subsequent entries in the chart >>> details. They then should appear in journal reports. >>> >>> This would be in contrast to payments/receipts made via >>> the Payments and Receipts menus for debtors and creditors. >>> >>> However, for bank fees and such which must be entered >>> through General Ledger payment (not a creditor), this >>> poses a problem as the amounts will show in bank account >>> transaction listings/reconcilliations - as they should. >>> Howevrer they will never show as a general journal or >>> reports as such (they are trans 12 not 0). >>> >>> Thanks in advance for any advice. >>> >>> Cheers, >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> >>> >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... <mailto:Web...@li...> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. >> Most IT >> organizations don't have a clear picture of how application >> performance >> affects their revenue. With AppDynamics, you get 100% visibility >> into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: icedlava <ice...@gm...> - 2013-11-27 12:40:00
|
> BUT where a $_POST is used as a criteria to some SQL we need the mysqli_escape_string to avoid any shenanigans with clever sods messing with the SQL to return stuff they shouldn't be looking at Yes, and this is the hack work i mentioned some time ago that may need doing to fix - unless we can find a better solution. Should we address it in sessions.inc? Not sure that is correct. Should we have a special prep for display and prep for database call we use for vars - do we rely on devs to ensure they prep any vars in their functions as required? Not sure. We need to escape before posting to db, and encode for html entities before we display vars - but mixing both as we do now is causing issues. I tried to give an example in my last post in reply to Tim. There are lots of ways but which way might need some discussion and balance need for performance, work involved to fix, and security. Cheers! On 27 Nov 2013, at 17:36, Phil Daintree wrote: > Looks like you are onto this one!! Yes this makes sense... I think you have identified the source of the problem... BUT where a $_POST is used as a criteria to some SQL we need the mysqli_escape_string to avoid any shenanigans with clever sods messing with the SQL to return stuff they shouldn't be looking at. > This function is a bit of a sledge hammer approach. Maybe we need to identify the variables where it is going wrong - I don't see it much.... although I have seen it before in descriptions I think - and perhaps we could strip slashes or similar. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 27/11/13 19:57, iced lava wrote: >> Currently we have sessions.inc processing all session, post and get vars in the same way. >> >> We make a big assumption here with DB_escape_string at line 59 and 66 (for single var and slightly different for arrays): >> >> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >> >> This assumes that we know what a function will do with the post/get/sessions vars and that they are going to be inserted/updated to a database. They are passed to the DB_escape_string function which returns (for mysqli): >> >> mysqli_real_escape_string($db, htmlspecialchars($String, ENT_COMPAT,'utf-8', false)); >> >> This is causing exponential slash addition to variables which are not entered to a database but instead posted to a HTML field value. Each time the field is updated the value is saved in the database with extra slashes when escaping a special char like a single quote. >> >> If we do actually need to do this variable processing in sessions.inc then perhaps we could decide what is more common displaying the var or insert/updating to a db. >> >> If we chose for example that displaying the var on the page is more common then we should change sessions inc for example on this line: >> >> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >> >> to >> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, ENT_QUOTES,'UTF-8'); >> >> and for this case in DB_escape_string from: >> >> return mysqli_real_escape_string($db, htmlspecialchars($String, ENT_COMPAT,'utf-8', false)); >> to >> >> return mysqli_real_escape_string($db, htmlspecialchars_decode($String, ENT_COMPAT)); >> >> >> Then we need to call DB_escape_string on vars before we send to any insert or edit for database. >> >> On the other hand - we need to do the opposite if we assume it is more likely to post to the database. >> >> Perhaps there is another 3rd way to handle it? >> >> Thanks to all in advance for any feedback!! >> >> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk_______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
From: icedlava <ice...@gm...> - 2013-11-27 12:30:44
|
Hi Tim, > thought we had caught and dealt with these We caught an instance but I knew at the time it required a broader fix but was unable to identify best way ahead for it. I have raised the issue some time ago with Phil but not had time until now to look at the code and had a better look today. > Can you give some > examples of where it is still happening? Perhaps you can try replicate - it could be text with special char in any text field that is submitted in a form, a displayed value or input value that has some e.g. post var, get var or session var submitted to the database (some specific instances in the code have been addressed and fixed like you mentioned). I will try and provide an example: 1. Create an item with an item description such as "Smith's Chips" 2. Place a purchase order and select the item for your order. 3. At the PO_items.php function, with the line item for the order selected, click on Update Order lines and watch the description. You should get more slashes each time you click the Update Order lines button. I think, that we cannot assume in the sessions.inc file that we are going to add/update a post or get or session var to a database at first instance - it could be displayed only, it could be used in an input post field etc - when we save to the database call the relevant function e.g. mysqli_real_escape_string on non-html entity string (in weberp this is the DB_escape_string function but should be nonentity string e.g. use htmlspecialchars_decode not htmlspecialchars). - when we display in HTML use htmlspecialchar call to encode to entities where relevant. Anyway this is just some issue i came across a while ago and now revisiting in hope we can squash it for good - maybe someone has a solution already. Cheers! On 27 Nov 2013, at 18:57, Tim Schofield wrote: > Hi Jo, > > I thought we had caught and dealt with these. Can you give some > examples of where it is still happening? > > Thanks > Tim > > On 27 November 2013 06:57, iced lava <ice...@gm...> wrote: >> Currently we have sessions.inc processing all session, post and get >> vars in >> the same way. >> >> We make a big assumption here with DB_escape_string at line 59 and 66 >> (for >> single var and slightly different for arrays): >> >> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue); >> >> This assumes that we know what a function will do with the >> post/get/sessions >> vars and that they are going to be inserted/updated to a database. >> They are >> passed to the DB_escape_string function which returns (for mysqli): >> >> mysqli_real_escape_string($db, htmlspecialchars($String, >> ENT_COMPAT,'utf-8', >> false)); >> >> This is causing exponential slash addition to variables which are not >> entered to a database but instead posted to a HTML field value. Each >> time >> the field is updated the value is saved in the database with extra >> slashes >> when escaping a special char like a single quote. >> >> If we do actually need to do this variable processing in sessions.inc >> then >> perhaps we could decide what is more common displaying the var or >> insert/updating to a db. >> >> If we chose for example that displaying the var on the page is more >> common >> then we should change sessions inc for example on this line: >> >> $_POST[$PostVariableName] = DB_escape_string($PostVariableValue) >> >> to >> $_POST[$PostVariableName]= htmlspecialchars($PostArrayValue, >> ENT_QUOTES,'UTF-8'); >> >> and for this case in DB_escape_string from: >> >> return mysqli_real_escape_string($db, htmlspecialchars($String, >> ENT_COMPAT,'utf-8', false)); >> to >> >> return mysqli_real_escape_string($db, >> htmlspecialchars_decode($String, >> ENT_COMPAT)); >> >> >> Then we need to call DB_escape_string on vars before we send to any >> insert >> or edit for database. >> >> On the other hand - we need to do the opposite if we assume it is >> more >> likely to post to the database. >> >> Perhaps there is another 3rd way to handle it? >> >> Thanks to all in advance for any feedback!! >> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most >> IT >> organizations don't have a clear picture of how application >> performance >> affects their revenue. With AppDynamics, you get 100% visibility into >> your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> AppDynamics >> Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > > > -- > Course View Towers, > Plot 21 Yusuf Lule Road, > Kampala > T +256 (0) 312 314 418 > M +256 (0) 752 963 325 > www.weberpafrica.com > Twitter: @TimSchofield2 > Blog: http://weberpafrica.blogspot.co.uk/ > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most > IT > organizations don't have a clear picture of how application > performance > affects their revenue. With AppDynamics, you get 100% visibility into > your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |