Re: [Phpgroupware-developers] Testing CK-Ledger v.0.7.1 against phpgroupware-0.9.16.RC1

[Dave Hall]

C=20K=20Wu <address@hidden> wrote:

> Hi, Dave,
> 
> Nah, I don't mean to nag the core team or the phpgw
> leadership into backing out of the .16 API changes. 
> My last email is actually to highlight to other addon
> maintainers that there is this potential problem that
> they have to deal with when they are preparing to
> upgrade to 0.9.16RC1 .

No problem.  Sorry I misunderstood.  I think other developers will
appreciate the heads up.  My offer of assisting you to get CK Ledger
ready for 16 still stands :)

Cheers

Dave
> 
> Cheers,
> CK
> 
> --- Dave Hall ¡G>
> Hey CK,
> > 
> > C=20K=20Wu <address@hidden> wrote:
> > 
> > > Hello, Dave,
> > > 
> > > I think I've found what's going on.
> > > 
> > > With 0.9.14.006,
> > > 
> > > ../phpgwapi/inc/class.sessions_php4.inc.php (line
> > 951)
> > > and ../phpgwapi/inc/class.sessions_db.inc.php
> > (line
> > > 977) read,
> > > 
> > > $new_extravars .= "$key=$value" ;
> > > 
> > > With 0.9.16RC1,
> > > 
> > > ../phpgwapi/inc/class.sessions.inc.php (line 1194)
> > > reads,
> > > 
> > > $new_extravars .= $key.'='.urlencode($value) ;
> > > 
> > > So, apparently, with earlier versions, it is the
> > > application script's responsibility to url_encode
> > GET
> > > variables before sending it on.  However, with
> > > 0.9.16RC1, the sessions facility handles the
> > > url_encode-ing when it receives the GET variables
> > from
> > > the application script.
> > > 
> > > With CK-Ledger v.0.7.1 running against phpgw
> > > 0.9.16RC1, it means double url_encoding and
> > therefore
> > > the callee scripts need to url_decode the GET
> > variable
> > > one more time to recover the correct value.
> > > 
> > > I think this will break a lot of the addon module
> > > codes.  However, if the GET variable passed
> > contains
> > > pure alphanumeric chars, no error will be
> > detected,
> > > since urlencode/urldecode in these cases do not
> > alter
> > > the GET variables.  So, there may be quite a fair
> > bit
> > > of  spurious 0.9.16RC1 errors being the result of
> > the
> > > above.
> > 
> > Ok, now I follow what is going on.  I didn't make
> > this change, but I can
> > understand (and agree with) the logic behind it. 
> > This is my logic with
> > it, others may disaagree, it is easier to url_encode
> > the variables, once
> > in the api, than each app maintainer having to
> > remember to encode them.
> >  It also means that if we ever have to do anything
> > else to the GET args
> > it can be changed once in the API and all apps
> > automatically get the
> > benefit.
> > 
> > I understand this will cause some problems with CK
> > Ledger, this is
> > unfortunate, but I doubt the change will be backed
> > out.  As will all new
> > versions of the API there are changes.  The 16 API
> > has quite a few
> > changes, some of which I think you app could benefit
> > from.  
> > 
> > I would suggest that you continue testing with the
> > 16RCs with regular
> > CVS updates, and keep in touch with us.  I am
> > willing to assist you get
> > your app to run properly on 16.  Please be aware
> > that I do not use CK
> > Ledger, but am happy to answer any questions you may
> > have.
> > 
> > Cheers
> > 
> > Dave
> > 
> > > 
> > > Cheers,
> > > CK
> > > 
> > > 
> > > 
> > > Dave Hall:
> > > 
> > > >CK Wu <address@hidden> wrote:
> > > >
> > > >>Hello, folks,
> > > >>
> > > >>While testing CK-Ledger v.0.7.1 against
> > > >>phpgroupware-0.9.16.RC1,
> > > >>I came across the following,
> > > >>
> > > >>When calling,
> > > >>
> > > >>
> > >
> >
>
>http://localhost/.../loglist.php?filter=%2BWHERE%2B1%253D1%2B&sessionid=...&kp3=...&domain=default&click_history=...
> > > >
> > > >Is this
> > >
> >
>
>http://localhost/phpgroupware/loglist.php?filter=%2BWHERE%2B1%253D1%2B&;...
> > > >
> > > >or
> > > >
> > > >http://localhost/ck-
> > >
> > ledger/loglist.php?filter=%2BWHERE%2B1%253D1%2B&...>
> > > >Looking at that code ... there are several
> > problems
> > > ....
> > > >
> > > >firstly the $_POST/$_GET hack won't work with
> > > register_globals = off
> > > >
> > > >Also phpgroupware has never processed the
> > external
> > > variables, I think it
> > > >is a PHP problem.  IIRC php will url_decode all
> > $_GET
> > > vars for you.
> > > >
> > > >Bit more info about where this code is will
> > probably
> > > help us track this
> > > >down.
> > > >
> > > >Cheers
> > > >
> > > >Dave
> > > >
> > > 
> > > 
> > >
> >
> _________________________________________________________
> > > ³Ì·s¹aÁn±À¤¶:address@hidden
> > > http://ringtone.yahoo.com.hk
> > > 
> > >
> > > begin:vcard
> > n:Hall;Dave
> > fn:Dave Hall
> > tel;fax:+61 3 8610 0029
> > tel;work:+61 3 96 871 871
> > org:Dave Hall Consulting;
> > adr:;;;;;;AUSTRALIA
> > version:2.1
> > email;internet:address@hidden
> > end:vcard
> > 
> >  
> 
> _________________________________________________________
> ³Ì·s¹aÁn±À¤¶:address@hidden
> http://ringtone.yahoo.com.hk
> 
>

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>