Menu
▾
▴
web-erp-developers — Discussion on development of webERP
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...> - 2014-04-03 09:24:16
|
*Hi, Phil,*
Thank you for your nice comments.
1. Thumb has almost completed the bin management module. I've
created an distributed version based on 4.10. I'll send it to you later.
2. Yes. It's better to assessment suppliers based on items. The
situation seems a little complicated. Need more consideration to this.
3. Currently, the salesman can only review their own customer
data if they are marked as salesman login. But we found that sometime some
users have 2 salesman accounts, they have to login and logout to see the
accounts they owned. And if there are several sales groups, the group leader
will not see their team's status. Thumb has created a team feature. Do we
need to add this feature to webERP? It seems more like a CRM concept. And
another scenario is that, some users will have one team to manage sales
orders, their responsibility will be classified by customer's type. For
instance, Clerk A will be responsible for customer type A, and Clerk B will
be responsible for customer type B. Shall this features is needed?
Thanks and best regards!
Exson
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Other-feature-to-develop-tp4657319p4657321.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: Phil D. <ph...@lo...> - 2014-04-03 08:08:45
|
Hi Exson, Thanks for your great efforts to make webERP better. That's an interesting idea - perhaps for 1 it needs to be by item - so perhaps they are ok to provide widget X but not widget Y. 2. Yes if we can work out a URL to initiate IM then would be good 3. Not quite so clear on this one. I think the salesman logic got a bit messy - not clear on how you see this evolving. Did the warehouse management development work ever get completed? Best regards Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 03/04/14 14:26, ExsonQu wrote: > *Dear all,* > > Thank you for your great efforts to webERP. > > I'd like to know if it need to develop following features or we > have work around for it: > > 1. Vendor status management. Currently, we have customers status > management such as watch, liquid, good etc. But we have no corresponding > feature with suppliers. I think it's also a need feature to record suppliers > status such as assessment, qualified, non-conformance. We can only issue PO > to qualified vendors. > > 2. IM is very popular even between businesses today, shall we > add a IM contact address for customer branches? > > 3. We have some control about sales people login now. But > sometime, roles such as sales group leaders have to view whole group's > customer data, is there any workaround or we just have to develop some new > feature. > > Any comments are welcome! > > Thanks and best regards! > > Exson > > > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Other-feature-to-develop-tp4657319.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: ExsonQu <hex...@gm...> - 2014-04-03 01:27:00
|
*Dear all,*
Thank you for your great efforts to webERP.
I'd like to know if it need to develop following features or we
have work around for it:
1. Vendor status management. Currently, we have customers status
management such as watch, liquid, good etc. But we have no corresponding
feature with suppliers. I think it's also a need feature to record suppliers
status such as assessment, qualified, non-conformance. We can only issue PO
to qualified vendors.
2. IM is very popular even between businesses today, shall we
add a IM contact address for customer branches?
3. We have some control about sales people login now. But
sometime, roles such as sales group leaders have to view whole group's
customer data, is there any workaround or we just have to develop some new
feature.
Any comments are welcome!
Thanks and best regards!
Exson
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Other-feature-to-develop-tp4657319.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: Phil D. <ph...@lo...> - 2014-03-31 08:58:25
|
Crickey, seems pretty tough to get any output from prepare/execute. This feels very messy to me... nothing pretty about it! Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 31/03/14 15:28, Jon R wrote: > Sorry about the repeating there, was on my phone and it does weird things. > I figured out a work around for the DB_PreparedQuery issues, I made a > class that has most of the functions of mysqli_result, and > DB_PreparedQuery passes that back. That way, the DB functions can > handle it as if it was a mysqli_result object. I've updated the > working branch accordingly. > I also moved $Parameters to the second position, so you don't have to > specify values for everything (since DB_Query is now different > $Parameters doesn't need to be last anymore), and reduced reliance on > passing $db around, although legacy code will still work. I recommend > removing $db from code outside of the connection includes wherever > possible. > > /Sent from my iLaptop/ > > > On Sun, Mar 30, 2014 at 11:41 AM, Jon R <jr...@gm... > <mailto:jr...@gm...>> wrote: > > Hi Phil, the main issue is icedlava's code returns an array and > all the support functions expect a mysqli_result object. If you > have: a) DB_query returns an array also, and the support functions > expect an array (hard to implement for the fetch functions) b) we > take the array result into account and handle DB_Preparedquery > differently from DB_Query (i don't recommend this) or, Hi Phil, > the main issue is icedlava's code returns an array and all the > support functions expect a mysqli_result object. If you have: a) > DB_query returns an array also, and the support functions expect > an array (hard to implement for the fetch functions) b) we take > the array result into account and handle DB_Preparedquery > differently from DB_Query (i don't recommend this) or, Hi Phil, > the main issue is icedlava's code returns an array and all the > support functions expect a mysqli_result object. If you have: a) > DB_query returns an array also, and the support functions expect > an array (hard to implement for the fetch functions) b) we take > the array result into account and handle DB_Preparedquery > differently from DB_Query (i don't recommend this) or, Hi Phil, > the main issue is icedlava's code returns an array and all the > support functions expect a mysqli_result object. If you have: a) > DB_query returns an array also, and the support functions expect > an array (hard to implement for the fetch functions) b) we take > the array result into account and handle DB_Preparedquery > differently from DB_Query (i don't recommend this) or, c) we > return the mysqli_stmt back, which has issues with binding the > return values, and that DB_Query returns a mysqli_result object, > which handles differently from mysqli_stmt > > On Mar 30, 2014 6:29 AM, "Phil Daintree" <ph...@lo... > <mailto:ph...@lo...>> wrote: > > I had a go at removing the $Conn parameter and renaming the > function > > DB_PreparedQuery() > > leaving the DB_query() function where it is - no reason why we > can't > continue to use it where there are no parameters involved I > guess - as > you suggested Jo... > > I messed with the style to try to bring the new code into line > with the > conventions we use and make the variable names a bit more > meaningful - I > hate abbreviated variable names that give you no clue as to > what is > going on... it is obvious when you write the code but 3 or 4 > sleeps > later not so obvious ... curly braces on the same line as the > function > call/if test etc etc. > > and of course predictably I have messed it up - login and > AccounGroups.php no longer work :-( > > Hopefully though the concept is clear. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > <tel:%2B64%20%280%29275%20567890> > http://www.logicworks.co.nz > > On 28/03/14 20:42, icedlava wrote: > > Phil, > > > > Can I commit TWIG to the new branch and a simple integration > - existing > > code will work as normal but it would provide somewhere to > add twig > > templates and themes for proof of concept or comparison? > > > > If it is not required, or wanted, it could be removed later. > > > > What do you think? > > > > > > > > On 28 Mar 2014, at 17:34, Phil Daintree wrote: > > > >> Jo, > >> > >> I can find it now - but have you written your ideal new > function - > >> named > >> other than DB_query - and where the parameter type is given > explicitly > >> rather than inferred? Would be interested to see that... > perhaps since > >> we are doing this we should jump right on in? > >> > >> I am also rethinking the TableView class idea to eliminate the > >> <tr><td></td></tr> all over the place - and perhaps maybe > conversion > >> to > >> <div> with optional classes? that might more easily > accommodate phones > >> etc. We are of course looking it almost a complete re-write > here! > >> > >> Let's go :-) > >> > >> Phil > >> > >> Phil Daintree > >> Logic Works Ltd - +64 (0)275 567890 > <tel:%2B64%20%280%29275%20567890> > >> http://www.logicworks.co.nz > >> > >> On 28/03/14 19:07, icedlava wrote: > >>> Hi Phil, > >>> > >>>> As you say, my revised DB_query() just escapes the > parameters as > >>>> they > >>>> were previously - just that we have now moved the > escaping to the > >>>> place > >>>> where it needs to happen rather than blanket escaping every > >>>> $_POST/$_GET > >>>> - so we are equally secure as we were ... unless I am > wrong and > >>>> those > >>>> variables which should not be escaped are not escape > >>> Yes, exactly - we are equally secure as we were before for > database > >>> transactions. > >>> As you say, the whole reason that this topic came up was > due to > >>> non-contextual escaping of variables and the issues that > has and is > >>> continuing to cause in the code/database. > >>> We have the opportunity now to fix it, but also improve > the security > >>> of > >>> webERP as we fix the original variable problem, which is > what I've > >>> tried to do with the version I committed. > >>> > >>> Thanks for your understanding! > >>> > >>> Cheers, > >>> > >>> > >>> On 28 Mar 2014, at 16:27, Phil Daintree wrote: > >>> > >>>> Hi Jo, > >>>> > >>>> As you say, my revised DB_query() just escapes the > parameters as > >>>> they > >>>> were previously - just that we have now moved the > escaping to the > >>>> place > >>>> where it needs to happen rather than blanket escaping every > >>>> $_POST/$_GET > >>>> - so we are equally secure as we were ... unless I am > wrong and > >>>> those > >>>> variables which should not be escaped are not escaped. > >>>> > >>>> That said, I will look into the full prepare execute > method in more > >>>> detail. Of course with my blinkered vision what I did is more > >>>> readable > >>>> :-) I am persuaded by the argument to do things the most > secure way > >>>> though given we are into a major re-write and I think > this may be > >>>> the > >>>> full prepare/execute method you first suggested. > >>>> > >>>> Phil > >>>> > >>>> Phil Daintree > >>>> Logic Works Ltd - +64 (0)275 567890 > <tel:%2B64%20%280%29275%20567890> > >>>> http://www.logicworks.co.nz > >>>> > >>>> On 28/03/14 16:45, icedlava wrote: > >>>>> Hi Phil, > >>>>> > >>>>> For reference here on the list, I have committed the code as > >>>>> requested. > >>>>> You have updated the original function I committed which > changes > >>>>> and > >>>>> I > >>>>> did make a point to you in email that these changes will > not work. > >>>>> > >>>>> As per your request I've forwarded your response to the > mailing > >>>>> list > >>>>> but > >>>>> posting here for completeness in this thread. > >>>>> > >>>>> Note that the latest changes will not work because it is > not the > >>>>> fact > >>>>> that the query is prepared, it is the fact the query is > >>>>> paramaterized > >>>>> that makes it secure. > >>>>> Parameterized queries, done in the way I did it work > because the > >>>>> query > >>>>> string and the variables are sent separately to the > database server > >>>>> and > >>>>> only there are put together. > >>>>> > >>>>> The changes you made are no different to the original > DB_query that > >>>>> mysql_db_escapes the data - except there is more code > and separated > >>>>> parameters. The key issue: > >>>>> > >>>>> In your new code: > >>>>> $result=mysqli_query($Conn, $SQLString); is the problem. No > >>>>> different > >>>>> to > >>>>> prior old DB_query. > >>>>> > >>>>> The query is already 'put together' with query and > variables before > >>>>> it > >>>>> goes to the server. That is the insecure nature of it > and why I > >>>>> changed > >>>>> it. > >>>>> > >>>>> Appreciate your work and thought on it so far. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: > >>>>> > >>>>>> I've made up a new branch so we can mess with this a bit > >>>>>> > >>>>>> svn checkout --username=XXXXX > >>>>>> > svn+ssh://XX...@sv.../p/web-erp/code/branches/working <http://XX...@sv.../p/web-erp/code/branches/working> > >>>>>> yourworkingcopy > >>>>>> > >>>>>> where XXXXX is your sourceforge login. > >>>>>> > >>>>>> Jo, if you commit the code you want for the new > DB_query - and I > >>>>>> propose > >>>>>> we should keep it the same name - but with a new optional > >>>>>> parameter > >>>>>> for > >>>>>> the array of parameters. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Phil > >>>>>> > >>>>>> Phil Daintree > >>>>>> Logic Works Ltd - +64 (0)275 567890 > <tel:%2B64%20%280%29275%20567890> > >>>>>> http://www.logicworks.co.nz > >>>>>> > >>>>>> > >>>>>> > ------------------------------------------------------------------------------ > >>>>>> Learn Graph Databases - Download FREE O'Reilly Book > >>>>>> "Graph Databases" is the definitive new guide to graph > databases > >>>>>> and > >>>>>> their > >>>>>> applications. Written by three acclaimed leaders in the > field, > >>>>>> this first edition is now available. Download your free > book > >>>>>> today! > >>>>>> http://p.sf.net/sfu/13534_NeoTech > >>>>>> _______________________________________________ > >>>>>> Web-erp-developers mailing list > >>>>>> Web...@li... > <mailto:Web...@li...> > >>>>>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>>> > ------------------------------------------------------------------------------ > >>>>> _______________________________________________ > >>>>> Web-erp-developers mailing list > >>>>> Web...@li... > <mailto:Web...@li...> > >>>>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>>> > >>>> > ------------------------------------------------------------------------------ > >>>> _______________________________________________ > >>>> Web-erp-developers mailing list > >>>> Web...@li... > <mailto:Web...@li...> > >>>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>> > ------------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Web-erp-developers mailing list > >>> Web...@li... > <mailto:Web...@li...> > >>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>> > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> Web-erp-developers mailing list > >> Web...@li... > <mailto:Web...@li...> > >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > <mailto:Web...@li...> > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > <mailto:Web...@li...> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Jon R <jr...@gm...> - 2014-03-31 02:28:55
|
Sorry about the repeating there, was on my phone and it does weird things. I figured out a work around for the DB_PreparedQuery issues, I made a class that has most of the functions of mysqli_result, and DB_PreparedQuery passes that back. That way, the DB functions can handle it as if it was a mysqli_result object. I've updated the working branch accordingly. I also moved $Parameters to the second position, so you don't have to specify values for everything (since DB_Query is now different $Parameters doesn't need to be last anymore), and reduced reliance on passing $db around, although legacy code will still work. I recommend removing $db from code outside of the connection includes wherever possible. *Sent from my iLaptop* On Sun, Mar 30, 2014 at 11:41 AM, Jon R <jr...@gm...> wrote: > Hi Phil, the main issue is icedlava's code returns an array and all the > support functions expect a mysqli_result object. If you have: a) DB_query > returns an array also, and the support functions expect an array (hard to > implement for the fetch functions) b) we take the array result into account > and handle DB_Preparedquery differently from DB_Query (i don't recommend > this) or, Hi Phil, the main issue is icedlava's code returns an array and > all the support functions expect a mysqli_result object. If you have: a) > DB_query returns an array also, and the support functions expect an array > (hard to implement for the fetch functions) b) we take the array result > into account and handle DB_Preparedquery differently from DB_Query (i don't > recommend this) or, Hi Phil, the main issue is icedlava's code returns an > array and all the support functions expect a mysqli_result object. If you > have: a) DB_query returns an array also, and the support functions expect > an array (hard to implement for the fetch functions) b) we take the array > result into account and handle DB_Preparedquery differently from DB_Query > (i don't recommend this) or, Hi Phil, the main issue is icedlava's code > returns an array and all the support functions expect a mysqli_result > object. If you have: a) DB_query returns an array also, and the support > functions expect an array (hard to implement for the fetch functions) b) we > take the array result into account and handle DB_Preparedquery differently > from DB_Query (i don't recommend this) or, c) we return the mysqli_stmt > back, which has issues with binding the return values, and that DB_Query > returns a mysqli_result object, which handles differently from mysqli_stmt > On Mar 30, 2014 6:29 AM, "Phil Daintree" <ph...@lo...> wrote: > >> I had a go at removing the $Conn parameter and renaming the function >> >> DB_PreparedQuery() >> >> leaving the DB_query() function where it is - no reason why we can't >> continue to use it where there are no parameters involved I guess - as >> you suggested Jo... >> >> I messed with the style to try to bring the new code into line with the >> conventions we use and make the variable names a bit more meaningful - I >> hate abbreviated variable names that give you no clue as to what is >> going on... it is obvious when you write the code but 3 or 4 sleeps >> later not so obvious ... curly braces on the same line as the function >> call/if test etc etc. >> >> and of course predictably I have messed it up - login and >> AccounGroups.php no longer work :-( >> >> Hopefully though the concept is clear. >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890 >> http://www.logicworks.co.nz >> >> On 28/03/14 20:42, icedlava wrote: >> > Phil, >> > >> > Can I commit TWIG to the new branch and a simple integration - existing >> > code will work as normal but it would provide somewhere to add twig >> > templates and themes for proof of concept or comparison? >> > >> > If it is not required, or wanted, it could be removed later. >> > >> > What do you think? >> > >> > >> > >> > On 28 Mar 2014, at 17:34, Phil Daintree wrote: >> > >> >> Jo, >> >> >> >> I can find it now - but have you written your ideal new function - >> >> named >> >> other than DB_query - and where the parameter type is given explicitly >> >> rather than inferred? Would be interested to see that... perhaps since >> >> we are doing this we should jump right on in? >> >> >> >> I am also rethinking the TableView class idea to eliminate the >> >> <tr><td></td></tr> all over the place - and perhaps maybe conversion >> >> to >> >> <div> with optional classes? that might more easily accommodate phones >> >> etc. We are of course looking it almost a complete re-write here! >> >> >> >> Let's go :-) >> >> >> >> Phil >> >> >> >> Phil Daintree >> >> Logic Works Ltd - +64 (0)275 567890 >> >> http://www.logicworks.co.nz >> >> >> >> On 28/03/14 19:07, icedlava wrote: >> >>> Hi Phil, >> >>> >> >>>> As you say, my revised DB_query() just escapes the parameters as >> >>>> they >> >>>> were previously - just that we have now moved the escaping to the >> >>>> place >> >>>> where it needs to happen rather than blanket escaping every >> >>>> $_POST/$_GET >> >>>> - so we are equally secure as we were ... unless I am wrong and >> >>>> those >> >>>> variables which should not be escaped are not escape >> >>> Yes, exactly - we are equally secure as we were before for database >> >>> transactions. >> >>> As you say, the whole reason that this topic came up was due to >> >>> non-contextual escaping of variables and the issues that has and is >> >>> continuing to cause in the code/database. >> >>> We have the opportunity now to fix it, but also improve the security >> >>> of >> >>> webERP as we fix the original variable problem, which is what I've >> >>> tried to do with the version I committed. >> >>> >> >>> Thanks for your understanding! >> >>> >> >>> Cheers, >> >>> >> >>> >> >>> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >> >>> >> >>>> Hi Jo, >> >>>> >> >>>> As you say, my revised DB_query() just escapes the parameters as >> >>>> they >> >>>> were previously - just that we have now moved the escaping to the >> >>>> place >> >>>> where it needs to happen rather than blanket escaping every >> >>>> $_POST/$_GET >> >>>> - so we are equally secure as we were ... unless I am wrong and >> >>>> those >> >>>> variables which should not be escaped are not escaped. >> >>>> >> >>>> That said, I will look into the full prepare execute method in more >> >>>> detail. Of course with my blinkered vision what I did is more >> >>>> readable >> >>>> :-) I am persuaded by the argument to do things the most secure way >> >>>> though given we are into a major re-write and I think this may be >> >>>> the >> >>>> full prepare/execute method you first suggested. >> >>>> >> >>>> Phil >> >>>> >> >>>> Phil Daintree >> >>>> Logic Works Ltd - +64 (0)275 567890 >> >>>> http://www.logicworks.co.nz >> >>>> >> >>>> On 28/03/14 16:45, icedlava wrote: >> >>>>> Hi Phil, >> >>>>> >> >>>>> For reference here on the list, I have committed the code as >> >>>>> requested. >> >>>>> You have updated the original function I committed which changes >> >>>>> and >> >>>>> I >> >>>>> did make a point to you in email that these changes will not work. >> >>>>> >> >>>>> As per your request I've forwarded your response to the mailing >> >>>>> list >> >>>>> but >> >>>>> posting here for completeness in this thread. >> >>>>> >> >>>>> Note that the latest changes will not work because it is not the >> >>>>> fact >> >>>>> that the query is prepared, it is the fact the query is >> >>>>> paramaterized >> >>>>> that makes it secure. >> >>>>> Parameterized queries, done in the way I did it work because the >> >>>>> query >> >>>>> string and the variables are sent separately to the database server >> >>>>> and >> >>>>> only there are put together. >> >>>>> >> >>>>> The changes you made are no different to the original DB_query that >> >>>>> mysql_db_escapes the data - except there is more code and separated >> >>>>> parameters. The key issue: >> >>>>> >> >>>>> In your new code: >> >>>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >> >>>>> different >> >>>>> to >> >>>>> prior old DB_query. >> >>>>> >> >>>>> The query is already 'put together' with query and variables before >> >>>>> it >> >>>>> goes to the server. That is the insecure nature of it and why I >> >>>>> changed >> >>>>> it. >> >>>>> >> >>>>> Appreciate your work and thought on it so far. >> >>>>> >> >>>>> Cheers, >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >> >>>>> >> >>>>>> I've made up a new branch so we can mess with this a bit >> >>>>>> >> >>>>>> svn checkout --username=XXXXX >> >>>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >> >>>>>> yourworkingcopy >> >>>>>> >> >>>>>> where XXXXX is your sourceforge login. >> >>>>>> >> >>>>>> Jo, if you commit the code you want for the new DB_query - and I >> >>>>>> propose >> >>>>>> we should keep it the same name - but with a new optional >> >>>>>> parameter >> >>>>>> for >> >>>>>> the array of parameters. >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Phil >> >>>>>> >> >>>>>> Phil Daintree >> >>>>>> Logic Works Ltd - +64 (0)275 567890 >> >>>>>> http://www.logicworks.co.nz >> >>>>>> >> >>>>>> >> >>>>>> >> ------------------------------------------------------------------------------ >> >>>>>> Learn Graph Databases - Download FREE O'Reilly Book >> >>>>>> "Graph Databases" is the definitive new guide to graph databases >> >>>>>> and >> >>>>>> their >> >>>>>> applications. Written by three acclaimed leaders in the field, >> >>>>>> this first edition is now available. Download your free book >> >>>>>> today! >> >>>>>> http://p.sf.net/sfu/13534_NeoTech >> >>>>>> _______________________________________________ >> >>>>>> Web-erp-developers mailing list >> >>>>>> Web...@li... >> >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>>>> >> ------------------------------------------------------------------------------ >> >>>>> _______________________________________________ >> >>>>> Web-erp-developers mailing list >> >>>>> Web...@li... >> >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>>>> >> >>>> >> ------------------------------------------------------------------------------ >> >>>> _______________________________________________ >> >>>> Web-erp-developers mailing list >> >>>> Web...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>> >> ------------------------------------------------------------------------------ >> >>> _______________________________________________ >> >>> Web-erp-developers mailing list >> >>> Web...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> >> Web-erp-developers mailing list >> >> Web...@li... >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Web-erp-developers mailing list >> > Web...@li... >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > |
|
From: Jon R <jr...@gm...> - 2014-03-30 03:41:55
|
Hi Phil, the main issue is icedlava's code returns an array and all the support functions expect a mysqli_result object. If you have: a) DB_query returns an array also, and the support functions expect an array (hard to implement for the fetch functions) b) we take the array result into account and handle DB_Preparedquery differently from DB_Query (i don't recommend this) or, Hi Phil, the main issue is icedlava's code returns an array and all the support functions expect a mysqli_result object. If you have: a) DB_query returns an array also, and the support functions expect an array (hard to implement for the fetch functions) b) we take the array result into account and handle DB_Preparedquery differently from DB_Query (i don't recommend this) or, Hi Phil, the main issue is icedlava's code returns an array and all the support functions expect a mysqli_result object. If you have: a) DB_query returns an array also, and the support functions expect an array (hard to implement for the fetch functions) b) we take the array result into account and handle DB_Preparedquery differently from DB_Query (i don't recommend this) or, Hi Phil, the main issue is icedlava's code returns an array and all the support functions expect a mysqli_result object. If you have: a) DB_query returns an array also, and the support functions expect an array (hard to implement for the fetch functions) b) we take the array result into account and handle DB_Preparedquery differently from DB_Query (i don't recommend this) or, c) we return the mysqli_stmt back, which has issues with binding the return values, and that DB_Query returns a mysqli_result object, which handles differently from mysqli_stmt On Mar 30, 2014 6:29 AM, "Phil Daintree" <ph...@lo...> wrote: > I had a go at removing the $Conn parameter and renaming the function > > DB_PreparedQuery() > > leaving the DB_query() function where it is - no reason why we can't > continue to use it where there are no parameters involved I guess - as > you suggested Jo... > > I messed with the style to try to bring the new code into line with the > conventions we use and make the variable names a bit more meaningful - I > hate abbreviated variable names that give you no clue as to what is > going on... it is obvious when you write the code but 3 or 4 sleeps > later not so obvious ... curly braces on the same line as the function > call/if test etc etc. > > and of course predictably I have messed it up - login and > AccounGroups.php no longer work :-( > > Hopefully though the concept is clear. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 28/03/14 20:42, icedlava wrote: > > Phil, > > > > Can I commit TWIG to the new branch and a simple integration - existing > > code will work as normal but it would provide somewhere to add twig > > templates and themes for proof of concept or comparison? > > > > If it is not required, or wanted, it could be removed later. > > > > What do you think? > > > > > > > > On 28 Mar 2014, at 17:34, Phil Daintree wrote: > > > >> Jo, > >> > >> I can find it now - but have you written your ideal new function - > >> named > >> other than DB_query - and where the parameter type is given explicitly > >> rather than inferred? Would be interested to see that... perhaps since > >> we are doing this we should jump right on in? > >> > >> I am also rethinking the TableView class idea to eliminate the > >> <tr><td></td></tr> all over the place - and perhaps maybe conversion > >> to > >> <div> with optional classes? that might more easily accommodate phones > >> etc. We are of course looking it almost a complete re-write here! > >> > >> Let's go :-) > >> > >> Phil > >> > >> Phil Daintree > >> Logic Works Ltd - +64 (0)275 567890 > >> http://www.logicworks.co.nz > >> > >> On 28/03/14 19:07, icedlava wrote: > >>> Hi Phil, > >>> > >>>> As you say, my revised DB_query() just escapes the parameters as > >>>> they > >>>> were previously - just that we have now moved the escaping to the > >>>> place > >>>> where it needs to happen rather than blanket escaping every > >>>> $_POST/$_GET > >>>> - so we are equally secure as we were ... unless I am wrong and > >>>> those > >>>> variables which should not be escaped are not escape > >>> Yes, exactly - we are equally secure as we were before for database > >>> transactions. > >>> As you say, the whole reason that this topic came up was due to > >>> non-contextual escaping of variables and the issues that has and is > >>> continuing to cause in the code/database. > >>> We have the opportunity now to fix it, but also improve the security > >>> of > >>> webERP as we fix the original variable problem, which is what I've > >>> tried to do with the version I committed. > >>> > >>> Thanks for your understanding! > >>> > >>> Cheers, > >>> > >>> > >>> On 28 Mar 2014, at 16:27, Phil Daintree wrote: > >>> > >>>> Hi Jo, > >>>> > >>>> As you say, my revised DB_query() just escapes the parameters as > >>>> they > >>>> were previously - just that we have now moved the escaping to the > >>>> place > >>>> where it needs to happen rather than blanket escaping every > >>>> $_POST/$_GET > >>>> - so we are equally secure as we were ... unless I am wrong and > >>>> those > >>>> variables which should not be escaped are not escaped. > >>>> > >>>> That said, I will look into the full prepare execute method in more > >>>> detail. Of course with my blinkered vision what I did is more > >>>> readable > >>>> :-) I am persuaded by the argument to do things the most secure way > >>>> though given we are into a major re-write and I think this may be > >>>> the > >>>> full prepare/execute method you first suggested. > >>>> > >>>> Phil > >>>> > >>>> Phil Daintree > >>>> Logic Works Ltd - +64 (0)275 567890 > >>>> http://www.logicworks.co.nz > >>>> > >>>> On 28/03/14 16:45, icedlava wrote: > >>>>> Hi Phil, > >>>>> > >>>>> For reference here on the list, I have committed the code as > >>>>> requested. > >>>>> You have updated the original function I committed which changes > >>>>> and > >>>>> I > >>>>> did make a point to you in email that these changes will not work. > >>>>> > >>>>> As per your request I've forwarded your response to the mailing > >>>>> list > >>>>> but > >>>>> posting here for completeness in this thread. > >>>>> > >>>>> Note that the latest changes will not work because it is not the > >>>>> fact > >>>>> that the query is prepared, it is the fact the query is > >>>>> paramaterized > >>>>> that makes it secure. > >>>>> Parameterized queries, done in the way I did it work because the > >>>>> query > >>>>> string and the variables are sent separately to the database server > >>>>> and > >>>>> only there are put together. > >>>>> > >>>>> The changes you made are no different to the original DB_query that > >>>>> mysql_db_escapes the data - except there is more code and separated > >>>>> parameters. The key issue: > >>>>> > >>>>> In your new code: > >>>>> $result=mysqli_query($Conn, $SQLString); is the problem. No > >>>>> different > >>>>> to > >>>>> prior old DB_query. > >>>>> > >>>>> The query is already 'put together' with query and variables before > >>>>> it > >>>>> goes to the server. That is the insecure nature of it and why I > >>>>> changed > >>>>> it. > >>>>> > >>>>> Appreciate your work and thought on it so far. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: > >>>>> > >>>>>> I've made up a new branch so we can mess with this a bit > >>>>>> > >>>>>> svn checkout --username=XXXXX > >>>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working > >>>>>> yourworkingcopy > >>>>>> > >>>>>> where XXXXX is your sourceforge login. > >>>>>> > >>>>>> Jo, if you commit the code you want for the new DB_query - and I > >>>>>> propose > >>>>>> we should keep it the same name - but with a new optional > >>>>>> parameter > >>>>>> for > >>>>>> the array of parameters. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Phil > >>>>>> > >>>>>> Phil Daintree > >>>>>> Logic Works Ltd - +64 (0)275 567890 > >>>>>> http://www.logicworks.co.nz > >>>>>> > >>>>>> > >>>>>> > ------------------------------------------------------------------------------ > >>>>>> Learn Graph Databases - Download FREE O'Reilly Book > >>>>>> "Graph Databases" is the definitive new guide to graph databases > >>>>>> and > >>>>>> their > >>>>>> applications. Written by three acclaimed leaders in the field, > >>>>>> this first edition is now available. Download your free book > >>>>>> today! > >>>>>> http://p.sf.net/sfu/13534_NeoTech > >>>>>> _______________________________________________ > >>>>>> Web-erp-developers mailing list > >>>>>> Web...@li... > >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>>> > ------------------------------------------------------------------------------ > >>>>> _______________________________________________ > >>>>> Web-erp-developers mailing list > >>>>> Web...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>>> > >>>> > ------------------------------------------------------------------------------ > >>>> _______________________________________________ > >>>> Web-erp-developers mailing list > >>>> Web...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>> > ------------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Web-erp-developers mailing list > >>> Web...@li... > >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>> > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> Web-erp-developers mailing list > >> Web...@li... > >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Phil D. <ph...@lo...> - 2014-03-30 02:04:23
|
Probably not worth changing then... Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 30/03/14 14:38, Jon R wrote: > > Yes we could, the only reason it is structured like that is to make > updating Doctrine a simple copy-paste but it's not necessary > > On Mar 30, 2014 6:33 AM, "Phil Daintree" <ph...@lo... > <mailto:ph...@lo...>> wrote: > > Nice ... > > Just one thought ... do we need to have the > > > include/Doctrine/lib directories > > couldn't we just go > > include/Doctrine/Common > and > include/Doctrine/DBAL > > folders directly as the includes/Doctrine directory is empty and > the includes/Doctrine/lib is empty other than the Doctrine folder > just want to be able to get at the meat :-) > > Phil > > Phil Daintree > Logic Works Ltd -+64 (0)275 567890 <tel:%2B64%20%280%29275%20567890> > http://www.logicworks.co.nz > > On 28/03/14 20:38, Jon R wrote: >> If we use the Views classes TWIG can be implemented in a theme. I >> will post a proof of concept to the github site in the next day >> or so. >> ~serakfalcon >> >> /Sent from my iLaptop/ >> >> >> On Fri, Mar 28, 2014 at 3:33 PM, icedlava <ice...@gm... >> <mailto:ice...@gm...>> wrote: >> >> Hi Phil, >> >> > but have you written your ideal new function - named >> > other than DB_query - and where the parameter type is given >> explicitly >> > rather than inferred? Would be interested to see that >> >> Did you want me to put it in the new branch? >> >> > I am also rethinking the TableView class idea to eliminate the >> > <tr><td></td></tr> all over the place - >> >> I would support that - I think we have too much dependence on >> tables for >> layout generally in the themes and using divs would be better. >> >> I think we should think very carefully about what classes are >> used and >> needed in the 'table less' themes and try and keep them to a >> minimum. >> CSS allows us to do great things with minimal markup. >> >> I do believe that tables are still important for data views >> which is >> where their forte in use is. >> >> > We are of course looking it almost a complete re-write here! >> >> Sounds like it lol! I'm up for it :) >> >> We could do with a list of other things to do while we are at it. >> I guess TWIG is still out ? It maybe just me but I don't >> find the code >> easy to look at as it's mixed thoroughly with html output. >> I'd still like to separate it but understand this might be >> going too far >> right now :p >> >> Cheers, >> >> >> >> On 28 Mar 2014, at 17:34, Phil Daintree wrote: >> >> > Jo, >> > >> > I can find it now - but have you written your ideal new >> function - >> > named >> > other than DB_query - and where the parameter type is given >> explicitly >> > rather than inferred? Would be interested to see that... >> perhaps since >> > we are doing this we should jump right on in? >> > >> > I am also rethinking the TableView class idea to eliminate the >> > <tr><td></td></tr> all over the place - and perhaps maybe >> conversion >> > to >> > <div> with optional classes? that might more easily >> accommodate phones >> > etc. We are of course looking it almost a complete re-write >> here! >> > >> > Let's go :-) >> > >> > Phil >> > >> > Phil Daintree >> > Logic Works Ltd - +64 (0)275 567890 >> <tel:%2B64%20%280%29275%20567890> >> > http://www.logicworks.co.nz >> > >> > On 28/03/14 19:07, icedlava wrote: >> >> Hi Phil, >> >> >> >>> As you say, my revised DB_query() just escapes the >> parameters as >> >>> they >> >>> were previously - just that we have now moved the >> escaping to the >> >>> place >> >>> where it needs to happen rather than blanket escaping every >> >>> $_POST/$_GET >> >>> - so we are equally secure as we were ... unless I am >> wrong and >> >>> those >> >>> variables which should not be escaped are not escape >> >> Yes, exactly - we are equally secure as we were before for >> database >> >> transactions. >> >> As you say, the whole reason that this topic came up was >> due to >> >> non-contextual escaping of variables and the issues that >> has and is >> >> continuing to cause in the code/database. >> >> We have the opportunity now to fix it, but also improve >> the security >> >> of >> >> webERP as we fix the original variable problem, which is >> what I've >> >> tried to do with the version I committed. >> >> >> >> Thanks for your understanding! >> >> >> >> Cheers, >> >> >> >> >> >> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >> >> >> >>> Hi Jo, >> >>> >> >>> As you say, my revised DB_query() just escapes the >> parameters as >> >>> they >> >>> were previously - just that we have now moved the >> escaping to the >> >>> place >> >>> where it needs to happen rather than blanket escaping every >> >>> $_POST/$_GET >> >>> - so we are equally secure as we were ... unless I am >> wrong and >> >>> those >> >>> variables which should not be escaped are not escaped. >> >>> >> >>> That said, I will look into the full prepare execute >> method in more >> >>> detail. Of course with my blinkered vision what I did is more >> >>> readable >> >>> :-) I am persuaded by the argument to do things the most >> secure way >> >>> though given we are into a major re-write and I think >> this may be >> >>> the >> >>> full prepare/execute method you first suggested. >> >>> >> >>> Phil >> >>> >> >>> Phil Daintree >> >>> Logic Works Ltd - +64 (0)275 567890 >> <tel:%2B64%20%280%29275%20567890> >> >>> http://www.logicworks.co.nz >> >>> >> >>> On 28/03/14 16:45, icedlava wrote: >> >>>> Hi Phil, >> >>>> >> >>>> For reference here on the list, I have committed the code as >> >>>> requested. >> >>>> You have updated the original function I committed which >> changes >> >>>> and >> >>>> I >> >>>> did make a point to you in email that these changes will >> not work. >> >>>> >> >>>> As per your request I've forwarded your response to the >> mailing >> >>>> list >> >>>> but >> >>>> posting here for completeness in this thread. >> >>>> >> >>>> Note that the latest changes will not work because it is >> not the >> >>>> fact >> >>>> that the query is prepared, it is the fact the query is >> >>>> paramaterized >> >>>> that makes it secure. >> >>>> Parameterized queries, done in the way I did it work >> because the >> >>>> query >> >>>> string and the variables are sent separately to the >> database server >> >>>> and >> >>>> only there are put together. >> >>>> >> >>>> The changes you made are no different to the original >> DB_query that >> >>>> mysql_db_escapes the data - except there is more code >> and separated >> >>>> parameters. The key issue: >> >>>> >> >>>> In your new code: >> >>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >> >>>> different >> >>>> to >> >>>> prior old DB_query. >> >>>> >> >>>> The query is already 'put together' with query and >> variables before >> >>>> it >> >>>> goes to the server. That is the insecure nature of it >> and why I >> >>>> changed >> >>>> it. >> >>>> >> >>>> Appreciate your work and thought on it so far. >> >>>> >> >>>> Cheers, >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >> >>>> >> >>>>> I've made up a new branch so we can mess with this a bit >> >>>>> >> >>>>> svn checkout --username=XXXXX >> >>>>> >> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >> <http://XX...@sv.../p/web-erp/code/branches/working> >> >>>>> yourworkingcopy >> >>>>> >> >>>>> where XXXXX is your sourceforge login. >> >>>>> >> >>>>> Jo, if you commit the code you want for the new >> DB_query - and I >> >>>>> propose >> >>>>> we should keep it the same name - but with a new optional >> >>>>> parameter >> >>>>> for >> >>>>> the array of parameters. >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Phil >> >>>>> >> >>>>> Phil Daintree >> >>>>> Logic Works Ltd - +64 (0)275 567890 >> <tel:%2B64%20%280%29275%20567890> >> >>>>> http://www.logicworks.co.nz >> >>>>> >> >>>>> >> >>>>> >> ------------------------------------------------------------------------------ >> >>>>> Learn Graph Databases - Download FREE O'Reilly Book >> >>>>> "Graph Databases" is the definitive new guide to graph >> databases >> >>>>> and >> >>>>> their >> >>>>> applications. Written by three acclaimed leaders in the >> field, >> >>>>> this first edition is now available. Download your free >> book >> >>>>> today! >> >>>>> http://p.sf.net/sfu/13534_NeoTech >> >>>>> _______________________________________________ >> >>>>> Web-erp-developers mailing list >> >>>>> Web...@li... >> <mailto:Web...@li...> >> >>>>> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>>> >> ------------------------------------------------------------------------------ >> >>>> _______________________________________________ >> >>>> Web-erp-developers mailing list >> >>>> Web...@li... >> <mailto:Web...@li...> >> >>>> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> _______________________________________________ >> >>> Web-erp-developers mailing list >> >>> Web...@li... >> <mailto:Web...@li...> >> >>> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> >> Web-erp-developers mailing list >> >> Web...@li... >> <mailto:Web...@li...> >> >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> > >> > >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Web-erp-developers mailing list >> > Web...@li... >> <mailto:Web...@li...> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > <mailto:Web...@li...> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Jon R <jr...@gm...> - 2014-03-30 01:38:29
|
Yes we could, the only reason it is structured like that is to make updating Doctrine a simple copy-paste but it's not necessary On Mar 30, 2014 6:33 AM, "Phil Daintree" <ph...@lo...> wrote: > Nice ... > > Just one thought ... do we need to have the > > > include/Doctrine/lib directories > > couldn't we just go > > include/Doctrine/Common > and > include/Doctrine/DBAL > > folders directly as the includes/Doctrine directory is empty and the > includes/Doctrine/lib is empty other than the Doctrine folder just want to > be able to get at the meat :-) > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890http://www.logicworks.co.nz > > On 28/03/14 20:38, Jon R wrote: > > If we use the Views classes TWIG can be implemented in a theme. I will > post a proof of concept to the github site in the next day or so. > ~serakfalcon > > *Sent from my iLaptop* > > > On Fri, Mar 28, 2014 at 3:33 PM, icedlava <ice...@gm...> wrote: > >> Hi Phil, >> >> > but have you written your ideal new function - named >> > other than DB_query - and where the parameter type is given explicitly >> > rather than inferred? Would be interested to see that >> >> Did you want me to put it in the new branch? >> >> > I am also rethinking the TableView class idea to eliminate the >> > <tr><td></td></tr> all over the place - >> >> I would support that - I think we have too much dependence on tables for >> layout generally in the themes and using divs would be better. >> >> I think we should think very carefully about what classes are used and >> needed in the 'table less' themes and try and keep them to a minimum. >> CSS allows us to do great things with minimal markup. >> >> I do believe that tables are still important for data views which is >> where their forte in use is. >> >> > We are of course looking it almost a complete re-write here! >> >> Sounds like it lol! I'm up for it :) >> >> We could do with a list of other things to do while we are at it. >> I guess TWIG is still out ? It maybe just me but I don't find the code >> easy to look at as it's mixed thoroughly with html output. >> I'd still like to separate it but understand this might be going too far >> right now :p >> >> Cheers, >> >> >> >> On 28 Mar 2014, at 17:34, Phil Daintree wrote: >> >> > Jo, >> > >> > I can find it now - but have you written your ideal new function - >> > named >> > other than DB_query - and where the parameter type is given explicitly >> > rather than inferred? Would be interested to see that... perhaps since >> > we are doing this we should jump right on in? >> > >> > I am also rethinking the TableView class idea to eliminate the >> > <tr><td></td></tr> all over the place - and perhaps maybe conversion >> > to >> > <div> with optional classes? that might more easily accommodate phones >> > etc. We are of course looking it almost a complete re-write here! >> > >> > Let's go :-) >> > >> > Phil >> > >> > Phil Daintree >> > Logic Works Ltd - +64 (0)275 567890 >> > http://www.logicworks.co.nz >> > >> > On 28/03/14 19:07, icedlava wrote: >> >> Hi Phil, >> >> >> >>> As you say, my revised DB_query() just escapes the parameters as >> >>> they >> >>> were previously - just that we have now moved the escaping to the >> >>> place >> >>> where it needs to happen rather than blanket escaping every >> >>> $_POST/$_GET >> >>> - so we are equally secure as we were ... unless I am wrong and >> >>> those >> >>> variables which should not be escaped are not escape >> >> Yes, exactly - we are equally secure as we were before for database >> >> transactions. >> >> As you say, the whole reason that this topic came up was due to >> >> non-contextual escaping of variables and the issues that has and is >> >> continuing to cause in the code/database. >> >> We have the opportunity now to fix it, but also improve the security >> >> of >> >> webERP as we fix the original variable problem, which is what I've >> >> tried to do with the version I committed. >> >> >> >> Thanks for your understanding! >> >> >> >> Cheers, >> >> >> >> >> >> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >> >> >> >>> Hi Jo, >> >>> >> >>> As you say, my revised DB_query() just escapes the parameters as >> >>> they >> >>> were previously - just that we have now moved the escaping to the >> >>> place >> >>> where it needs to happen rather than blanket escaping every >> >>> $_POST/$_GET >> >>> - so we are equally secure as we were ... unless I am wrong and >> >>> those >> >>> variables which should not be escaped are not escaped. >> >>> >> >>> That said, I will look into the full prepare execute method in more >> >>> detail. Of course with my blinkered vision what I did is more >> >>> readable >> >>> :-) I am persuaded by the argument to do things the most secure way >> >>> though given we are into a major re-write and I think this may be >> >>> the >> >>> full prepare/execute method you first suggested. >> >>> >> >>> Phil >> >>> >> >>> Phil Daintree >> >>> Logic Works Ltd - +64 (0)275 567890 >> >>> http://www.logicworks.co.nz >> >>> >> >>> On 28/03/14 16:45, icedlava wrote: >> >>>> Hi Phil, >> >>>> >> >>>> For reference here on the list, I have committed the code as >> >>>> requested. >> >>>> You have updated the original function I committed which changes >> >>>> and >> >>>> I >> >>>> did make a point to you in email that these changes will not work. >> >>>> >> >>>> As per your request I've forwarded your response to the mailing >> >>>> list >> >>>> but >> >>>> posting here for completeness in this thread. >> >>>> >> >>>> Note that the latest changes will not work because it is not the >> >>>> fact >> >>>> that the query is prepared, it is the fact the query is >> >>>> paramaterized >> >>>> that makes it secure. >> >>>> Parameterized queries, done in the way I did it work because the >> >>>> query >> >>>> string and the variables are sent separately to the database server >> >>>> and >> >>>> only there are put together. >> >>>> >> >>>> The changes you made are no different to the original DB_query that >> >>>> mysql_db_escapes the data - except there is more code and separated >> >>>> parameters. The key issue: >> >>>> >> >>>> In your new code: >> >>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >> >>>> different >> >>>> to >> >>>> prior old DB_query. >> >>>> >> >>>> The query is already 'put together' with query and variables before >> >>>> it >> >>>> goes to the server. That is the insecure nature of it and why I >> >>>> changed >> >>>> it. >> >>>> >> >>>> Appreciate your work and thought on it so far. >> >>>> >> >>>> Cheers, >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >> >>>> >> >>>>> I've made up a new branch so we can mess with this a bit >> >>>>> >> >>>>> svn checkout --username=XXXXX >> >>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >> >>>>> yourworkingcopy >> >>>>> >> >>>>> where XXXXX is your sourceforge login. >> >>>>> >> >>>>> Jo, if you commit the code you want for the new DB_query - and I >> >>>>> propose >> >>>>> we should keep it the same name - but with a new optional >> >>>>> parameter >> >>>>> for >> >>>>> the array of parameters. >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Phil >> >>>>> >> >>>>> Phil Daintree >> >>>>> Logic Works Ltd - +64 (0)275 567890 >> >>>>> http://www.logicworks.co.nz >> >>>>> >> >>>>> >> >>>>> >> ------------------------------------------------------------------------------ >> >>>>> Learn Graph Databases - Download FREE O'Reilly Book >> >>>>> "Graph Databases" is the definitive new guide to graph databases >> >>>>> and >> >>>>> their >> >>>>> applications. Written by three acclaimed leaders in the field, >> >>>>> this first edition is now available. Download your free book >> >>>>> today! >> >>>>> http://p.sf.net/sfu/13534_NeoTech >> >>>>> _______________________________________________ >> >>>>> Web-erp-developers mailing list >> >>>>> Web...@li... >> >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>>> >> ------------------------------------------------------------------------------ >> >>>> _______________________________________________ >> >>>> Web-erp-developers mailing list >> >>>> Web...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >>>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> _______________________________________________ >> >>> Web-erp-developers mailing list >> >>> Web...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> >> Web-erp-developers mailing list >> >> Web...@li... >> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> > >> > >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Web-erp-developers mailing list >> > Web...@li... >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Web-erp-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > |
|
From: Phil D. <ph...@lo...> - 2014-03-29 22:32:56
|
Nice ... Just one thought ... do we need to have the include/Doctrine/lib directories couldn't we just go include/Doctrine/Common and include/Doctrine/DBAL folders directly as the includes/Doctrine directory is empty and the includes/Doctrine/lib is empty other than the Doctrine folder just want to be able to get at the meat :-) Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/03/14 20:38, Jon R wrote: > If we use the Views classes TWIG can be implemented in a theme. I will > post a proof of concept to the github site in the next day or so. > ~serakfalcon > > /Sent from my iLaptop/ > > > On Fri, Mar 28, 2014 at 3:33 PM, icedlava <ice...@gm... > <mailto:ice...@gm...>> wrote: > > Hi Phil, > > > but have you written your ideal new function - named > > other than DB_query - and where the parameter type is given > explicitly > > rather than inferred? Would be interested to see that > > Did you want me to put it in the new branch? > > > I am also rethinking the TableView class idea to eliminate the > > <tr><td></td></tr> all over the place - > > I would support that - I think we have too much dependence on > tables for > layout generally in the themes and using divs would be better. > > I think we should think very carefully about what classes are used and > needed in the 'table less' themes and try and keep them to a minimum. > CSS allows us to do great things with minimal markup. > > I do believe that tables are still important for data views which is > where their forte in use is. > > > We are of course looking it almost a complete re-write here! > > Sounds like it lol! I'm up for it :) > > We could do with a list of other things to do while we are at it. > I guess TWIG is still out ? It maybe just me but I don't find > the code > easy to look at as it's mixed thoroughly with html output. > I'd still like to separate it but understand this might be going > too far > right now :p > > Cheers, > > > > On 28 Mar 2014, at 17:34, Phil Daintree wrote: > > > Jo, > > > > I can find it now - but have you written your ideal new function - > > named > > other than DB_query - and where the parameter type is given > explicitly > > rather than inferred? Would be interested to see that... perhaps > since > > we are doing this we should jump right on in? > > > > I am also rethinking the TableView class idea to eliminate the > > <tr><td></td></tr> all over the place - and perhaps maybe conversion > > to > > <div> with optional classes? that might more easily accommodate > phones > > etc. We are of course looking it almost a complete re-write here! > > > > Let's go :-) > > > > Phil > > > > Phil Daintree > > Logic Works Ltd - +64 (0)275 567890 > <tel:%2B64%20%280%29275%20567890> > > http://www.logicworks.co.nz > > > > On 28/03/14 19:07, icedlava wrote: > >> Hi Phil, > >> > >>> As you say, my revised DB_query() just escapes the parameters as > >>> they > >>> were previously - just that we have now moved the escaping to the > >>> place > >>> where it needs to happen rather than blanket escaping every > >>> $_POST/$_GET > >>> - so we are equally secure as we were ... unless I am wrong and > >>> those > >>> variables which should not be escaped are not escape > >> Yes, exactly - we are equally secure as we were before for database > >> transactions. > >> As you say, the whole reason that this topic came up was due to > >> non-contextual escaping of variables and the issues that has and is > >> continuing to cause in the code/database. > >> We have the opportunity now to fix it, but also improve the > security > >> of > >> webERP as we fix the original variable problem, which is what I've > >> tried to do with the version I committed. > >> > >> Thanks for your understanding! > >> > >> Cheers, > >> > >> > >> On 28 Mar 2014, at 16:27, Phil Daintree wrote: > >> > >>> Hi Jo, > >>> > >>> As you say, my revised DB_query() just escapes the parameters as > >>> they > >>> were previously - just that we have now moved the escaping to the > >>> place > >>> where it needs to happen rather than blanket escaping every > >>> $_POST/$_GET > >>> - so we are equally secure as we were ... unless I am wrong and > >>> those > >>> variables which should not be escaped are not escaped. > >>> > >>> That said, I will look into the full prepare execute method in > more > >>> detail. Of course with my blinkered vision what I did is more > >>> readable > >>> :-) I am persuaded by the argument to do things the most > secure way > >>> though given we are into a major re-write and I think this may be > >>> the > >>> full prepare/execute method you first suggested. > >>> > >>> Phil > >>> > >>> Phil Daintree > >>> Logic Works Ltd - +64 (0)275 567890 > <tel:%2B64%20%280%29275%20567890> > >>> http://www.logicworks.co.nz > >>> > >>> On 28/03/14 16:45, icedlava wrote: > >>>> Hi Phil, > >>>> > >>>> For reference here on the list, I have committed the code as > >>>> requested. > >>>> You have updated the original function I committed which changes > >>>> and > >>>> I > >>>> did make a point to you in email that these changes will not > work. > >>>> > >>>> As per your request I've forwarded your response to the mailing > >>>> list > >>>> but > >>>> posting here for completeness in this thread. > >>>> > >>>> Note that the latest changes will not work because it is not the > >>>> fact > >>>> that the query is prepared, it is the fact the query is > >>>> paramaterized > >>>> that makes it secure. > >>>> Parameterized queries, done in the way I did it work because the > >>>> query > >>>> string and the variables are sent separately to the database > server > >>>> and > >>>> only there are put together. > >>>> > >>>> The changes you made are no different to the original > DB_query that > >>>> mysql_db_escapes the data - except there is more code and > separated > >>>> parameters. The key issue: > >>>> > >>>> In your new code: > >>>> $result=mysqli_query($Conn, $SQLString); is the problem. No > >>>> different > >>>> to > >>>> prior old DB_query. > >>>> > >>>> The query is already 'put together' with query and variables > before > >>>> it > >>>> goes to the server. That is the insecure nature of it and why I > >>>> changed > >>>> it. > >>>> > >>>> Appreciate your work and thought on it so far. > >>>> > >>>> Cheers, > >>>> > >>>> > >>>> > >>>> > >>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: > >>>> > >>>>> I've made up a new branch so we can mess with this a bit > >>>>> > >>>>> svn checkout --username=XXXXX > >>>>> > svn+ssh://XX...@sv.../p/web-erp/code/branches/working > <http://XX...@sv.../p/web-erp/code/branches/working> > >>>>> yourworkingcopy > >>>>> > >>>>> where XXXXX is your sourceforge login. > >>>>> > >>>>> Jo, if you commit the code you want for the new DB_query - and I > >>>>> propose > >>>>> we should keep it the same name - but with a new optional > >>>>> parameter > >>>>> for > >>>>> the array of parameters. > >>>>> > >>>>> > >>>>> -- > >>>>> Phil > >>>>> > >>>>> Phil Daintree > >>>>> Logic Works Ltd - +64 (0)275 567890 > <tel:%2B64%20%280%29275%20567890> > >>>>> http://www.logicworks.co.nz > >>>>> > >>>>> > >>>>> > ------------------------------------------------------------------------------ > >>>>> Learn Graph Databases - Download FREE O'Reilly Book > >>>>> "Graph Databases" is the definitive new guide to graph databases > >>>>> and > >>>>> their > >>>>> applications. Written by three acclaimed leaders in the field, > >>>>> this first edition is now available. Download your free book > >>>>> today! > >>>>> http://p.sf.net/sfu/13534_NeoTech > >>>>> _______________________________________________ > >>>>> Web-erp-developers mailing list > >>>>> Web...@li... > <mailto:Web...@li...> > >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>> > ------------------------------------------------------------------------------ > >>>> _______________________________________________ > >>>> Web-erp-developers mailing list > >>>> Web...@li... > <mailto:Web...@li...> > >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Web-erp-developers mailing list > >>> Web...@li... > <mailto:Web...@li...> > >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> Web-erp-developers mailing list > >> Web...@li... > <mailto:Web...@li...> > >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >> > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > <mailto:Web...@li...> > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > <mailto:Web...@li...> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Phil D. <ph...@lo...> - 2014-03-29 22:28:31
|
I had a go at removing the $Conn parameter and renaming the function DB_PreparedQuery() leaving the DB_query() function where it is - no reason why we can't continue to use it where there are no parameters involved I guess - as you suggested Jo... I messed with the style to try to bring the new code into line with the conventions we use and make the variable names a bit more meaningful - I hate abbreviated variable names that give you no clue as to what is going on... it is obvious when you write the code but 3 or 4 sleeps later not so obvious ... curly braces on the same line as the function call/if test etc etc. and of course predictably I have messed it up - login and AccounGroups.php no longer work :-( Hopefully though the concept is clear. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/03/14 20:42, icedlava wrote: > Phil, > > Can I commit TWIG to the new branch and a simple integration - existing > code will work as normal but it would provide somewhere to add twig > templates and themes for proof of concept or comparison? > > If it is not required, or wanted, it could be removed later. > > What do you think? > > > > On 28 Mar 2014, at 17:34, Phil Daintree wrote: > >> Jo, >> >> I can find it now - but have you written your ideal new function - >> named >> other than DB_query - and where the parameter type is given explicitly >> rather than inferred? Would be interested to see that... perhaps since >> we are doing this we should jump right on in? >> >> I am also rethinking the TableView class idea to eliminate the >> <tr><td></td></tr> all over the place - and perhaps maybe conversion >> to >> <div> with optional classes? that might more easily accommodate phones >> etc. We are of course looking it almost a complete re-write here! >> >> Let's go :-) >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890 >> http://www.logicworks.co.nz >> >> On 28/03/14 19:07, icedlava wrote: >>> Hi Phil, >>> >>>> As you say, my revised DB_query() just escapes the parameters as >>>> they >>>> were previously - just that we have now moved the escaping to the >>>> place >>>> where it needs to happen rather than blanket escaping every >>>> $_POST/$_GET >>>> - so we are equally secure as we were ... unless I am wrong and >>>> those >>>> variables which should not be escaped are not escape >>> Yes, exactly - we are equally secure as we were before for database >>> transactions. >>> As you say, the whole reason that this topic came up was due to >>> non-contextual escaping of variables and the issues that has and is >>> continuing to cause in the code/database. >>> We have the opportunity now to fix it, but also improve the security >>> of >>> webERP as we fix the original variable problem, which is what I've >>> tried to do with the version I committed. >>> >>> Thanks for your understanding! >>> >>> Cheers, >>> >>> >>> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >>> >>>> Hi Jo, >>>> >>>> As you say, my revised DB_query() just escapes the parameters as >>>> they >>>> were previously - just that we have now moved the escaping to the >>>> place >>>> where it needs to happen rather than blanket escaping every >>>> $_POST/$_GET >>>> - so we are equally secure as we were ... unless I am wrong and >>>> those >>>> variables which should not be escaped are not escaped. >>>> >>>> That said, I will look into the full prepare execute method in more >>>> detail. Of course with my blinkered vision what I did is more >>>> readable >>>> :-) I am persuaded by the argument to do things the most secure way >>>> though given we are into a major re-write and I think this may be >>>> the >>>> full prepare/execute method you first suggested. >>>> >>>> Phil >>>> >>>> Phil Daintree >>>> Logic Works Ltd - +64 (0)275 567890 >>>> http://www.logicworks.co.nz >>>> >>>> On 28/03/14 16:45, icedlava wrote: >>>>> Hi Phil, >>>>> >>>>> For reference here on the list, I have committed the code as >>>>> requested. >>>>> You have updated the original function I committed which changes >>>>> and >>>>> I >>>>> did make a point to you in email that these changes will not work. >>>>> >>>>> As per your request I've forwarded your response to the mailing >>>>> list >>>>> but >>>>> posting here for completeness in this thread. >>>>> >>>>> Note that the latest changes will not work because it is not the >>>>> fact >>>>> that the query is prepared, it is the fact the query is >>>>> paramaterized >>>>> that makes it secure. >>>>> Parameterized queries, done in the way I did it work because the >>>>> query >>>>> string and the variables are sent separately to the database server >>>>> and >>>>> only there are put together. >>>>> >>>>> The changes you made are no different to the original DB_query that >>>>> mysql_db_escapes the data - except there is more code and separated >>>>> parameters. The key issue: >>>>> >>>>> In your new code: >>>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >>>>> different >>>>> to >>>>> prior old DB_query. >>>>> >>>>> The query is already 'put together' with query and variables before >>>>> it >>>>> goes to the server. That is the insecure nature of it and why I >>>>> changed >>>>> it. >>>>> >>>>> Appreciate your work and thought on it so far. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> >>>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >>>>> >>>>>> I've made up a new branch so we can mess with this a bit >>>>>> >>>>>> svn checkout --username=XXXXX >>>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>>>>> yourworkingcopy >>>>>> >>>>>> where XXXXX is your sourceforge login. >>>>>> >>>>>> Jo, if you commit the code you want for the new DB_query - and I >>>>>> propose >>>>>> we should keep it the same name - but with a new optional >>>>>> parameter >>>>>> for >>>>>> the array of parameters. >>>>>> >>>>>> >>>>>> -- >>>>>> Phil >>>>>> >>>>>> Phil Daintree >>>>>> Logic Works Ltd - +64 (0)275 567890 >>>>>> http://www.logicworks.co.nz >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>>> "Graph Databases" is the definitive new guide to graph databases >>>>>> and >>>>>> their >>>>>> applications. Written by three acclaimed leaders in the field, >>>>>> this first edition is now available. Download your free book >>>>>> today! >>>>>> http://p.sf.net/sfu/13534_NeoTech >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Rafael C. <raf...@gm...> - 2014-03-28 23:30:24
|
Hi Phil. Thank you, very much. From what I could understand the code, I think it is what you indicate me. I'm not entirely sure, so I preferred to confirm. I'll make the fix. Best regards, Rafael. 2014-03-28 0:15 GMT-06:00 Phil Daintree <ph...@lo...>: > Hi Rafael, > > Well debtortranstaxes can have many tax amounts that accumulate to equal > the debtortrans.ovgst - the reason we have debtortranstaxes at all is > because of the requirement for multiple taxes in some authorities. > > I think debtortranstaxes stores the tax in local currency though not the > FX ... would need to check I may be wrong. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 28/03/14 03:14, Rafael Chacón wrote: >> Hi All, >> >> Any comments or suggestions? >> >> >> Best regards, Rafael. >> >> 2014-03-21 5:23 GMT-06:00 Rafael Chacón <raf...@gm...>: >>> Hi, >>> >>> In tax.php (line 46) we have: >>> >>> (debtortrans.ovamount+debtortrans.ovfreight)/debtortrans.rate AS netamount, >>> debtortrans.ovfreight/debtortrans.rate AS freightamount, >>> debtortranstaxes.taxamount/debtortrans.rate AS tax >>> >>> ***dividing by exchange rate*** >>> >>> but >>> In ConfirmDispatch_Invoice.php (line 830) we use: $SQL = "INSERT INTO >>> debtortranstaxes.taxamount VALUES ('" . $TaxAmount/$_SESSION['CurrencyRate'] >>> . "')"; >>> In ConfirmDispatch_Invoice.php (line 1615) we use: $SQL = "INSERT INTO >>> gltrans.amount VALUES ('" . >>> round((-$TaxAmount/$_SESSION['CurrencyRate']),$_SESSION['CompanyRecord']['decimalplaces']) >>> . "')"; >>> In CounterReturns.php (line 965) we use: $SQL = "INSERT INTO >>> debtortranstaxes.taxamount VALUES ('" . -$TaxAmount/$ExRate . "')"; >>> In CounterReturns.php (line 1428) we use: $SQL = "INSERT INTO gltrans.amount >>> VALUES ('" . ($TaxAmount/$ExRate) . "')"; >>> In CounterSales.php (line 1383) we use: $SQL = "INSERT INTO >>> debtortranstaxes.taxamount VALUES ('" . $TaxAmount/$ExRate . "')"; >>> In CounterSales.php (line 1885) we use: $SQL = "INSERT INTO gltrans.amount >>> VALUES ('" . (-$TaxAmount/$ExRate) . "')"; >>> In Credit_Invoice.php (line 644) we use: $SQL = "INSERT INTO >>> debtortranstaxes.taxamount VALUES ('" . >>> (-$TaxAmount/$_SESSION['CurrencyRate']) . "')"; >>> In RecurringSalesOrdersProcess.php (line 692) we use: $SQL = "INSERT INTO >>> debtortranstaxes.taxamount VALUES ('" . >>> filter_number_format($Tax['FXAmount']/$CurrencyRate) . "')"; >>> In SelectCreditItems.php (line 1178) we use: $SQL = "INSERT INTO >>> debtortranstaxes.taxamount VALUES ('" . >>> -$TaxAmount/$_SESSION['CurrencyRate'] . "')"; >>> In SupplierCredit.php (line 1158) we use: $SQL = "INSERT INTO >>> supptranstaxes.taxamount VALUES ('" . -$TaxTotals->TaxOvAmount . "')"; >>> In SupplierInvoice.php (1514) we use: $SQL = "INSERT INTO >>> supptranstaxes.taxamount VALUES ('" . $TaxTotals->TaxOvAmount . "')"; >>> >>> I guess it must be corrected to: >>> >>> (debtortrans.ovamount+debtortrans.ovfreight)/debtortrans.rate AS netamount, >>> debtortrans.ovfreight/debtortrans.rate AS freightamount, >>> debtortranstaxes.taxamount AS tax >>> >>> ***NOT dividing by exchange rate*** >>> >>> Also, I have also doubt to what it serves the field debtortrans.ovgst. What >>> is the difference between tax saved in debtortrans.ovgst and >>> debtortranstaxes.taxamount? Is it exchange rate? >>> >>> Best regards, Rafael Chacon. >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Phil D. <ph...@lo...> - 2014-03-28 08:33:46
|
OK why not... I have seen it before I think but would be interested in other views on this. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/03/14 20:42, icedlava wrote: > Phil, > > Can I commit TWIG to the new branch and a simple integration - existing > code will work as normal but it would provide somewhere to add twig > templates and themes for proof of concept or comparison? > > If it is not required, or wanted, it could be removed later. > > What do you think? > > > > On 28 Mar 2014, at 17:34, Phil Daintree wrote: > >> Jo, >> >> I can find it now - but have you written your ideal new function - >> named >> other than DB_query - and where the parameter type is given explicitly >> rather than inferred? Would be interested to see that... perhaps since >> we are doing this we should jump right on in? >> >> I am also rethinking the TableView class idea to eliminate the >> <tr><td></td></tr> all over the place - and perhaps maybe conversion >> to >> <div> with optional classes? that might more easily accommodate phones >> etc. We are of course looking it almost a complete re-write here! >> >> Let's go :-) >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890 >> http://www.logicworks.co.nz >> >> On 28/03/14 19:07, icedlava wrote: >>> Hi Phil, >>> >>>> As you say, my revised DB_query() just escapes the parameters as >>>> they >>>> were previously - just that we have now moved the escaping to the >>>> place >>>> where it needs to happen rather than blanket escaping every >>>> $_POST/$_GET >>>> - so we are equally secure as we were ... unless I am wrong and >>>> those >>>> variables which should not be escaped are not escape >>> Yes, exactly - we are equally secure as we were before for database >>> transactions. >>> As you say, the whole reason that this topic came up was due to >>> non-contextual escaping of variables and the issues that has and is >>> continuing to cause in the code/database. >>> We have the opportunity now to fix it, but also improve the security >>> of >>> webERP as we fix the original variable problem, which is what I've >>> tried to do with the version I committed. >>> >>> Thanks for your understanding! >>> >>> Cheers, >>> >>> >>> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >>> >>>> Hi Jo, >>>> >>>> As you say, my revised DB_query() just escapes the parameters as >>>> they >>>> were previously - just that we have now moved the escaping to the >>>> place >>>> where it needs to happen rather than blanket escaping every >>>> $_POST/$_GET >>>> - so we are equally secure as we were ... unless I am wrong and >>>> those >>>> variables which should not be escaped are not escaped. >>>> >>>> That said, I will look into the full prepare execute method in more >>>> detail. Of course with my blinkered vision what I did is more >>>> readable >>>> :-) I am persuaded by the argument to do things the most secure way >>>> though given we are into a major re-write and I think this may be >>>> the >>>> full prepare/execute method you first suggested. >>>> >>>> Phil >>>> >>>> Phil Daintree >>>> Logic Works Ltd - +64 (0)275 567890 >>>> http://www.logicworks.co.nz >>>> >>>> On 28/03/14 16:45, icedlava wrote: >>>>> Hi Phil, >>>>> >>>>> For reference here on the list, I have committed the code as >>>>> requested. >>>>> You have updated the original function I committed which changes >>>>> and >>>>> I >>>>> did make a point to you in email that these changes will not work. >>>>> >>>>> As per your request I've forwarded your response to the mailing >>>>> list >>>>> but >>>>> posting here for completeness in this thread. >>>>> >>>>> Note that the latest changes will not work because it is not the >>>>> fact >>>>> that the query is prepared, it is the fact the query is >>>>> paramaterized >>>>> that makes it secure. >>>>> Parameterized queries, done in the way I did it work because the >>>>> query >>>>> string and the variables are sent separately to the database server >>>>> and >>>>> only there are put together. >>>>> >>>>> The changes you made are no different to the original DB_query that >>>>> mysql_db_escapes the data - except there is more code and separated >>>>> parameters. The key issue: >>>>> >>>>> In your new code: >>>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >>>>> different >>>>> to >>>>> prior old DB_query. >>>>> >>>>> The query is already 'put together' with query and variables before >>>>> it >>>>> goes to the server. That is the insecure nature of it and why I >>>>> changed >>>>> it. >>>>> >>>>> Appreciate your work and thought on it so far. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> >>>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >>>>> >>>>>> I've made up a new branch so we can mess with this a bit >>>>>> >>>>>> svn checkout --username=XXXXX >>>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>>>>> yourworkingcopy >>>>>> >>>>>> where XXXXX is your sourceforge login. >>>>>> >>>>>> Jo, if you commit the code you want for the new DB_query - and I >>>>>> propose >>>>>> we should keep it the same name - but with a new optional >>>>>> parameter >>>>>> for >>>>>> the array of parameters. >>>>>> >>>>>> >>>>>> -- >>>>>> Phil >>>>>> >>>>>> Phil Daintree >>>>>> Logic Works Ltd - +64 (0)275 567890 >>>>>> http://www.logicworks.co.nz >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>>> "Graph Databases" is the definitive new guide to graph databases >>>>>> and >>>>>> their >>>>>> applications. Written by three acclaimed leaders in the field, >>>>>> this first edition is now available. Download your free book >>>>>> today! >>>>>> http://p.sf.net/sfu/13534_NeoTech >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Jon R <jr...@gm...> - 2014-03-28 08:12:58
|
sorry, gmail keeps switching to my work email *Sent from my iLaptop* On Fri, Mar 28, 2014 at 4:11 PM, Jonathan (Thành) <th...@ic...>wrote: > I finished ConnectDB_dbal but can't commit it. > > > On Fri, Mar 28, 2014 at 3:45 PM, Phil Daintree <ph...@lo...>wrote: > >> Yes please re perfect parameterized query function and maybe >> AccountGroups.php reworked >> I think twig undermines the readability. >> >> On 28 March 2014 8:33:35 PM NZDT, icedlava <ice...@gm...> wrote: >> >>> Hi Phil, >>> >>> but have you written your ideal new function - named >>>> other than DB_query - and where the parameter type is given explicitly >>>> >>>> >>>> rather than inferred? Would be interested to see that >>>> >>> >>> Did you want me to put it in the new branch? >>> >>> >>>> >>>> I am also rethinking the TableView class idea to eliminate the >>>> <tr><td></td></tr> all over the place - >>>> >>> >>> I would support that - I think we have too much dependence on tables for >>> >>> >>> layout generally in the themes and using divs would be better. >>> >>> I think we should think very carefully about what classes are used and >>> needed in the 'table less' themes and try and keep them to a >>> minimum. >>> CSS allows us to do great things with minimal markup. >>> >>> I do believe that tables are still important for data views which is >>> where their forte in use is. >>> >>> >>>> >>>> We are of course looking it almost a complete re-write here! >>>> >>> >>> Sounds like it lol! I'm up for it :) >>> >>> We could do with a list of other things to do while we are at it. >>> I guess TWIG is still out ? It maybe just me but I don't find the code >>> >>> >>> easy to look at as it's mixed thoroughly with html output. >>> I'd still like to separate it but understand this might be going too far >>> right now :p >>> >>> Cheers, >>> >>> >>> >>> On 28 Mar 2014, at 17:34, Phil Daintree wrote: >>> >>> >>> Jo, >>>> >>>> I can >>>> find it now - but have you written your ideal new function - >>>> named >>>> other than DB_query - and where the parameter type is given explicitly >>>> rather than inferred? Would be interested to see that... perhaps since >>>> >>>> >>>> we are doing this we should jump right on in? >>>> >>>> I am also rethinking the TableView class idea to eliminate the >>>> <tr><td></td></tr> all over the place - and perhaps maybe conversion >>>> to >>>> >>>> >>>> <div> with optional classes? that might more easily accommodate phones >>>> etc. We are of course looking it almost a complete re-write here! >>>> >>>> Let's go :-) >>>> >>>> Phil >>>> >>>> Phil Daintree >>>> Logic Works Ltd - +64 (0)275 567890 >>>> >>>> >>>> http://www.logicworks.co.nz >>>> >>>> On 28/03/14 19:07, icedlava wrote: >>>> >>>>> >>>>> Hi Phil, >>>>> >>>>> As you say, my revised DB_query() just escapes the parameters as >>>>>> they >>>>>> >>>>>> were previously - just that we have now moved the escaping to the >>>>>> place >>>>>> where it needs to happen rather than blanket escaping every >>>>>> $_POST/$_GET >>>>>> - so we are equally secure as we were ... unless I am wrong and >>>>>> >>>>>> >>>>>> those >>>>>> variables which should not be escaped are not escape >>>>>> >>>>> Yes, exactly - we are equally secure as we were before for database >>>>> transactions. >>>>> As you say, the whole reason that this topic came up was due to >>>>> >>>>> >>>>> non-contextual escaping of variables and the issues that has and is >>>>> continuing to cause in the code/database. >>>>> We have the opportunity now to fix it, but also improve the security >>>>> of >>>>> webERP as we fix the original variable problem, which is what I've >>>>> >>>>> >>>>> tried to do with the >>>>> version I committed. >>>>> >>>>> Thanks for your understanding! >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >>>>> >>>>> >>>>>> Hi Jo, >>>>>> >>>>>> As you say, my revised DB_query() just escapes the parameters as >>>>>> they >>>>>> were previously - just that we have now moved the escaping to the >>>>>> place >>>>>> where it needs to happen rather than blanket escaping every >>>>>> >>>>>> >>>>>> $_POST/$_GET >>>>>> - so we are equally secure as we were ... unless I am wrong and >>>>>> those >>>>>> variables which should not be escaped are not escaped. >>>>>> >>>>>> That said, I will look into the full prepare execute method in more >>>>>> >>>>>> >>>>>> detail. Of course with my blinkered vision what I did is more >>>>>> readable >>>>>> :-) I am persuaded by the argument to do things the most secure way >>>>>> though given we are into a major re-write and I think this may be >>>>>> the >>>>>> full prepare/execute method you first suggested. >>>>>> >>>>>> Phil >>>>>> >>>>>> Phil Daintree >>>>>> Logic Works Ltd - +64 (0)275 567890 >>>>>> >>>>>> >>>>>> http://www.logicworks.co.nz >>>>>> >>>>>> On 28/03/14 16:45, icedlava wrote: >>>>>> >>>>>>> >>>>>>> Hi Phil, >>>>>>> >>>>>>> For reference here on the list, I have committed the code as >>>>>>> requested. >>>>>>> You have updated the original function I committed which changes >>>>>>> and >>>>>>> I >>>>>>> did make a point to you in email that these changes will not work. >>>>>>> >>>>>>> >>>>>>> As per your request I've forwarded your response to the mailing >>>>>>> list >>>>>>> but >>>>>>> posting here for completeness in this thread. >>>>>>> >>>>>>> Note that the latest changes will not work because it is not the >>>>>>> fact >>>>>>> >>>>>>> >>>>>>> that the query is prepared, it is the fact the query is >>>>>>> paramaterized >>>>>>> that >>>>>>> makes it secure. >>>>>>> Parameterized queries, done in the way I did it work because the >>>>>>> query >>>>>>> string and the variables are sent separately to the database server >>>>>>> and >>>>>>> only there are put together. >>>>>>> >>>>>>> The changes you made are no different to the original DB_query that >>>>>>> >>>>>>> >>>>>>> mysql_db_escapes the data - except there is more code and separated >>>>>>> parameters. The key issue: >>>>>>> >>>>>>> In your new code: >>>>>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >>>>>>> different >>>>>>> to >>>>>>> prior old DB_query. >>>>>>> >>>>>>> >>>>>>> The query is already 'put together' with query and variables before >>>>>>> it >>>>>>> goes to the server. That is the insecure nature of it and why I >>>>>>> changed >>>>>>> it. >>>>>>> >>>>>>> Appreciate your work and thought on it so far. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I've made up a new branch so we can mess with this a bit >>>>>>>> >>>>>>>> svn checkout --username=XXXXX >>>>>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>>>>>>> >>>>>>>> >>>>>>>> yourworkingcopy >>>>>>>> >>>>>>>> where XXXXX is your sourceforge login. >>>>>>>> >>>>>>>> Jo, if you commit the code you want for the new DB_query - and I >>>>>>>> propose >>>>>>>> we should keep it the same name - but with a new optional >>>>>>>> parameter >>>>>>>> >>>>>>>> >>>>>>>> for >>>>>>>> the array of parameters. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Phil >>>>>>>> >>>>>>>> Phil Daintree >>>>>>>> Logic Works Ltd - +64 (0)275 567890 >>>>>>>> http://www.logicworks.co.nz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>>>>> "Graph Databases" is the definitive new guide to graph databases >>>>>>>> and >>>>>>>> their >>>>>>>> applications. Written by three acclaimed leaders in the field, >>>>>>>> >>>>>>>> >>>>>>>> this first edition is now available. Download your free book >>>>>>>> today! >>>>>>>> http://p.sf.net/sfu/13534_NeoTech >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> Web-erp-developers mailing list >>>>>>>> >>>>>>>> >>>>>>>> Web...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>>> >>>>>>>> ------------------------------ >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> Web-erp-developers mailing list >>>>>>> Web...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>> >>>>>> ------------------------------ >>>>> >>>>> ------------------------------ >>>>> >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> ------------------------------ >>>> >>>> Web-erp-developers mailing list >>>> >>>> >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>>> >>> ------------------------------ >>> >>> ------------------------------ >>> >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >>> >> Phil Daintree >> +64(0)275 567890 >> skype: daintree >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> > |
|
From: Jonathan (T. <th...@ic...> - 2014-03-28 08:12:05
|
I finished ConnectDB_dbal but can't commit it. On Fri, Mar 28, 2014 at 3:45 PM, Phil Daintree <ph...@lo...>wrote: > Yes please re perfect parameterized query function and maybe > AccountGroups.php reworked > I think twig undermines the readability. > > On 28 March 2014 8:33:35 PM NZDT, icedlava <ice...@gm...> wrote: > >> Hi Phil, >> >> but have you written your ideal new function - named >>> other than DB_query - and where the parameter type is given explicitly >>> rather than inferred? Would be interested to see that >>> >> >> Did you want me to put it in the new branch? >> >> I am also rethinking the TableView class idea to eliminate the >>> <tr><td></td></tr> all over the place - >>> >> >> I would support that - I think we have too much dependence on tables for >> layout generally in the themes and using divs would be better. >> >> I think we should think very carefully about what classes are used and >> needed in the 'table less' themes and try and keep them to a >> minimum. >> CSS allows us to do great things with minimal markup. >> >> I do believe that tables are still important for data views which is >> where their forte in use is. >> >> We are of course looking it almost a complete re-write here! >>> >> >> Sounds like it lol! I'm up for it :) >> >> We could do with a list of other things to do while we are at it. >> I guess TWIG is still out ? It maybe just me but I don't find the code >> easy to look at as it's mixed thoroughly with html output. >> I'd still like to separate it but understand this might be going too far >> right now :p >> >> Cheers, >> >> >> >> On 28 Mar 2014, at 17:34, Phil Daintree wrote: >> >> Jo, >>> >>> I can >>> find it now - but have you written your ideal new function - >>> named >>> other than DB_query - and where the parameter type is given explicitly >>> rather than inferred? Would be interested to see that... perhaps since >>> we are doing this we should jump right on in? >>> >>> I am also rethinking the TableView class idea to eliminate the >>> <tr><td></td></tr> all over the place - and perhaps maybe conversion >>> to >>> <div> with optional classes? that might more easily accommodate phones >>> etc. We are of course looking it almost a complete re-write here! >>> >>> Let's go :-) >>> >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd - +64 (0)275 567890 >>> http://www.logicworks.co.nz >>> >>> On 28/03/14 19:07, icedlava wrote: >>> >>>> Hi Phil, >>>> >>>> As you say, my revised DB_query() just escapes the parameters as >>>>> they >>>>> were previously - just that we have now moved the escaping to the >>>>> place >>>>> where it needs to happen rather than blanket escaping every >>>>> $_POST/$_GET >>>>> - so we are equally secure as we were ... unless I am wrong and >>>>> those >>>>> variables which should not be escaped are not escape >>>>> >>>> Yes, exactly - we are equally secure as we were before for database >>>> transactions. >>>> As you say, the whole reason that this topic came up was due to >>>> non-contextual escaping of variables and the issues that has and is >>>> continuing to cause in the code/database. >>>> We have the opportunity now to fix it, but also improve the security >>>> of >>>> webERP as we fix the original variable problem, which is what I've >>>> tried to do with the >>>> version I committed. >>>> >>>> Thanks for your understanding! >>>> >>>> Cheers, >>>> >>>> >>>> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >>>> >>>> Hi Jo, >>>>> >>>>> As you say, my revised DB_query() just escapes the parameters as >>>>> they >>>>> were previously - just that we have now moved the escaping to the >>>>> place >>>>> where it needs to happen rather than blanket escaping every >>>>> $_POST/$_GET >>>>> - so we are equally secure as we were ... unless I am wrong and >>>>> those >>>>> variables which should not be escaped are not escaped. >>>>> >>>>> That said, I will look into the full prepare execute method in more >>>>> detail. Of course with my blinkered vision what I did is more >>>>> readable >>>>> :-) I am persuaded by the argument to do things the most secure way >>>>> though given we are into a major re-write and I think this may be >>>>> the >>>>> full prepare/execute method you first suggested. >>>>> >>>>> Phil >>>>> >>>>> Phil Daintree >>>>> Logic Works Ltd - +64 (0)275 567890 >>>>> http://www.logicworks.co.nz >>>>> >>>>> On 28/03/14 16:45, icedlava wrote: >>>>> >>>>>> Hi Phil, >>>>>> >>>>>> For reference here on the list, I have committed the code as >>>>>> requested. >>>>>> You have updated the original function I committed which changes >>>>>> and >>>>>> I >>>>>> did make a point to you in email that these changes will not work. >>>>>> >>>>>> As per your request I've forwarded your response to the mailing >>>>>> list >>>>>> but >>>>>> posting here for completeness in this thread. >>>>>> >>>>>> Note that the latest changes will not work because it is not the >>>>>> fact >>>>>> that the query is prepared, it is the fact the query is >>>>>> paramaterized >>>>>> that >>>>>> makes it secure. >>>>>> Parameterized queries, done in the way I did it work because the >>>>>> query >>>>>> string and the variables are sent separately to the database server >>>>>> and >>>>>> only there are put together. >>>>>> >>>>>> The changes you made are no different to the original DB_query that >>>>>> mysql_db_escapes the data - except there is more code and separated >>>>>> parameters. The key issue: >>>>>> >>>>>> In your new code: >>>>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >>>>>> different >>>>>> to >>>>>> prior old DB_query. >>>>>> >>>>>> The query is already 'put together' with query and variables before >>>>>> it >>>>>> goes to the server. That is the insecure nature of it and why I >>>>>> changed >>>>>> it. >>>>>> >>>>>> Appreciate your work and thought on it so far. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >>>>>> >>>>>> I've made up a new branch so we can mess with this a bit >>>>>>> >>>>>>> svn checkout --username=XXXXX >>>>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>>>>>> yourworkingcopy >>>>>>> >>>>>>> where XXXXX is your sourceforge login. >>>>>>> >>>>>>> Jo, if you commit the code you want for the new DB_query - and I >>>>>>> propose >>>>>>> we should keep it the same name - but with a new optional >>>>>>> parameter >>>>>>> for >>>>>>> the array of parameters. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Phil >>>>>>> >>>>>>> Phil Daintree >>>>>>> Logic Works Ltd - +64 (0)275 567890 >>>>>>> http://www.logicworks.co.nz >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>>>> "Graph Databases" is the definitive new guide to graph databases >>>>>>> and >>>>>>> their >>>>>>> applications. Written by three acclaimed leaders in the field, >>>>>>> this first edition is now available. Download your free book >>>>>>> today! >>>>>>> http://p.sf.net/sfu/13534_NeoTech >>>>>>> ------------------------------ >>>>>>> >>>>>>> Web-erp-developers mailing list >>>>>>> Web...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> ------------------------------ >>>>> >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>> ------------------------------ >>>> >>>> ------------------------------ >>>> >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>> >>> >>> >>> ------------------------------ >>> >>> ------------------------------ >>> >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >> >> ------------------------------ >> >> ------------------------------ >> >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> > Phil Daintree > +64(0)275 567890 > skype: daintree > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > |
|
From: Phil D. <ph...@lo...> - 2014-03-28 07:46:04
|
Yes please re perfect parameterized query function and maybe AccountGroups.php reworked I think twig undermines the readability. On 28 March 2014 8:33:35 PM NZDT, icedlava <ice...@gm...> wrote: >Hi Phil, > >> but have you written your ideal new function - named >> other than DB_query - and where the parameter type is given >explicitly >> rather than inferred? Would be interested to see that > >Did you want me to put it in the new branch? > >> I am also rethinking the TableView class idea to eliminate the >> <tr><td></td></tr> all over the place - > >I would support that - I think we have too much dependence on tables >for >layout generally in the themes and using divs would be better. > >I think we should think very carefully about what classes are used and >needed in the 'table less' themes and try and keep them to a minimum. >CSS allows us to do great things with minimal markup. > >I do believe that tables are still important for data views which is >where their forte in use is. > >> We are of course looking it almost a complete re-write here! > >Sounds like it lol! I'm up for it :) > >We could do with a list of other things to do while we are at it. >I guess TWIG is still out ? It maybe just me but I don't find the >code >easy to look at as it's mixed thoroughly with html output. >I'd still like to separate it but understand this might be going too >far >right now :p > >Cheers, > > > >On 28 Mar 2014, at 17:34, Phil Daintree wrote: > >> Jo, >> >> I can find it now - but have you written your ideal new function - >> named >> other than DB_query - and where the parameter type is given >explicitly >> rather than inferred? Would be interested to see that... perhaps >since >> we are doing this we should jump right on in? >> >> I am also rethinking the TableView class idea to eliminate the >> <tr><td></td></tr> all over the place - and perhaps maybe conversion >> to >> <div> with optional classes? that might more easily accommodate >phones >> etc. We are of course looking it almost a complete re-write here! >> >> Let's go :-) >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890 >> http://www.logicworks.co.nz >> >> On 28/03/14 19:07, icedlava wrote: >>> Hi Phil, >>> >>>> As you say, my revised DB_query() just escapes the parameters as >>>> they >>>> were previously - just that we have now moved the escaping to the >>>> place >>>> where it needs to happen rather than blanket escaping every >>>> $_POST/$_GET >>>> - so we are equally secure as we were ... unless I am wrong and >>>> those >>>> variables which should not be escaped are not escape >>> Yes, exactly - we are equally secure as we were before for database >>> transactions. >>> As you say, the whole reason that this topic came up was due to >>> non-contextual escaping of variables and the issues that has and is >>> continuing to cause in the code/database. >>> We have the opportunity now to fix it, but also improve the security > >>> of >>> webERP as we fix the original variable problem, which is what I've >>> tried to do with the version I committed. >>> >>> Thanks for your understanding! >>> >>> Cheers, >>> >>> >>> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >>> >>>> Hi Jo, >>>> >>>> As you say, my revised DB_query() just escapes the parameters as >>>> they >>>> were previously - just that we have now moved the escaping to the >>>> place >>>> where it needs to happen rather than blanket escaping every >>>> $_POST/$_GET >>>> - so we are equally secure as we were ... unless I am wrong and >>>> those >>>> variables which should not be escaped are not escaped. >>>> >>>> That said, I will look into the full prepare execute method in more >>>> detail. Of course with my blinkered vision what I did is more >>>> readable >>>> :-) I am persuaded by the argument to do things the most secure way >>>> though given we are into a major re-write and I think this may be >>>> the >>>> full prepare/execute method you first suggested. >>>> >>>> Phil >>>> >>>> Phil Daintree >>>> Logic Works Ltd - +64 (0)275 567890 >>>> http://www.logicworks.co.nz >>>> >>>> On 28/03/14 16:45, icedlava wrote: >>>>> Hi Phil, >>>>> >>>>> For reference here on the list, I have committed the code as >>>>> requested. >>>>> You have updated the original function I committed which changes >>>>> and >>>>> I >>>>> did make a point to you in email that these changes will not work. >>>>> >>>>> As per your request I've forwarded your response to the mailing >>>>> list >>>>> but >>>>> posting here for completeness in this thread. >>>>> >>>>> Note that the latest changes will not work because it is not the >>>>> fact >>>>> that the query is prepared, it is the fact the query is >>>>> paramaterized >>>>> that makes it secure. >>>>> Parameterized queries, done in the way I did it work because the >>>>> query >>>>> string and the variables are sent separately to the database >server >>>>> and >>>>> only there are put together. >>>>> >>>>> The changes you made are no different to the original DB_query >that >>>>> mysql_db_escapes the data - except there is more code and >separated >>>>> parameters. The key issue: >>>>> >>>>> In your new code: >>>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >>>>> different >>>>> to >>>>> prior old DB_query. >>>>> >>>>> The query is already 'put together' with query and variables >before >>>>> it >>>>> goes to the server. That is the insecure nature of it and why I >>>>> changed >>>>> it. >>>>> >>>>> Appreciate your work and thought on it so far. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> >>>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >>>>> >>>>>> I've made up a new branch so we can mess with this a bit >>>>>> >>>>>> svn checkout --username=XXXXX >>>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>>>>> yourworkingcopy >>>>>> >>>>>> where XXXXX is your sourceforge login. >>>>>> >>>>>> Jo, if you commit the code you want for the new DB_query - and I >>>>>> propose >>>>>> we should keep it the same name - but with a new optional >>>>>> parameter >>>>>> for >>>>>> the array of parameters. >>>>>> >>>>>> >>>>>> -- >>>>>> Phil >>>>>> >>>>>> Phil Daintree >>>>>> Logic Works Ltd - +64 (0)275 567890 >>>>>> http://www.logicworks.co.nz >>>>>> >>>>>> >>>>>> >------------------------------------------------------------------------------ >>>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>>> "Graph Databases" is the definitive new guide to graph databases >>>>>> and >>>>>> their >>>>>> applications. Written by three acclaimed leaders in the field, >>>>>> this first edition is now available. Download your free book >>>>>> today! >>>>>> http://p.sf.net/sfu/13534_NeoTech >>>>>> _______________________________________________ >>>>>> Web-erp-developers mailing list >>>>>> Web...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>>> >>>> >>>> >------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >------------------------------------------------------------------------------ >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >> >> >> >------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >------------------------------------------------------------------------------ >_______________________________________________ >Web-erp-developers mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/web-erp-developers Phil Daintree +64(0)275 567890 skype: daintree |
|
From: icedlava <ice...@gm...> - 2014-03-28 07:43:06
|
Phil, Can I commit TWIG to the new branch and a simple integration - existing code will work as normal but it would provide somewhere to add twig templates and themes for proof of concept or comparison? If it is not required, or wanted, it could be removed later. What do you think? On 28 Mar 2014, at 17:34, Phil Daintree wrote: > Jo, > > I can find it now - but have you written your ideal new function - > named > other than DB_query - and where the parameter type is given explicitly > rather than inferred? Would be interested to see that... perhaps since > we are doing this we should jump right on in? > > I am also rethinking the TableView class idea to eliminate the > <tr><td></td></tr> all over the place - and perhaps maybe conversion > to > <div> with optional classes? that might more easily accommodate phones > etc. We are of course looking it almost a complete re-write here! > > Let's go :-) > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 28/03/14 19:07, icedlava wrote: >> Hi Phil, >> >>> As you say, my revised DB_query() just escapes the parameters as >>> they >>> were previously - just that we have now moved the escaping to the >>> place >>> where it needs to happen rather than blanket escaping every >>> $_POST/$_GET >>> - so we are equally secure as we were ... unless I am wrong and >>> those >>> variables which should not be escaped are not escape >> Yes, exactly - we are equally secure as we were before for database >> transactions. >> As you say, the whole reason that this topic came up was due to >> non-contextual escaping of variables and the issues that has and is >> continuing to cause in the code/database. >> We have the opportunity now to fix it, but also improve the security >> of >> webERP as we fix the original variable problem, which is what I've >> tried to do with the version I committed. >> >> Thanks for your understanding! >> >> Cheers, >> >> >> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >> >>> Hi Jo, >>> >>> As you say, my revised DB_query() just escapes the parameters as >>> they >>> were previously - just that we have now moved the escaping to the >>> place >>> where it needs to happen rather than blanket escaping every >>> $_POST/$_GET >>> - so we are equally secure as we were ... unless I am wrong and >>> those >>> variables which should not be escaped are not escaped. >>> >>> That said, I will look into the full prepare execute method in more >>> detail. Of course with my blinkered vision what I did is more >>> readable >>> :-) I am persuaded by the argument to do things the most secure way >>> though given we are into a major re-write and I think this may be >>> the >>> full prepare/execute method you first suggested. >>> >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd - +64 (0)275 567890 >>> http://www.logicworks.co.nz >>> >>> On 28/03/14 16:45, icedlava wrote: >>>> Hi Phil, >>>> >>>> For reference here on the list, I have committed the code as >>>> requested. >>>> You have updated the original function I committed which changes >>>> and >>>> I >>>> did make a point to you in email that these changes will not work. >>>> >>>> As per your request I've forwarded your response to the mailing >>>> list >>>> but >>>> posting here for completeness in this thread. >>>> >>>> Note that the latest changes will not work because it is not the >>>> fact >>>> that the query is prepared, it is the fact the query is >>>> paramaterized >>>> that makes it secure. >>>> Parameterized queries, done in the way I did it work because the >>>> query >>>> string and the variables are sent separately to the database server >>>> and >>>> only there are put together. >>>> >>>> The changes you made are no different to the original DB_query that >>>> mysql_db_escapes the data - except there is more code and separated >>>> parameters. The key issue: >>>> >>>> In your new code: >>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >>>> different >>>> to >>>> prior old DB_query. >>>> >>>> The query is already 'put together' with query and variables before >>>> it >>>> goes to the server. That is the insecure nature of it and why I >>>> changed >>>> it. >>>> >>>> Appreciate your work and thought on it so far. >>>> >>>> Cheers, >>>> >>>> >>>> >>>> >>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >>>> >>>>> I've made up a new branch so we can mess with this a bit >>>>> >>>>> svn checkout --username=XXXXX >>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>>>> yourworkingcopy >>>>> >>>>> where XXXXX is your sourceforge login. >>>>> >>>>> Jo, if you commit the code you want for the new DB_query - and I >>>>> propose >>>>> we should keep it the same name - but with a new optional >>>>> parameter >>>>> for >>>>> the array of parameters. >>>>> >>>>> >>>>> -- >>>>> Phil >>>>> >>>>> Phil Daintree >>>>> Logic Works Ltd - +64 (0)275 567890 >>>>> http://www.logicworks.co.nz >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>> "Graph Databases" is the definitive new guide to graph databases >>>>> and >>>>> their >>>>> applications. Written by three acclaimed leaders in the field, >>>>> this first edition is now available. Download your free book >>>>> today! >>>>> http://p.sf.net/sfu/13534_NeoTech >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Jon R <jr...@gm...> - 2014-03-28 07:38:09
|
If we use the Views classes TWIG can be implemented in a theme. I will post a proof of concept to the github site in the next day or so. ~serakfalcon *Sent from my iLaptop* On Fri, Mar 28, 2014 at 3:33 PM, icedlava <ice...@gm...> wrote: > Hi Phil, > > > but have you written your ideal new function - named > > other than DB_query - and where the parameter type is given explicitly > > rather than inferred? Would be interested to see that > > Did you want me to put it in the new branch? > > > I am also rethinking the TableView class idea to eliminate the > > <tr><td></td></tr> all over the place - > > I would support that - I think we have too much dependence on tables for > layout generally in the themes and using divs would be better. > > I think we should think very carefully about what classes are used and > needed in the 'table less' themes and try and keep them to a minimum. > CSS allows us to do great things with minimal markup. > > I do believe that tables are still important for data views which is > where their forte in use is. > > > We are of course looking it almost a complete re-write here! > > Sounds like it lol! I'm up for it :) > > We could do with a list of other things to do while we are at it. > I guess TWIG is still out ? It maybe just me but I don't find the code > easy to look at as it's mixed thoroughly with html output. > I'd still like to separate it but understand this might be going too far > right now :p > > Cheers, > > > > On 28 Mar 2014, at 17:34, Phil Daintree wrote: > > > Jo, > > > > I can find it now - but have you written your ideal new function - > > named > > other than DB_query - and where the parameter type is given explicitly > > rather than inferred? Would be interested to see that... perhaps since > > we are doing this we should jump right on in? > > > > I am also rethinking the TableView class idea to eliminate the > > <tr><td></td></tr> all over the place - and perhaps maybe conversion > > to > > <div> with optional classes? that might more easily accommodate phones > > etc. We are of course looking it almost a complete re-write here! > > > > Let's go :-) > > > > Phil > > > > Phil Daintree > > Logic Works Ltd - +64 (0)275 567890 > > http://www.logicworks.co.nz > > > > On 28/03/14 19:07, icedlava wrote: > >> Hi Phil, > >> > >>> As you say, my revised DB_query() just escapes the parameters as > >>> they > >>> were previously - just that we have now moved the escaping to the > >>> place > >>> where it needs to happen rather than blanket escaping every > >>> $_POST/$_GET > >>> - so we are equally secure as we were ... unless I am wrong and > >>> those > >>> variables which should not be escaped are not escape > >> Yes, exactly - we are equally secure as we were before for database > >> transactions. > >> As you say, the whole reason that this topic came up was due to > >> non-contextual escaping of variables and the issues that has and is > >> continuing to cause in the code/database. > >> We have the opportunity now to fix it, but also improve the security > >> of > >> webERP as we fix the original variable problem, which is what I've > >> tried to do with the version I committed. > >> > >> Thanks for your understanding! > >> > >> Cheers, > >> > >> > >> On 28 Mar 2014, at 16:27, Phil Daintree wrote: > >> > >>> Hi Jo, > >>> > >>> As you say, my revised DB_query() just escapes the parameters as > >>> they > >>> were previously - just that we have now moved the escaping to the > >>> place > >>> where it needs to happen rather than blanket escaping every > >>> $_POST/$_GET > >>> - so we are equally secure as we were ... unless I am wrong and > >>> those > >>> variables which should not be escaped are not escaped. > >>> > >>> That said, I will look into the full prepare execute method in more > >>> detail. Of course with my blinkered vision what I did is more > >>> readable > >>> :-) I am persuaded by the argument to do things the most secure way > >>> though given we are into a major re-write and I think this may be > >>> the > >>> full prepare/execute method you first suggested. > >>> > >>> Phil > >>> > >>> Phil Daintree > >>> Logic Works Ltd - +64 (0)275 567890 > >>> http://www.logicworks.co.nz > >>> > >>> On 28/03/14 16:45, icedlava wrote: > >>>> Hi Phil, > >>>> > >>>> For reference here on the list, I have committed the code as > >>>> requested. > >>>> You have updated the original function I committed which changes > >>>> and > >>>> I > >>>> did make a point to you in email that these changes will not work. > >>>> > >>>> As per your request I've forwarded your response to the mailing > >>>> list > >>>> but > >>>> posting here for completeness in this thread. > >>>> > >>>> Note that the latest changes will not work because it is not the > >>>> fact > >>>> that the query is prepared, it is the fact the query is > >>>> paramaterized > >>>> that makes it secure. > >>>> Parameterized queries, done in the way I did it work because the > >>>> query > >>>> string and the variables are sent separately to the database server > >>>> and > >>>> only there are put together. > >>>> > >>>> The changes you made are no different to the original DB_query that > >>>> mysql_db_escapes the data - except there is more code and separated > >>>> parameters. The key issue: > >>>> > >>>> In your new code: > >>>> $result=mysqli_query($Conn, $SQLString); is the problem. No > >>>> different > >>>> to > >>>> prior old DB_query. > >>>> > >>>> The query is already 'put together' with query and variables before > >>>> it > >>>> goes to the server. That is the insecure nature of it and why I > >>>> changed > >>>> it. > >>>> > >>>> Appreciate your work and thought on it so far. > >>>> > >>>> Cheers, > >>>> > >>>> > >>>> > >>>> > >>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: > >>>> > >>>>> I've made up a new branch so we can mess with this a bit > >>>>> > >>>>> svn checkout --username=XXXXX > >>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working > >>>>> yourworkingcopy > >>>>> > >>>>> where XXXXX is your sourceforge login. > >>>>> > >>>>> Jo, if you commit the code you want for the new DB_query - and I > >>>>> propose > >>>>> we should keep it the same name - but with a new optional > >>>>> parameter > >>>>> for > >>>>> the array of parameters. > >>>>> > >>>>> > >>>>> -- > >>>>> Phil > >>>>> > >>>>> Phil Daintree > >>>>> Logic Works Ltd - +64 (0)275 567890 > >>>>> http://www.logicworks.co.nz > >>>>> > >>>>> > >>>>> > ------------------------------------------------------------------------------ > >>>>> Learn Graph Databases - Download FREE O'Reilly Book > >>>>> "Graph Databases" is the definitive new guide to graph databases > >>>>> and > >>>>> their > >>>>> applications. Written by three acclaimed leaders in the field, > >>>>> this first edition is now available. Download your free book > >>>>> today! > >>>>> http://p.sf.net/sfu/13534_NeoTech > >>>>> _______________________________________________ > >>>>> Web-erp-developers mailing list > >>>>> Web...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>> > ------------------------------------------------------------------------------ > >>>> _______________________________________________ > >>>> Web-erp-developers mailing list > >>>> Web...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >>>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Web-erp-developers mailing list > >>> Web...@li... > >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> Web-erp-developers mailing list > >> Web...@li... > >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > >> > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: icedlava <ice...@gm...> - 2014-03-28 07:34:00
|
Hi Phil, > but have you written your ideal new function - named > other than DB_query - and where the parameter type is given explicitly > rather than inferred? Would be interested to see that Did you want me to put it in the new branch? > I am also rethinking the TableView class idea to eliminate the > <tr><td></td></tr> all over the place - I would support that - I think we have too much dependence on tables for layout generally in the themes and using divs would be better. I think we should think very carefully about what classes are used and needed in the 'table less' themes and try and keep them to a minimum. CSS allows us to do great things with minimal markup. I do believe that tables are still important for data views which is where their forte in use is. > We are of course looking it almost a complete re-write here! Sounds like it lol! I'm up for it :) We could do with a list of other things to do while we are at it. I guess TWIG is still out ? It maybe just me but I don't find the code easy to look at as it's mixed thoroughly with html output. I'd still like to separate it but understand this might be going too far right now :p Cheers, On 28 Mar 2014, at 17:34, Phil Daintree wrote: > Jo, > > I can find it now - but have you written your ideal new function - > named > other than DB_query - and where the parameter type is given explicitly > rather than inferred? Would be interested to see that... perhaps since > we are doing this we should jump right on in? > > I am also rethinking the TableView class idea to eliminate the > <tr><td></td></tr> all over the place - and perhaps maybe conversion > to > <div> with optional classes? that might more easily accommodate phones > etc. We are of course looking it almost a complete re-write here! > > Let's go :-) > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 28/03/14 19:07, icedlava wrote: >> Hi Phil, >> >>> As you say, my revised DB_query() just escapes the parameters as >>> they >>> were previously - just that we have now moved the escaping to the >>> place >>> where it needs to happen rather than blanket escaping every >>> $_POST/$_GET >>> - so we are equally secure as we were ... unless I am wrong and >>> those >>> variables which should not be escaped are not escape >> Yes, exactly - we are equally secure as we were before for database >> transactions. >> As you say, the whole reason that this topic came up was due to >> non-contextual escaping of variables and the issues that has and is >> continuing to cause in the code/database. >> We have the opportunity now to fix it, but also improve the security >> of >> webERP as we fix the original variable problem, which is what I've >> tried to do with the version I committed. >> >> Thanks for your understanding! >> >> Cheers, >> >> >> On 28 Mar 2014, at 16:27, Phil Daintree wrote: >> >>> Hi Jo, >>> >>> As you say, my revised DB_query() just escapes the parameters as >>> they >>> were previously - just that we have now moved the escaping to the >>> place >>> where it needs to happen rather than blanket escaping every >>> $_POST/$_GET >>> - so we are equally secure as we were ... unless I am wrong and >>> those >>> variables which should not be escaped are not escaped. >>> >>> That said, I will look into the full prepare execute method in more >>> detail. Of course with my blinkered vision what I did is more >>> readable >>> :-) I am persuaded by the argument to do things the most secure way >>> though given we are into a major re-write and I think this may be >>> the >>> full prepare/execute method you first suggested. >>> >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd - +64 (0)275 567890 >>> http://www.logicworks.co.nz >>> >>> On 28/03/14 16:45, icedlava wrote: >>>> Hi Phil, >>>> >>>> For reference here on the list, I have committed the code as >>>> requested. >>>> You have updated the original function I committed which changes >>>> and >>>> I >>>> did make a point to you in email that these changes will not work. >>>> >>>> As per your request I've forwarded your response to the mailing >>>> list >>>> but >>>> posting here for completeness in this thread. >>>> >>>> Note that the latest changes will not work because it is not the >>>> fact >>>> that the query is prepared, it is the fact the query is >>>> paramaterized >>>> that makes it secure. >>>> Parameterized queries, done in the way I did it work because the >>>> query >>>> string and the variables are sent separately to the database server >>>> and >>>> only there are put together. >>>> >>>> The changes you made are no different to the original DB_query that >>>> mysql_db_escapes the data - except there is more code and separated >>>> parameters. The key issue: >>>> >>>> In your new code: >>>> $result=mysqli_query($Conn, $SQLString); is the problem. No >>>> different >>>> to >>>> prior old DB_query. >>>> >>>> The query is already 'put together' with query and variables before >>>> it >>>> goes to the server. That is the insecure nature of it and why I >>>> changed >>>> it. >>>> >>>> Appreciate your work and thought on it so far. >>>> >>>> Cheers, >>>> >>>> >>>> >>>> >>>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >>>> >>>>> I've made up a new branch so we can mess with this a bit >>>>> >>>>> svn checkout --username=XXXXX >>>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>>>> yourworkingcopy >>>>> >>>>> where XXXXX is your sourceforge login. >>>>> >>>>> Jo, if you commit the code you want for the new DB_query - and I >>>>> propose >>>>> we should keep it the same name - but with a new optional >>>>> parameter >>>>> for >>>>> the array of parameters. >>>>> >>>>> >>>>> -- >>>>> Phil >>>>> >>>>> Phil Daintree >>>>> Logic Works Ltd - +64 (0)275 567890 >>>>> http://www.logicworks.co.nz >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>> "Graph Databases" is the definitive new guide to graph databases >>>>> and >>>>> their >>>>> applications. Written by three acclaimed leaders in the field, >>>>> this first edition is now available. Download your free book >>>>> today! >>>>> http://p.sf.net/sfu/13534_NeoTech >>>>> _______________________________________________ >>>>> Web-erp-developers mailing list >>>>> Web...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Phil D. <ph...@lo...> - 2014-03-28 07:05:11
|
Jo, I can find it now - but have you written your ideal new function - named other than DB_query - and where the parameter type is given explicitly rather than inferred? Would be interested to see that... perhaps since we are doing this we should jump right on in? I am also rethinking the TableView class idea to eliminate the <tr><td></td></tr> all over the place - and perhaps maybe conversion to <div> with optional classes? that might more easily accommodate phones etc. We are of course looking it almost a complete re-write here! Let's go :-) Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/03/14 19:07, icedlava wrote: > Hi Phil, > >> As you say, my revised DB_query() just escapes the parameters as they >> were previously - just that we have now moved the escaping to the >> place >> where it needs to happen rather than blanket escaping every >> $_POST/$_GET >> - so we are equally secure as we were ... unless I am wrong and those >> variables which should not be escaped are not escape > Yes, exactly - we are equally secure as we were before for database > transactions. > As you say, the whole reason that this topic came up was due to > non-contextual escaping of variables and the issues that has and is > continuing to cause in the code/database. > We have the opportunity now to fix it, but also improve the security of > webERP as we fix the original variable problem, which is what I've > tried to do with the version I committed. > > Thanks for your understanding! > > Cheers, > > > On 28 Mar 2014, at 16:27, Phil Daintree wrote: > >> Hi Jo, >> >> As you say, my revised DB_query() just escapes the parameters as they >> were previously - just that we have now moved the escaping to the >> place >> where it needs to happen rather than blanket escaping every >> $_POST/$_GET >> - so we are equally secure as we were ... unless I am wrong and those >> variables which should not be escaped are not escaped. >> >> That said, I will look into the full prepare execute method in more >> detail. Of course with my blinkered vision what I did is more readable >> :-) I am persuaded by the argument to do things the most secure way >> though given we are into a major re-write and I think this may be the >> full prepare/execute method you first suggested. >> >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890 >> http://www.logicworks.co.nz >> >> On 28/03/14 16:45, icedlava wrote: >>> Hi Phil, >>> >>> For reference here on the list, I have committed the code as >>> requested. >>> You have updated the original function I committed which changes and >>> I >>> did make a point to you in email that these changes will not work. >>> >>> As per your request I've forwarded your response to the mailing list >>> but >>> posting here for completeness in this thread. >>> >>> Note that the latest changes will not work because it is not the fact >>> that the query is prepared, it is the fact the query is paramaterized >>> that makes it secure. >>> Parameterized queries, done in the way I did it work because the >>> query >>> string and the variables are sent separately to the database server >>> and >>> only there are put together. >>> >>> The changes you made are no different to the original DB_query that >>> mysql_db_escapes the data - except there is more code and separated >>> parameters. The key issue: >>> >>> In your new code: >>> $result=mysqli_query($Conn, $SQLString); is the problem. No different >>> to >>> prior old DB_query. >>> >>> The query is already 'put together' with query and variables before >>> it >>> goes to the server. That is the insecure nature of it and why I >>> changed >>> it. >>> >>> Appreciate your work and thought on it so far. >>> >>> Cheers, >>> >>> >>> >>> >>> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >>> >>>> I've made up a new branch so we can mess with this a bit >>>> >>>> svn checkout --username=XXXXX >>>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>>> yourworkingcopy >>>> >>>> where XXXXX is your sourceforge login. >>>> >>>> Jo, if you commit the code you want for the new DB_query - and I >>>> propose >>>> we should keep it the same name - but with a new optional parameter >>>> for >>>> the array of parameters. >>>> >>>> >>>> -- >>>> Phil >>>> >>>> Phil Daintree >>>> Logic Works Ltd - +64 (0)275 567890 >>>> http://www.logicworks.co.nz >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Learn Graph Databases - Download FREE O'Reilly Book >>>> "Graph Databases" is the definitive new guide to graph databases and >>>> their >>>> applications. Written by three acclaimed leaders in the field, >>>> this first edition is now available. Download your free book today! >>>> http://p.sf.net/sfu/13534_NeoTech >>>> _______________________________________________ >>>> Web-erp-developers mailing list >>>> Web...@li... >>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Phil D. <ph...@lo...> - 2014-03-28 06:15:35
|
Hi Rafael, Well debtortranstaxes can have many tax amounts that accumulate to equal the debtortrans.ovgst - the reason we have debtortranstaxes at all is because of the requirement for multiple taxes in some authorities. I think debtortranstaxes stores the tax in local currency though not the FX ... would need to check I may be wrong. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/03/14 03:14, Rafael Chacón wrote: > Hi All, > > Any comments or suggestions? > > > Best regards, Rafael. > > 2014-03-21 5:23 GMT-06:00 Rafael Chacón <raf...@gm...>: >> Hi, >> >> In tax.php (line 46) we have: >> >> (debtortrans.ovamount+debtortrans.ovfreight)/debtortrans.rate AS netamount, >> debtortrans.ovfreight/debtortrans.rate AS freightamount, >> debtortranstaxes.taxamount/debtortrans.rate AS tax >> >> ***dividing by exchange rate*** >> >> but >> In ConfirmDispatch_Invoice.php (line 830) we use: $SQL = "INSERT INTO >> debtortranstaxes.taxamount VALUES ('" . $TaxAmount/$_SESSION['CurrencyRate'] >> . "')"; >> In ConfirmDispatch_Invoice.php (line 1615) we use: $SQL = "INSERT INTO >> gltrans.amount VALUES ('" . >> round((-$TaxAmount/$_SESSION['CurrencyRate']),$_SESSION['CompanyRecord']['decimalplaces']) >> . "')"; >> In CounterReturns.php (line 965) we use: $SQL = "INSERT INTO >> debtortranstaxes.taxamount VALUES ('" . -$TaxAmount/$ExRate . "')"; >> In CounterReturns.php (line 1428) we use: $SQL = "INSERT INTO gltrans.amount >> VALUES ('" . ($TaxAmount/$ExRate) . "')"; >> In CounterSales.php (line 1383) we use: $SQL = "INSERT INTO >> debtortranstaxes.taxamount VALUES ('" . $TaxAmount/$ExRate . "')"; >> In CounterSales.php (line 1885) we use: $SQL = "INSERT INTO gltrans.amount >> VALUES ('" . (-$TaxAmount/$ExRate) . "')"; >> In Credit_Invoice.php (line 644) we use: $SQL = "INSERT INTO >> debtortranstaxes.taxamount VALUES ('" . >> (-$TaxAmount/$_SESSION['CurrencyRate']) . "')"; >> In RecurringSalesOrdersProcess.php (line 692) we use: $SQL = "INSERT INTO >> debtortranstaxes.taxamount VALUES ('" . >> filter_number_format($Tax['FXAmount']/$CurrencyRate) . "')"; >> In SelectCreditItems.php (line 1178) we use: $SQL = "INSERT INTO >> debtortranstaxes.taxamount VALUES ('" . >> -$TaxAmount/$_SESSION['CurrencyRate'] . "')"; >> In SupplierCredit.php (line 1158) we use: $SQL = "INSERT INTO >> supptranstaxes.taxamount VALUES ('" . -$TaxTotals->TaxOvAmount . "')"; >> In SupplierInvoice.php (1514) we use: $SQL = "INSERT INTO >> supptranstaxes.taxamount VALUES ('" . $TaxTotals->TaxOvAmount . "')"; >> >> I guess it must be corrected to: >> >> (debtortrans.ovamount+debtortrans.ovfreight)/debtortrans.rate AS netamount, >> debtortrans.ovfreight/debtortrans.rate AS freightamount, >> debtortranstaxes.taxamount AS tax >> >> ***NOT dividing by exchange rate*** >> >> Also, I have also doubt to what it serves the field debtortrans.ovgst. What >> is the difference between tax saved in debtortrans.ovgst and >> debtortranstaxes.taxamount? Is it exchange rate? >> >> Best regards, Rafael Chacon. > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: icedlava <ice...@gm...> - 2014-03-28 06:08:03
|
Hi Phil, > As you say, my revised DB_query() just escapes the parameters as they > were previously - just that we have now moved the escaping to the > place > where it needs to happen rather than blanket escaping every > $_POST/$_GET > - so we are equally secure as we were ... unless I am wrong and those > variables which should not be escaped are not escape Yes, exactly - we are equally secure as we were before for database transactions. As you say, the whole reason that this topic came up was due to non-contextual escaping of variables and the issues that has and is continuing to cause in the code/database. We have the opportunity now to fix it, but also improve the security of webERP as we fix the original variable problem, which is what I've tried to do with the version I committed. Thanks for your understanding! Cheers, On 28 Mar 2014, at 16:27, Phil Daintree wrote: > Hi Jo, > > As you say, my revised DB_query() just escapes the parameters as they > were previously - just that we have now moved the escaping to the > place > where it needs to happen rather than blanket escaping every > $_POST/$_GET > - so we are equally secure as we were ... unless I am wrong and those > variables which should not be escaped are not escaped. > > That said, I will look into the full prepare execute method in more > detail. Of course with my blinkered vision what I did is more readable > :-) I am persuaded by the argument to do things the most secure way > though given we are into a major re-write and I think this may be the > full prepare/execute method you first suggested. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 28/03/14 16:45, icedlava wrote: >> Hi Phil, >> >> For reference here on the list, I have committed the code as >> requested. >> You have updated the original function I committed which changes and >> I >> did make a point to you in email that these changes will not work. >> >> As per your request I've forwarded your response to the mailing list >> but >> posting here for completeness in this thread. >> >> Note that the latest changes will not work because it is not the fact >> that the query is prepared, it is the fact the query is paramaterized >> that makes it secure. >> Parameterized queries, done in the way I did it work because the >> query >> string and the variables are sent separately to the database server >> and >> only there are put together. >> >> The changes you made are no different to the original DB_query that >> mysql_db_escapes the data - except there is more code and separated >> parameters. The key issue: >> >> In your new code: >> $result=mysqli_query($Conn, $SQLString); is the problem. No different >> to >> prior old DB_query. >> >> The query is already 'put together' with query and variables before >> it >> goes to the server. That is the insecure nature of it and why I >> changed >> it. >> >> Appreciate your work and thought on it so far. >> >> Cheers, >> >> >> >> >> On 25 Mar 2014, at 17:10, Phil Daintree wrote: >> >>> I've made up a new branch so we can mess with this a bit >>> >>> svn checkout --username=XXXXX >>> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >>> yourworkingcopy >>> >>> where XXXXX is your sourceforge login. >>> >>> Jo, if you commit the code you want for the new DB_query - and I >>> propose >>> we should keep it the same name - but with a new optional parameter >>> for >>> the array of parameters. >>> >>> >>> -- >>> Phil >>> >>> Phil Daintree >>> Logic Works Ltd - +64 (0)275 567890 >>> http://www.logicworks.co.nz >>> >>> >>> ------------------------------------------------------------------------------ >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and >>> their >>> applications. Written by three acclaimed leaders in the field, >>> this first edition is now available. Download your free book today! >>> http://p.sf.net/sfu/13534_NeoTech >>> _______________________________________________ >>> Web-erp-developers mailing list >>> Web...@li... >>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: icedlava <ice...@gm...> - 2014-03-28 05:57:42
|
Hi Exson, This would be useful to have as an option and would be used as main choice for the webERP installs we have. While the picking list is useful, it would be beneficial to have Sales/accounts actually know the goods are actually picked and be able to confirm delivery will go ahead, and then issue invoice. Thanks for your good idea! Cheers, On 27 Mar 2014, at 20:03, ExsonQu wrote: > *Dear all:* > > I'm considering to add a feature to make warehouse preparing > the > goods for sales orders and Accountant or Sales can know the goods are > ready > to delivery or not more transparent. The scenario is like this: > > 1. First Sales select those orders should be arranged to > delivery. > > 2. Warehouse man check the order delivery schedule. And mark > the > order lines when it's ready. > > 3. Sales(Or accountant) confirm the delivery and issue invoice > according to the marked orders. > > 4. warehouse actually delivery. > > Not sure if it's a redundant feature. > > Any comments are very welcome. > > Best regards! > > Exson > > > > > > > > -- > View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/More-convenient-feature-for-preparing-goods-in-warehouse-and-confirm-delivery-tp4657290.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Phil D. <ph...@lo...> - 2014-03-28 05:57:22
|
Hi Jo, As you say, my revised DB_query() just escapes the parameters as they were previously - just that we have now moved the escaping to the place where it needs to happen rather than blanket escaping every $_POST/$_GET - so we are equally secure as we were ... unless I am wrong and those variables which should not be escaped are not escaped. That said, I will look into the full prepare execute method in more detail. Of course with my blinkered vision what I did is more readable :-) I am persuaded by the argument to do things the most secure way though given we are into a major re-write and I think this may be the full prepare/execute method you first suggested. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 28/03/14 16:45, icedlava wrote: > Hi Phil, > > For reference here on the list, I have committed the code as requested. > You have updated the original function I committed which changes and I > did make a point to you in email that these changes will not work. > > As per your request I've forwarded your response to the mailing list but > posting here for completeness in this thread. > > Note that the latest changes will not work because it is not the fact > that the query is prepared, it is the fact the query is paramaterized > that makes it secure. > Parameterized queries, done in the way I did it work because the query > string and the variables are sent separately to the database server and > only there are put together. > > The changes you made are no different to the original DB_query that > mysql_db_escapes the data - except there is more code and separated > parameters. The key issue: > > In your new code: > $result=mysqli_query($Conn, $SQLString); is the problem. No different to > prior old DB_query. > > The query is already 'put together' with query and variables before it > goes to the server. That is the insecure nature of it and why I changed > it. > > Appreciate your work and thought on it so far. > > Cheers, > > > > > On 25 Mar 2014, at 17:10, Phil Daintree wrote: > >> I've made up a new branch so we can mess with this a bit >> >> svn checkout --username=XXXXX >> svn+ssh://XX...@sv.../p/web-erp/code/branches/working >> yourworkingcopy >> >> where XXXXX is your sourceforge login. >> >> Jo, if you commit the code you want for the new DB_query - and I >> propose >> we should keep it the same name - but with a new optional parameter >> for >> the array of parameters. >> >> >> -- >> Phil >> >> Phil Daintree >> Logic Works Ltd - +64 (0)275 567890 >> http://www.logicworks.co.nz >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Phil D. <ph...@lo...> - 2014-03-28 05:51:13
|
This is a bit like the picking list - with stock availability displayed so you know which orders you can pick. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 27/03/14 22:33, ExsonQu wrote: > *Dear all:* > > I'm considering to add a feature to make warehouse preparing the > goods for sales orders and Accountant or Sales can know the goods are ready > to delivery or not more transparent. The scenario is like this: > > 1. First Sales select those orders should be arranged to delivery. > > 2. Warehouse man check the order delivery schedule. And mark the > order lines when it's ready. > > 3. Sales(Or accountant) confirm the delivery and issue invoice > according to the marked orders. > > 4. warehouse actually delivery. > > Not sure if it's a redundant feature. > > Any comments are very welcome. > > Best regards! > > Exson > > > > > > > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/More-convenient-feature-for-preparing-goods-in-warehouse-and-confirm-delivery-tp4657290.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Jonathan (T. <th...@ic...> - 2014-03-28 04:16:05
|
Hi there, just to put my two cents in-- Phil, the main advantage security wise of parametrized queries is that the data is sent over in a distinct 'package' from the query. You 'pseudo-parametrized' query is sent over as a string, however the true parametrized queries sends the query along separately from the parameters, which is why it protects against SQL injection, since the parameters are never a part of the SQL query string at all. |
231 messages has been excluded from this view by a project administrator.
