apc-aa-coders — Discussion only useful to active developers.

[Apc-aa-coders] New Images - background colors

[Mitra <mi...@ea...>]

It looks like someone is editing the layout - its great, much 
snappier than the old one.

But .....

Remember some of us are using different color schemes etc, for example

the new "Browse"  button has a white rather than transparant 
background, so it doesn't look so great on our blue admin screens!

- Mitra

-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] Ids of strange lineths.

[Honza M. <hon...@ec...>]

On P=E1, 2003-01-31 at 23:08, Mitra wrote:
> Honza
>=20
> Did you make this change to new_id?
> I don't see it in the new_id in the current CVS

I do not send it to CVS, yet. I have quite a lot of changes, which I do
not want to send to CVS at this time. If you can add it here I will
appreciate it:

/**
 * Returns new unpacked md5 unique id, except these which can force
 * unexpected end of string (or other problems)
 */
function new_id ($seed=3D"hugo"){
    do {
       $foo=3Dmd5(uniqid($seed));
    } while (ereg("(00|27)",$foo) || (substr($foo,30,2)=3D=3D'20')); =20
      // '00' is end of string, '27' is ' and packed '20' is space,=20
      // which is removed by MySQL
    return $foo;
}=20

Honza

> - Mitra
>=20
>=20
> At 2:43 PM +0100 25/1/03, Honza Malik wrote:
> > Hi Mitra,
> >=20
> >    I did some more testing on ids and now I know, where the problem
> > is.
> > The new_id() is OK - it returns allways 32 character long id, but
> > sometimes it return id with ...20 at the end. Packed '20' is space
> > and
> > this is problem, because if you insert 16 characters long packed id
> > ending with space into MySQL and then you get it back, the id is 15
> > character long.
> >=20
> > MySQL REMOVES ENDING SPACES FROM INSERTED STRING!
> > I will fix new_id() to not generate such ids.
> >=20
> >=20
> > On P=E1, 2003-01-24 at 12:28, Mitra wrote:
> > > Ok - stranger .... my guess was wrong, md5 returns a 32 character
> > > string, which cannot contain 00 or 27 so cannot end up as a
> > shorter
> > > string.
> > >
> > > To test, I ran a loop through 99999 samples of new_id, which
> > should
> > > have generated about 400 bad ids by your statistics.
> > >
> > > I think the bad ids in your database must be the result of some
> > buggy
> > > earlier code.
> > >
> > > Lets try three things.
> > > 1: Please check my test - appended at the end of this message.
> >=20
> > I test it and all 99999 ids are 32 characters long.
> >=20
> > > 2: Please re-run your test, see if the number of bad ids has gone
> > up,
> > > if there is something bad then as long as you have created more
> > than
> > > 256 ids then statistically it should have increased by 1 or more.
> >=20
> > Increased: [16] =3D> 92254 [15] =3D> 367 [14] =3D> 4
> >=20
> > > 3: Please send the code for your test, I'll run it on my
> > installation
> > > and see how many odd length ids I have.
> >=20
> > require "include/config.php3";
> > require $GLOBALS[AA_INC_PATH]."util.php3";
> > require $GLOBALS[AA_INC_PATH]."locsessi.php3";
> >=20
> > $db =3D new DB_AA;
> >=20
> > $db->query( "SELECT id from item" );
> > while($db->next_record()) {
> >     $fromdb[$len_p =3D strlen($db->f('id'))]++;
> >     $unpdb[$len_u =3D strlen(unpack_id($db->f('id')))]++;
> > //    if( $len_p<16 )
> > //        echo "<br>".$db->f('id');
> > }  =20
> >=20
> > huh($fromdb, 'packed');
> > huh($unpdb, 'unpacked');
> > echo "
> >        Regards
> >                  Honza ";
> > >
> > > - Mitra
> > >
> > >
> > > At 11:55 PM +0100 22/1/03, Honza Malik wrote:
> > > >  >3) Your assumption that packed ids are EXACTLY 16 characters
> > long (and
> > > >  >unpacked are EXACTLY 32 characters long) is unfortunately
> > wrong. I can't
> > > >  >say you why - we generate the ids by new_id() function, but in
> > our
> > > >  >database are packed ids for item 16 (in 91907 items), 15 (366)
> > and 14
> > > >  >(4) characters long.
> > > >
> > > >  Strange - because new_id uses "md5" which has to return 128
> > bits.
> > > >
> > > >  I wonder if these were ids which generated a leading ascii
> > zero, the
> > > >  ratios look reasonable for this, i.e. 919007/366 =3D 251, which
> > is
> > > >  close to a one in 256 chance, i.e. something that occurred when
> > 8
> > > >  bits (2^8=3D256) all were zero.    This makes sense if we assume
> > that
> > > >  md5 returns a number which the ereg in new_id casts as a
> > string, and
> > > >  so ignores the leading zero.
> > > >
> > > >  I've fixed zids.php3 to allow 12..16 character packed ids, and
> > 24..32
> > > >  long, but this could break my tagged ids. I've also fixed
> > > >  util.php3.new_id to only return a string of exactly 16 chars.
> > > >
> > > >  > >5) In zids.php3 you wrote:
> > > >>  >
> > > >>  >function id_t2l(&$str) {
> > > >>  >#TODO: Look online for quicker way to substr last 32 chars -
> > mitra
> > > >>  >         if (ereg("(.*)([0-9a-f]{32})",$str,$parts))
> > > >>  >                 return $parts[2];
> > > >>  >
> > > >>  >The quicker way is: substr($str, -32), but see 3)
> > > >>
> > > >>  Ok - I'll make this 24..32, and I guess we can't use tags that
> > end in
> > > >>  a hex character [0-9a-f)
> > > >
> > > >Or you can use some delimeter (tag:unpacked_id). As I write
> > before, we
> > > >never use tags so far, so the syntax is on your choice.
> > >
> > >
> > > require "../include/config.php3";
> > > require $GLOBALS[AA_INC_PATH]."util.php3";
> > >
> > > $i =3D 0;
> > > $j=3D 99999;
> > > print "<br>Testing start, loops=3D$j: sample=3D";
> > > $foo =3D new_id();
> > > print $foo;
> > > while ($i++ < $j) {
> > > $foo =3D new_id();
> > > if (strlen($foo) !=3D 32) print
> > "<br>FOO:$i:$foo:strlen=3D".strlen($foo);
> > > if (strlen(pack_id($foo)) !=3D 16) print "<br>FOO:$i:$foo:packed
> > > strlen=3D".strlen(\
> > > pack_id($foo));
> > > }
> > > print "<br>Testing end sample =3D ";
> > > $foo =3D new_id();
> > > print $foo;
> > >
> > > print "Done\n";
> > >
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld
> > http://www.vasoftware.com
> > _______________________________________________
> > Apc-aa-coders mailing list
> > Apc...@li...
> > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>=20
>=20
>=20
> --=20
> Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> 02-6684-8096  or 0414-648-0722=20
>=20
> Life is a Mystery to be Lived, not a Problem to be Solved
>=20

[Apc-aa-coders] FAQ update

[Mitra <mi...@ea...>]

I've made a few changes to the FAQ, allowing for grouping Slice Admin 
sections by sub-category, I've assigned most of the existing items to 
categories, but feel free to edit, move etc etc

- Mitra

-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722

Life is a Mystery to be Lived, not a Problem to be Solved

[Apc-aa-coders] Group permissions broken

[Mitra <mi...@ea...>]

Group Permissions seem to be broken,

Assign New Permissions has a list of slices, but when you select one 
and hit Update the page redraws with no changes.

Anyone been working on this recently, want to take a look at what is wrong?

- Mitra

-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722

Life is a Mystery to be Lived, not a Problem to be Solved

[Apc-aa-coders] CVS updates - miscellaneous

[Mitra <mi...@ea...>]

I've updated a number of files to CVS, a collection of minor changes, 
plus a bugfix that Norbert needed.

here's the commented Changes file extract

02/01/03

  - removed "Edit" from uneditable aliases in se_view (mitra)

This is a visual change in the Admin interface, it doesn't make any 
sense to put a non-clickable "Edit" for the fixed aliases.

          - added _#ITEMINDX and f_e:itemindex  for item number within a view

I'm working on some code for a photo gallery, knowing which item you 
are on is part of it.

          - added _#ADD_ITEM standard alias, for putting on views to 
jump to add item (uses f_e)

This is a companion to _#EDITITEM, allowing a button on a view that 
goes to the admin interface to add an item.

          - added {dequote:....} to stringexpand to allow { } in 
fields where needed

This might need a little explaining.   i have a view, which displays 
"fulltext" of an item, but I want the item to be able to call another 
view - specifically I have a number of pages on a site, but one or 
two are actually generated from database lists. If you put 
"{view.php3?vid=20}" into the fulltext field then the "{" get quoted, 
but by putting "{dequote:{fulltext}} " in the caller, I unquote the { 
and expand as normal.  This took a lot of thinking about, but I think 
its right since it specifically make sure that the contents of a 
field are ONLY expanded when specifically allowed by the caller.

          - added a generic extensions syntax to stringexpand via an 
array of functions

Mor eon this later, I want a general way to add new functions to the 
{....} syntax.

          - made huhl smarter, can print object via its printobj() 
method, implemented for zids.

Trying to make the debugging output more meaningful AND shorter.

- Mitra


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] timeouts with site module

[Mitra <mi...@ea...>]

Ok -

There was an inadvertant change in handling this particular case of 
handling   x-234-
which I've fixed and put into CVS

I haven't figured out why it is handling invalid ids badly, are you 
sure it used to work for bad ids?

- Mitra


At 2:37 PM +0100 31/1/03, Norbert Brazda wrote:
>From: "Norbert Brazda" <br...@ch...>
>>  I have downloaded fresh CVS version of AA scripts. The new scripts are
>>  not able to parse/generate resulting contents of the site pages 
>>due to timeouts:
>>  "Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/
>>  html/apc-aa/include/stringexpand.php3 on line 243".
>
>This was false alarm. New installation of AA somehow used settings 
>from old one.
>
>But anyway, there are other problems that seems related to changes 
>in querying item ids (zids?).
>
>We use something like
>     {view.php3?vid=235&cmd[235]=x-235-{cat}}
>in our site module. In old version of aa scripts, it works even if 
>the "cat" is not defined, empty, or set to bad value (not in 
>database). New version displays SQL error messages.
>
>When "cat" is not defined/empty:
>
>SELECT * FROM item WHERE short_id IN () Database error: Invalid SQL: 
>explain SELECT * FROM item WHERE short_id  IN ()
>MySQL Error: 1064 (You have an error in your SQL syntax near ')' at line 1)
>Please contact te...@ch... and report the exact error message.
>Session halted.
>
>When "cat" is set to bad value (not defined in our aa dabase):
>
>SELECT * FROM content WHERE item_id = Database error: Invalid SQL: 
>explain SELECT * FROM content WHERE item_id  = 
>MySQL Error: 1064 (You have an error in your SQL syntax near '' at line 2)
>Please contact te...@ch... and report the exact error message.
>Session halted.
>
>
>
>You can see this at:
>http://test.changenet.sk/
>
>
>
>
>Norbert Brazda
>br...@ch...
>tel: 0905-729359
>
>ChangeNet  - informacny servis o obcianskej spolocnosti
>Mlynske nivy 41, 821 09  Bratislava, Slovakia
>tel/fax: 02-55560026, eMail: in...@ch...
>http://www.changenet.sk
>
>SPAJAME LUDI, KTORI MENIA SVET
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] Ids of strange lineths.

[Mitra <mi...@ea...>]

Honza

Did you make this change to new_id?

I don't see it in the new_id in the current CVS

- Mitra


At 2:43 PM +0100 25/1/03, Honza Malik wrote:
>Hi Mitra,
>
>    I did some more testing on ids and now I know, where the problem is.
>The new_id() is OK - it returns allways 32 character long id, but
>sometimes it return id with ...20 at the end. Packed '20' is space and
>this is problem, because if you insert 16 characters long packed id
>ending with space into MySQL and then you get it back, the id is 15
>character long.
>
>MySQL REMOVES ENDING SPACES FROM INSERTED STRING!
>
>I will fix new_id() to not generate such ids.
>
>
>On P=E1, 2003-01-24 at 12:28, Mitra wrote:
>>  Ok - stranger .... my guess was wrong, md5 returns a 32 character
>>  string, which cannot contain 00 or 27 so cannot end up as a shorter
>>  string.
>>
>>  To test, I ran a loop through 99999 samples of new_id, which should
>>  have generated about 400 bad ids by your statistics.
>>
>>  I think the bad ids in your database must be the result of some buggy
>>  earlier code.
>>
>>  Lets try three things.
>>  1: Please check my test - appended at the end of this message.
>
>I test it and all 99999 ids are 32 characters long.
>
>>  2: Please re-run your test, see if the number of bad ids has gone up,
>>  if there is something bad then as long as you have created more than
>>  256 ids then statistically it should have increased by 1 or more.
>
>Increased: [16] =3D> 92254 [15] =3D> 367 [14] =3D> 4
>
>>  3: Please send the code for your test, I'll run it on my installation
>>  and see how many odd length ids I have.
>
>require "include/config.php3";
>require $GLOBALS[AA_INC_PATH]."util.php3";
>require $GLOBALS[AA_INC_PATH]."locsessi.php3";
>
>$db =3D new DB_AA;
>
>$db->query( "SELECT id from item" );
>while($db->next_record()) {
>     $fromdb[$len_p =3D strlen($db->f('id'))]++;
>     $unpdb[$len_u =3D strlen(unpack_id($db->f('id')))]++;
>//    if( $len_p<16 )
>//        echo "<br>".$db->f('id');
>}   
>
>huh($fromdb, 'packed');
>huh($unpdb, 'unpacked');
>
>echo "
>
>        Regards
>                  Honza ";
>
>
>  >
>  > - Mitra
>  >
>  >
>  > At 11:55 PM +0100 22/1/03, Honza Malik wrote:
>  > >  >3) Your assumption that packed ids are EXACTLY 16 characters long (=
and
>>  >  >unpacked are EXACTLY 32 characters long) is unfortunately wrong. I c=
an't
>>  >  >say you why - we generate the ids by new_id() function, but in our
>>  >  >database are packed ids for item 16 (in 91907 items), 15 (366) and 1=
4
>>  >  >(4) characters long.
>>  >
>>  >  Strange - because new_id uses "md5" which has to return 128 bits.
>>  >
>>  >  I wonder if these were ids which generated a leading ascii zero, the
>>  >  ratios look reasonable for this, i.e. 919007/366 =3D 251, which is
>>  >  close to a one in 256 chance, i.e. something that occurred when 8
>>  >  bits (2^8=3D256) all were zero.    This makes sense if we assume that
>  > >  md5 returns a number which the ereg in new_id casts as a string, and
>  > >  so ignores the leading zero.
>  > >
>  > >  I've fixed zids.php3 to allow 12..16 character packed ids, and 24..3=
2
>>  >  long, but this could break my tagged ids. I've also fixed
>>  >  util.php3.new_id to only return a string of exactly 16 chars.
>>  >
>>  >  > >5) In zids.php3 you wrote:
>>  >>  >
>>  >>  >function id_t2l(&$str) {
>>  >>  >#TODO: Look online for quicker way to substr last 32 chars - mitra
>>  >>  >         if (ereg("(.*)([0-9a-f]{32})",$str,$parts))
>>  >>  >                 return $parts[2];
>>  >>  >
>>  >>  >The quicker way is: substr($str, -32), but see 3)
>>  >>
>>  >>  Ok - I'll make this 24..32, and I guess we can't use tags that end i=
n
>>  >>  a hex character [0-9a-f)
>>  >
>>  >Or you can use some delimeter (tag:unpacked_id). As I write before, we
>>  >never use tags so far, so the syntax is on your choice.
>>
>>
>>  require "../include/config.php3";
>>  require $GLOBALS[AA_INC_PATH]."util.php3";
>>
>>  $i =3D 0;
>>  $j=3D 99999;
>>  print "<br>Testing start, loops=3D$j: sample=3D";
>>  $foo =3D new_id();
>>  print $foo;
>>  while ($i++ < $j) {
>  > $foo =3D new_id();
>>  if (strlen($foo) !=3D 32) print "<br>FOO:$i:$foo:strlen=3D".strlen($foo)=
;
>>  if (strlen(pack_id($foo)) !=3D 16) print "<br>FOO:$i:$foo:packed
>>  strlen=3D".strlen(\
>>  pack_id($foo));
>>  }
>>  print "<br>Testing end sample =3D ";
>>  $foo =3D new_id();
>>  print $foo;
>>
>>  print "Done\n";
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] timeouts with site module

[Norbert B. <br...@ch...>]

From: "Norbert Brazda" <br...@ch...>
> I have downloaded fresh CVS version of AA scripts. The new scripts are =

> not able to parse/generate resulting contents of the site pages due to =
timeouts:=20
> "Fatal error: Maximum execution time of 30 seconds exceeded in =
/var/www/
> html/apc-aa/include/stringexpand.php3 on line 243".

This was false alarm. New installation of AA somehow used settings from =
old one.=20

But anyway, there are other problems that seems related to changes in =
querying item ids (zids?).

We use something like=20
    {view.php3?vid=3D235&cmd[235]=3Dx-235-{cat}}=20
in our site module. In old version of aa scripts, it works even if the =
"cat" is not defined, empty, or set to bad value (not in database). New =
version displays SQL error messages.=20

When "cat" is not defined/empty:

SELECT * FROM item WHERE short_id IN () Database error: Invalid SQL: =
explain SELECT * FROM item WHERE short_id  IN ()
MySQL Error: 1064 (You have an error in your SQL syntax near ')' at line =
1)
Please contact te...@ch... and report the exact error message.
Session halted.

When "cat" is set to bad value (not defined in our aa dabase):

SELECT * FROM content WHERE item_id =3D Database error: Invalid SQL: =
explain SELECT * FROM content WHERE item_id  =3D =20
MySQL Error: 1064 (You have an error in your SQL syntax near '' at line =
2)
Please contact te...@ch... and report the exact error message.
Session halted.



You can see this at:
http://test.changenet.sk/




Norbert Brazda
br...@ch...
tel: 0905-729359

ChangeNet  - informacny servis o obcianskej spolocnosti
Mlynske nivy 41, 821 09  Bratislava, Slovakia
tel/fax: 02-55560026, eMail: in...@ch...
http://www.changenet.sk

SPAJAME LUDI, KTORI MENIA SVET

[Apc-aa-coders] timeouts with site module

[Norbert B. <br...@ch...>]

I have downloaded fresh CVS version of AA scripts. The new scripts are =
not able to parse/generate resulting contents of the site pages due to =
timeouts: "Fatal error: Maximum execution time of 30 seconds exceeded in =
/var/www/html/apc-aa/include/stringexpand.php3 on line 243".

I have created test site with fresh CVS code with the same content =
(accessing the same aadb database) as main ChangeNet's website. It is =
located at http://test.changenet.sk/, while original site (with code =
from Dec 2002) is at: http://www.changenet.sk/.

We tested parsing of individual spots (as defined in site module) - no =
problems, their content is parsed and displayed correctly. But it ends =
with timeout when the site.php3 script is going to parse all spots in =
the module.

Any ideas?



Norbert Brazda
br...@ch...
tel: 0905-729359

ChangeNet  - informacny servis o obcianskej spolocnosti
Mlynske nivy 41, 821 09  Bratislava, Slovakia
tel/fax: 02-55560026, eMail: in...@ch...
http://www.changenet.sk

SPAJAME LUDI, KTORI MENIA SVET

Re: [Apc-aa-coders] CountHits

[Honza M. <hon...@ec...>]

On =C8t, 2003-01-30 at 12:08, Norbert Brazda wrote:
> From: "Mitra" <mi...@ea...>
> > Any ideas on this?  There are a couple of changes I'd like to make to=
=20
> > core tables - specifically for View to add a "name" and "counthits"=20
> > fields.

It make sense. For "counthits" you can also use the "flag" field. It's
up to you.

> It might be worth to think about new function that will do general
> "counting" on fields (e.g. increment, decrement, add value, etc -
> perhaps with use of math function). It might be achieved by retrieving
> value of specified field from AA database, doing math operation and
> storing value back.
>=20
> Except for "hits" it might be usefull for rating of articles
> (good/bad, 1/2/3/4/5 points, average, etc.) or other purposes.

Mitra's 'counthits' field is something a bit different - it is just flag
which tells view.php3 script that the view displays fulltext of an item,
so the 'item view count' should be incremented.

Anyway, good idea.

   Honza

>=20
>=20
> norbert
> br...@ch...
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware=
.com
> _______________________________________________
> Apc-aa-coders mailing list
> Apc...@li...
> https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>=20

Re: [Apc-aa-coders] CountHits

[Norbert B. <br...@ch...>]

From: "Mitra" <mi...@ea...>
> Any ideas on this?  There are a couple of changes I'd like to make to=20
> core tables - specifically for View to add a "name" and "counthits"=20
> fields.

It might be worth to think about new function that will do general =
"counting" on fields (e.g. increment, decrement, add value, etc - =
perhaps with use of math function). It might be achieved by retrieving =
value of specified field from AA database, doing math operation and =
storing value back.

Except for "hits" it might be usefull for rating of articles (good/bad, =
1/2/3/4/5 points, average, etc.) or other purposes.



norbert
br...@ch...

Re: [Apc-aa-coders] Changes: site module, edititem,

[Mitra <mi...@ea...>]

Yes - but the cached session problem is a completely differernt problem.

I was trying to think about this - and how to implement it today - 
why don't we have this problem within APC-AA/admin, in other words, 
aren't we caching stuff that is dependent on users-id, but caching it 
without caching the users-id (via the session)

- Mitra


At 2:17 AM +0100 30/1/03, Honza Malik wrote:
>On St, 2003-01-29 at 02:38, Mitra wrote:
>>  Logging in is fine if you just want to edit one item, but if you are
>>  editing lots of items it really doesn't work. This is the case where
>>  for example someone is going back and forward from the site to the
>>  editor looking at how their site looks as they make changes.
>>
>>  The ONLY use-case I can find where what I'm doing has a problem is ...
>>  a: Has superadmin permissions
>>  b: Uses a browser that does HTTP_REFERER (most don't these days)
>>  b: Follows a link on apc-aa to a site run by hackers who grab the
>>  Session id from the HTTP_REFERER
>>  c: They use that id within the expiry time (how long is that?)
>>
>>  This is a pretty obscure case, and I'm sure I could find much more
>>  frequent (but also obscure) ways to breach security.
>
>I know it is quite obscure. If you know about other security problems in
>AA, please send me it.
>
>>  Do you have other Use-cases?
>
>No, you are right. On the other hand I would probably say the same three
>weeks ago, before we found the problem with cached sessions.
>
>    Honza
>
>>
>>  Mitra
>>
>>
>>  At 2:25 AM +0100 29/1/03, Honza Malik wrote:
>>  >On St, 2003-01-29 at 01:55, Mitra wrote:
>>  >>  Ok - I'll put this in, which will fix the current clear 
>>security problem.
>>  >>
>>  >>  If you don't want to export AA_CP_Session what other solution would
>>  >>  be better, to allow moving smoothly between viewing and editing items
>>  >>  on a site?
>>  >
>>  >Maybe Anonymous posting form or maybe some solution with simplified user
>>  >account - this user will be able just edit the items in the slice but
>>  >nothing more. Then the exporting of the AA_CP_Session will not be such
>>  >problem than to export the session with my superadmin account.
>>  >The solution, where you have to login each time you want to edit the
>  > >item (it is your solution without exporting sessions) is not so bad,
>  > >too.
>  > >
>  > >    Honza
>  > >
>  > >>     Maybe using cookies for the authentication would be
>  > >>  better? Or maybe you could deal with your "HTTP_REFERER" concern by
>>  >>  linking AA_CP_Session with IP address.
>>  >>
>>  >>  - Mitra
>>  >>
>>  >>
>>  >>  At 12:42 AM +0100 29/1/03, Honza Malik wrote:
>>  >>  >Sorry for no response. I think the addition AA_CP_Session in cache
>>  >>  >str2find string could help.
>>  >>  >
>>  >>  >On the other hand, you probably know I'm not freind of exporting
>>  >>  >AA_CP_Session outside of AA Admin interface (referer problem, 
>>...), so I
>>  >>  >will probably encourage Econnect's administrators to not use this
>>  >>  >feature on our servers. It doesn't mean I do not want this 
>>feature in AA
>>  >>  >- I just want to mention possible problems in the FAQ - the ussage of
>>  >>  >such feature is then up to admins.
>>  >>  >
>>  >>  >    Honza
>>  >>  >
>>  >>  >
>>  >>  >On St, 2003-01-29 at 00:04, Mitra wrote:
>>  >>  >>  Honza -
>>  >>  >>
>>  >>  >>  I don't see a reply to this ... do you think adding the 
>>AA_CP_Session
>>  >>  >>  to the cache string is a good idea?
>>  >>  >>
>>  >>  >>  - Mitra
>>  >>  >>
>>  >>  >>
>>  >>  >>  At 9:34 PM +1100 20/1/03, Mitra wrote:
>>  >>  >>  > Hmmm -
>>  >>  >>  > This is a good point,
>>  >>  >>  > One alternative would be to add the AA_CP_Session to the cache
>>  >  > >>  > string,
>>  >  > >>  > Even if this is not sufficient, this is something we need to do.
>>  >  > >>  > What do you think?
>>  >  > >>  > - Mitra
>>  >  > >>  > At 10:50 AM +0100 20/1/03, Honza Malik wrote:
>>  >>  >>  > > I found another, much more serious problem in this - caching.
>>  >>  >>  > >
>>  >>  >>  > > If I update an item on such page (you can test on FAQ), then new
>  > >>  >>  > > page is
>>  >>  >>  > > generated from database and my AA_CP_Session id is added. BUT,
>>  >>  >>  > > this page
>>  >>  >>  > > is CACHED (internaly in AA for both - slice.php3 as well as for
>>  >>  >>  > > view.php3), so EVERYONE who is going to the page obtain the page
>>  >>  >>  > > from
>>  >>  >>  > > cache WITH MY SESSION ID.
>>  >>  >>  > >
>>  >>  >>  > > I think we really have to remove export AA_CP_Session 
>>ids outside
>>  >>  >>  > > of
>>  >>  >>  > > Admin interface.
>>  >>  >>  > >
>>  >>  >>  > >    Honza
>>  >>  >>  > >
>>  >>  >>  > > On Ne, 2003-01-12 at 22:11, Mitra wrote:
>>  >>  >>  > > > Its a good point, I was trying to think of security 
>>holes in it.
>>  >>  >>  > > >
>>  >>  >>  > > > I think this is a bit of a non-worry for a number of reasons.
>>  >>  >>  > > > 1: Most browsers don't send referer URLs any more - really
>>  >>  >  > > > annoying
>>  >>  >  > > > > when you are trying to track things down.
>>  >>  >  > > > > 2: The hacker would have to be on a site you linked to, and
>>  >  > >  > > > react
>>  >>  >  > > > > within three hours.
>>  >>  >>  > > >
>>  >>  >>  > > > I just don't see this as a big security hole.
>>  >>  >>  > > >
>>  >>  >>  > > > - Mitra
>>  >>  >>  > > >
>>  >>  >>  > > >
>>  >>  >>  > > > At 10:05 PM +0100 12/1/03, Honza Malik wrote:
>>  >>  >>  > > > >On Ne, 2003-01-12 at 02:08, Mitra wrote:
>>  >>  >>  > > > >>  The biggest change is that _#EDITITEM should now work in
>>  >>  >>  > > most cases
>>  >>  >>  > > > >>  outside of the admin interface, with the user 
>>being prompted
>>  >>  >  > > > for a
>>  >>  >  > > > > >>  userid/password and then returned back to where they came
>>  >>  >  > > > from.
>>  >>  >  > > > > >
>>  >>  >  > > > > >It's nice. Thanks Mitra.
>>  >>  >  > > > > >
>>  >>  >  > > > > >Just one note: It's not secure to add AA_CP_Session to urls
>>  >>  >>  > > outside of
>>  >>  >>  > > > >AA Admin interface (like in FAQ). If there is any link to any
>>  >>  >>  > > other
>>  >>  >>  > > > >webpage (in FAQ), it is possible to get your session id
>>  >>  >>  > > (AA_CP_Session)
>>  >>  >>  > > > >from 'Referer' field. With this id (or url) you are able to
>>  >>  >>  > > access AA
>>  >>  >>  > > > >admin pages without login (for 3 hours, when session id
>>  >>  >>  > > expires).
>>  >>  >>  > > > >
>>  >>  >>  > > > >I would probably prefer to create the link without 
>>the session
>>  >>  >>  > > id (with
>>  >>  >>  > > > >f_e) as default (so users have to log in on every item edit)
>>  >>  >>  > > and then
>>  >>  >>  > > > >maybe create optional f_e for those admins, who knows about
>>  >>  >>  > > this problem
>>  >>  >>  > > > >and don't care. At least we have to mention it in the FAQ.
>>  >>  >>  > > > >
>>  >>  >>  > > > >What you think?
>>  >>  >>  > > > >
>>  >>  >>  > > > >    Honza
>>  >>  >>  > > > >
>>  >>  >>  > > > >>  - Mitra
>>  >>  >>  > > > >>
>>  >>  >>  > > > >>
>>  >>  >>  > > > >>
>>  >>  >>  > > > >>  01/12/02 - changed site module to go to prior sibling when
>>  >>  >  > > > deleting
>>  >>  >  > > > > >>  rather than parent
>>  >>  >>  > > > >>  01/12/02 - added default $item=null to 
>>new_unalias_recurent
>>  >>  >>  > > to allow
>>  >>  >>  > > > >>  calling from site module without warnings
>>  >>  >>  > > > >>  01/12/02 - fixed adding AA_CP_Session to url in 
>>site module
>>  >>  >>  > > AAPage
>>  >>  >>  > > > >>  where it is already there.
>>  >>  >>  > > > >>  01/12/02 - changes to allow _#EDITITEM to be 
>>used outside of
>>  >>  >>  > > admin interface
>>  >>  >>  > > > >>  01/12/02 - combined several ways of redirecting to a URL
>>  >>  >>  > > into common
>>  >>  >>  > > > >>  function go_return_or_url
>>  >>  >>  > > > >
>>  >>  >>  > > > >
>>  >>  >>  > > > >
>>  >>  >>  > > > >-------------------------------------------------------
>>  >>  >>  > > > >This SF.NET email is sponsored by:
>>  >>  >>  > > > >SourceForge Enterprise Edition + IBM + LinuxWorld = 
>>Something 2
>>  >>  >>  > > See!
>>  >>  >>  > > > >http://www.vasoftware.com
>>  >>  >>  > > > >_______________________________________________
>>  >>  >>  > > > >Apc-aa-coders mailing list
>>  >>  >>  > > > >Apc...@li...
>>  >>  >>  > > > >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>  >>  >>  > > >
>  > >>  >>  > >
>>  >>  >>  > >
>>  >>  >>  > >
>>  >>  >>  > > -------------------------------------------------------
>>  >>  >>  > > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>>  >>  >>  > > are you planning your Web Server Security? Click here to get a
>>  >>  >>  > > FREE
>>  >>  >>  > > Thawte SSL guide and find the answers to all your  SSL security
>>  >>  >>  > > issues.
>>  >>  >>  > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>>  >>  >>  > > _______________________________________________
>>  >>  >>  > > Apc-aa-coders mailing list
>>  >>  >>  > > Apc...@li...
>>  >>  >>  > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>  >>  >>  > --
>>  >>  >>  > Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>>  >>  >>  > 02-6684-8096  or 0414-648-0722
>>  >>  >>  > Life is a Mystery to be Lived, not a Problem to be Solved
>>  >>  >>
>>  >>  >>
>>  >>  >>
>>  >>  >>  --
>>  >>  >>  Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>>  >>  >>  02-6684-8096  or 0414-648-0722
>>  >>  >>
>>  >>  >>  Life is a Mystery to be Lived, not a Problem to be Solved
>>  >>  >>
>>  >>  >
>>  >>  >
>>  >>  >
>>  >>  >-------------------------------------------------------
>>  >>  >This SF.NET email is sponsored by:
>>  >>  >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>  >>  >http://www.vasoftware.com
>>  >>  >_______________________________________________
>>  >>  >Apc-aa-coders mailing list
>>  >  > >Apc...@li...
>>  >>  >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>  >>
>>  >
>>  >
>>  >
>>  >-------------------------------------------------------
>>  >This SF.NET email is sponsored by:
>>  >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>  >http://www.vasoftware.com
>>  >_______________________________________________
>>  >Apc-aa-coders mailing list
>>  >Apc...@li...
>>  >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] Re: [Apc-aa-general] Re: Is everyone running PHP 4.0.6 or better

[Mitra <mi...@ea...>]

I'll add it to the FAQ

That phpDocumentor doc is pretty comprehensive, but  If you read the 
whole of phpDocumenter and use all its options, then our 
phpDocumentor produced document will be totally inconsistent.

I think we need a stripped down version that describes basic 
documentation   .... just a couple of examples of what to put at each 
key point

Head of file
Before function
Before class

- Mitra

At 2:08 AM +0100 30/1/03, Honza Malik wrote:
>On St, 2003-01-29 at 02:07, Mitra wrote:
>>  Honza -
>>
>>  Can you put a pointer to that file (first time I remember seeing it!)
>>  in the FAQ and in doc/index.htm
>
>I already added the link in doc/index.htm. If you can, please, do it in
>FAQ.
>
>>  Also ... if we are using PHPdoc then lets say so, and how to use it.
>
>Most of us think, it is good idea to use phpDoc comments (based on
>reactions in the list), so I ask developers to use it in new code. It
>doesn't mean we will not use standard '//' comments in the code - every
>part of code should be comented as much as possible.
>
>The best manual for phpDoc I found is on:
>
>http://phpdoc.org/docs/HTMLframesConverter/default/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html
>>  Also ....what do you think about ...
>>
>>  >Outside of a class definition it is best not to access its member
>>  >variables directly, so for example don't do
>>  >auth->auth[$uid]
>>  >The reason is that it makes it hard to change the internal data
>>  >representation, which is a part of the reason behind using classes.
>
>Yes, encapsulation is good technique and we should follow it
>(unfortunately the phpLib do not use this technique - as shown in your
>example - there is no way how to get $auth[$uid] without accessing
>internal class variable (and we need it - it is stored in database)).
>
>>  >Instead create a function in the class that returns what you are
>>  >looking for, and think ahead - i.e. the worst thing you can do is
>>  >just to create access functiosn like "function get_auth()". This
>>  >just adds overhead with no useful encapsulation, instead create
>>  >useful functions like "function is_authorised($uid)"
>
>Sometimes the access functions (like _get(), _store()) are not so bad
>idea - many IDEs creates such functions automaticaly. At least, it is
>much better than to use direct access to internal variables.
>
>  > Maybe also a suggestion about NOT using session variables except
>  > where necessary, and maybe we need to document all of these in one
>>  place?
>
>Good idea.
>
>    Honza
>
>>  - Mitra
>>
>>
>>  At 2:13 AM +0100 29/1/03, Honza Malik wrote:
>>  >OK, next release of APC ActionApps will be for PHP 4.0.6 or better.
>>  >I mention this in 'Coding Standards' file:
>>  >http://aa.ecn.cz/aaa/doc/coding.html
>>  >
>>  >    Honza
>>  >
>>  >On St, 2003-01-29 at 00:19, Mitra wrote:
>>  >>  We recieved several replies saying that people are running 4.0.6 or
>>  >>  better, and none saying they were still using PHP 3 so I think we can
>>  >>  go ahead and assume that we can use PHP4 features in apc-aa
>>  >>
>>  >>  - Mitra
>>  >>
>>  >>
>>  >>  At 2:30 PM +1100 23/1/03, Mitra wrote:
>>  >>  >Hi
>>  >>  >
>>  >>  >There is some thinking about using PHP functions that are only in
>>  >>  >PHP4.0.6 or better,
>>  >>  >
>>  >>  >In fact ... they are in the latest CVS version, since i didn't
>>  >>  >realize how new they were :-)
>>  >>  >
>>  >>  >If anyone is running a lower version could they let us know so we
>>  >>  >can decide whether to convert this code back to php3 or whether we
>>  >>  >can stick with php4.
>>  >>  >
>>  >>  >- Mitra
>>  >>  >
>>  >>  >--
>>  >>  >Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>>  >>  >02-6684-8096  or 0414-648-0722
>>  >>  >
>>  >>  >Life is a Mystery to be Lived, not a Problem to be Solved
>>  >>
>>  >
>>  >
>>  >
>>  >-------------------------------------------------------
>>  >This SF.NET email is sponsored by:
>>  >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>  > >http://www.vasoftware.com
>>  >_______________________________________________
>>  >apc-aa-general mailing list
>>  >apc...@li...
>>  >https://lists.sourceforge.net/lists/listinfo/apc-aa-general
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] CountHits

[Mitra <mi...@ea...>]

Hi Honza

Any ideas on this?  There are a couple of changes I'd like to make to 
core tables - specifically for View to add a "name" and "counthits" 
fields.

- Mitra


At 8:53 AM +1100 24/1/03, Mitra wrote:
>This sounds like a trivial change, but I'm unclear where are all the 
>places that need changing if a change like this is to be made to a 
>key table like view?
>
>Maybe this is something you could put in the Developers part of the 
>FAQ, I know that if I do it, I'll probably miss one place and break 
>something.
>
>-  Mitra
>
>
>At 9:57 PM +0100 23/1/03, Honza Malik wrote:
>>It's quite hard to decide, when to count hit and when not by script. The
>>x-vid-item_id commend is mainly used for fulltext item display, so used
>>aproximation is not so bad, but I agree it could be improved. The idea
>>of view parameter sounds good.
>>
>>    Honza
>>
>>On P=E1, 2003-01-17 at 08:39, Mitra wrote:
>>>  I'm doing some work on the flexible Ids that we discussed.
>>>
>>>  Looking at view.php3, it is very strange in the way it Counts hits -
>>>  where parameters are passed with cmd[]=3Dx-vid-123-456 -
>>>
>>>  it increments the first item in the view, but not the others, this is
>>>  going to make the first item look much more popular than the others?
>>>
>>>  Maybe this should be a parameter of the view, overridable in the
>>>  code?  So for example as a site editor I might consider that showing
>>>  a list of headlines didn't count as a "display", but showing the
>>>  abstracts did?
>>>
>>>  - Mitra
>>
>>
>>
>>-------------------------------------------------------
>>This SF.NET email is sponsored by:
>>SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.co=
m
>>_______________________________________________
>>Apc-aa-coders mailing list
>>Apc...@li...
>>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>
>
>--
>Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>02-6684-8096  or 0414-648-0722
>
>Life is a Mystery to be Lived, not a Problem to be Solved


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] Changes: site module, edititem,

[Honza M. <hon...@ec...>]

On St, 2003-01-29 at 02:38, Mitra wrote:
> Logging in is fine if you just want to edit one item, but if you are 
> editing lots of items it really doesn't work. This is the case where 
> for example someone is going back and forward from the site to the 
> editor looking at how their site looks as they make changes.
> 
> The ONLY use-case I can find where what I'm doing has a problem is ...
> a: Has superadmin permissions
> b: Uses a browser that does HTTP_REFERER (most don't these days)
> b: Follows a link on apc-aa to a site run by hackers who grab the 
> Session id from the HTTP_REFERER
> c: They use that id within the expiry time (how long is that?)
> 
> This is a pretty obscure case, and I'm sure I could find much more 
> frequent (but also obscure) ways to breach security.

I know it is quite obscure. If you know about other security problems in
AA, please send me it.

> Do you have other Use-cases?

No, you are right. On the other hand I would probably say the same three
weeks ago, before we found the problem with cached sessions.

   Honza

> 
> Mitra
> 
> 
> At 2:25 AM +0100 29/1/03, Honza Malik wrote:
> >On St, 2003-01-29 at 01:55, Mitra wrote:
> >>  Ok - I'll put this in, which will fix the current clear security problem.
> >>
> >>  If you don't want to export AA_CP_Session what other solution would
> >>  be better, to allow moving smoothly between viewing and editing items
> >>  on a site?
> >
> >Maybe Anonymous posting form or maybe some solution with simplified user
> >account - this user will be able just edit the items in the slice but
> >nothing more. Then the exporting of the AA_CP_Session will not be such
> >problem than to export the session with my superadmin account.
> >The solution, where you have to login each time you want to edit the
> >item (it is your solution without exporting sessions) is not so bad,
> >too.
> >
> >    Honza
> >
> >>     Maybe using cookies for the authentication would be
> >>  better? Or maybe you could deal with your "HTTP_REFERER" concern by
> >>  linking AA_CP_Session with IP address.
> >>
> >>  - Mitra
> >>
> >>
> >>  At 12:42 AM +0100 29/1/03, Honza Malik wrote:
> >>  >Sorry for no response. I think the addition AA_CP_Session in cache
> >>  >str2find string could help.
> >>  >
> >>  >On the other hand, you probably know I'm not freind of exporting
> >>  >AA_CP_Session outside of AA Admin interface (referer problem, ...), so I
> >>  >will probably encourage Econnect's administrators to not use this
> >>  >feature on our servers. It doesn't mean I do not want this feature in AA
> >>  >- I just want to mention possible problems in the FAQ - the ussage of
> >>  >such feature is then up to admins.
> >>  >
> >>  >    Honza
> >>  >
> >>  >
> >>  >On St, 2003-01-29 at 00:04, Mitra wrote:
> >>  >>  Honza -
> >>  >>
> >>  >>  I don't see a reply to this ... do you think adding the AA_CP_Session
> >>  >>  to the cache string is a good idea?
> >>  >>
> >>  >>  - Mitra
> >>  >>
> >>  >>
> >>  >>  At 9:34 PM +1100 20/1/03, Mitra wrote:
> >>  >>  > Hmmm -
> >>  >>  > This is a good point,
> >>  >>  > One alternative would be to add the AA_CP_Session to the cache
> >  > >>  > string,
> >  > >>  > Even if this is not sufficient, this is something we need to do.
> >  > >>  > What do you think?
> >  > >>  > - Mitra
> >  > >>  > At 10:50 AM +0100 20/1/03, Honza Malik wrote:
> >>  >>  > > I found another, much more serious problem in this - caching.
> >>  >>  > >
> >>  >>  > > If I update an item on such page (you can test on FAQ), then new
> >>  >>  > > page is
> >>  >>  > > generated from database and my AA_CP_Session id is added. BUT,
> >>  >>  > > this page
> >>  >>  > > is CACHED (internaly in AA for both - slice.php3 as well as for
> >>  >>  > > view.php3), so EVERYONE who is going to the page obtain the page
> >>  >>  > > from
> >>  >>  > > cache WITH MY SESSION ID.
> >>  >>  > >
> >>  >>  > > I think we really have to remove export AA_CP_Session ids outside
> >>  >>  > > of
> >>  >>  > > Admin interface.
> >>  >>  > >
> >>  >>  > >    Honza
> >>  >>  > >
> >>  >>  > > On Ne, 2003-01-12 at 22:11, Mitra wrote:
> >>  >>  > > > Its a good point, I was trying to think of security holes in it.
> >>  >>  > > >
> >>  >>  > > > I think this is a bit of a non-worry for a number of reasons.
> >>  >>  > > > 1: Most browsers don't send referer URLs any more - really
> >>  >  > > > annoying
> >>  >  > > > > when you are trying to track things down.
> >>  >  > > > > 2: The hacker would have to be on a site you linked to, and
> >  > >  > > > react
> >>  >  > > > > within three hours.
> >>  >>  > > >
> >>  >>  > > > I just don't see this as a big security hole.
> >>  >>  > > >
> >>  >>  > > > - Mitra
> >>  >>  > > >
> >>  >>  > > >
> >>  >>  > > > At 10:05 PM +0100 12/1/03, Honza Malik wrote:
> >>  >>  > > > >On Ne, 2003-01-12 at 02:08, Mitra wrote:
> >>  >>  > > > >>  The biggest change is that _#EDITITEM should now work in
> >>  >>  > > most cases
> >>  >>  > > > >>  outside of the admin interface, with the user being prompted
> >>  >  > > > for a
> >>  >  > > > > >>  userid/password and then returned back to where they came
> >>  >  > > > from.
> >>  >  > > > > >
> >>  >  > > > > >It's nice. Thanks Mitra.
> >>  >  > > > > >
> >>  >  > > > > >Just one note: It's not secure to add AA_CP_Session to urls
> >>  >>  > > outside of
> >>  >>  > > > >AA Admin interface (like in FAQ). If there is any link to any
> >>  >>  > > other
> >>  >>  > > > >webpage (in FAQ), it is possible to get your session id
> >>  >>  > > (AA_CP_Session)
> >>  >>  > > > >from 'Referer' field. With this id (or url) you are able to
> >>  >>  > > access AA
> >>  >>  > > > >admin pages without login (for 3 hours, when session id
> >>  >>  > > expires).
> >>  >>  > > > >
> >>  >>  > > > >I would probably prefer to create the link without the session
> >>  >>  > > id (with
> >>  >>  > > > >f_e) as default (so users have to log in on every item edit)
> >>  >>  > > and then
> >>  >>  > > > >maybe create optional f_e for those admins, who knows about
> >>  >>  > > this problem
> >>  >>  > > > >and don't care. At least we have to mention it in the FAQ.
> >>  >>  > > > >
> >>  >>  > > > >What you think?
> >>  >>  > > > >
> >>  >>  > > > >    Honza
> >>  >>  > > > >
> >>  >>  > > > >>  - Mitra
> >>  >>  > > > >>
> >>  >>  > > > >>
> >>  >>  > > > >>
> >>  >>  > > > >>  01/12/02 - changed site module to go to prior sibling when
> >>  >  > > > deleting
> >>  >  > > > > >>  rather than parent
> >>  >>  > > > >>  01/12/02 - added default $item=null to new_unalias_recurent
> >>  >>  > > to allow
> >>  >>  > > > >>  calling from site module without warnings
> >>  >>  > > > >>  01/12/02 - fixed adding AA_CP_Session to url in site module
> >>  >>  > > AAPage
> >>  >>  > > > >>  where it is already there.
> >>  >>  > > > >>  01/12/02 - changes to allow _#EDITITEM to be used outside of
> >>  >>  > > admin interface
> >>  >>  > > > >>  01/12/02 - combined several ways of redirecting to a URL
> >>  >>  > > into common
> >>  >>  > > > >>  function go_return_or_url
> >>  >>  > > > >
> >>  >>  > > > >
> >>  >>  > > > >
> >>  >>  > > > >-------------------------------------------------------
> >>  >>  > > > >This SF.NET email is sponsored by:
> >>  >>  > > > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2
> >>  >>  > > See!
> >>  >>  > > > >http://www.vasoftware.com
> >>  >>  > > > >_______________________________________________
> >>  >>  > > > >Apc-aa-coders mailing list
> >>  >>  > > > >Apc...@li...
> >>  >>  > > > >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> >>  >>  > > >
> >>  >>  > >
> >>  >>  > >
> >>  >>  > >
> >>  >>  > > -------------------------------------------------------
> >>  >>  > > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> >>  >>  > > are you planning your Web Server Security? Click here to get a
> >>  >>  > > FREE
> >>  >>  > > Thawte SSL guide and find the answers to all your  SSL security
> >>  >>  > > issues.
> >>  >>  > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> >>  >>  > > _______________________________________________
> >>  >>  > > Apc-aa-coders mailing list
> >>  >>  > > Apc...@li...
> >>  >>  > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> >>  >>  > --
> >>  >>  > Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> >>  >>  > 02-6684-8096  or 0414-648-0722
> >>  >>  > Life is a Mystery to be Lived, not a Problem to be Solved
> >>  >>
> >>  >>
> >>  >>
> >>  >>  --
> >>  >>  Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> >>  >>  02-6684-8096  or 0414-648-0722
> >>  >>
> >>  >>  Life is a Mystery to be Lived, not a Problem to be Solved
> >>  >>
> >>  >
> >>  >
> >>  >
> >>  >-------------------------------------------------------
> >>  >This SF.NET email is sponsored by:
> >>  >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> >>  >http://www.vasoftware.com
> >>  >_______________________________________________
> >>  >Apc-aa-coders mailing list
> >  > >Apc...@li...
> >>  >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.NET email is sponsored by:
> >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> >http://www.vasoftware.com
> >_______________________________________________
> >Apc-aa-coders mailing list
> >Apc...@li...
> >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> 

Re: [Apc-aa-coders] Re: [Apc-aa-general] Re: Is everyone running PHP 4.0.6 or better

[Honza M. <hon...@ec...>]

On St, 2003-01-29 at 02:07, Mitra wrote:
> Honza -
> 
> Can you put a pointer to that file (first time I remember seeing it!) 
> in the FAQ and in doc/index.htm

I already added the link in doc/index.htm. If you can, please, do it in
FAQ.

> Also ... if we are using PHPdoc then lets say so, and how to use it.

Most of us think, it is good idea to use phpDoc comments (based on
reactions in the list), so I ask developers to use it in new code. It
doesn't mean we will not use standard '//' comments in the code - every
part of code should be comented as much as possible.

The best manual for phpDoc I found is on:

http://phpdoc.org/docs/HTMLframesConverter/default/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html 
> Also ....what do you think about ...
> 
> >Outside of a class definition it is best not to access its member 
> >variables directly, so for example don't do
> >auth->auth[$uid]
> >The reason is that it makes it hard to change the internal data 
> >representation, which is a part of the reason behind using classes.

Yes, encapsulation is good technique and we should follow it
(unfortunately the phpLib do not use this technique - as shown in your
example - there is no way how to get $auth[$uid] without accessing
internal class variable (and we need it - it is stored in database)).

> >Instead create a function in the class that returns what you are 
> >looking for, and think ahead - i.e. the worst thing you can do is 
> >just to create access functiosn like "function get_auth()". This 
> >just adds overhead with no useful encapsulation, instead create 
> >useful functions like "function is_authorised($uid)"

Sometimes the access functions (like _get(), _store()) are not so bad
idea - many IDEs creates such functions automaticaly. At least, it is
much better than to use direct access to internal variables.

> Maybe also a suggestion about NOT using session variables except 
> where necessary, and maybe we need to document all of these in one 
> place?

Good idea.

   Honza

> - Mitra
> 
> 
> At 2:13 AM +0100 29/1/03, Honza Malik wrote:
> >OK, next release of APC ActionApps will be for PHP 4.0.6 or better.
> >I mention this in 'Coding Standards' file:
> >http://aa.ecn.cz/aaa/doc/coding.html
> >
> >    Honza
> >
> >On St, 2003-01-29 at 00:19, Mitra wrote:
> >>  We recieved several replies saying that people are running 4.0.6 or
> >>  better, and none saying they were still using PHP 3 so I think we can
> >>  go ahead and assume that we can use PHP4 features in apc-aa
> >>
> >>  - Mitra
> >>
> >>
> >>  At 2:30 PM +1100 23/1/03, Mitra wrote:
> >>  >Hi
> >>  >
> >>  >There is some thinking about using PHP functions that are only in
> >>  >PHP4.0.6 or better,
> >>  >
> >>  >In fact ... they are in the latest CVS version, since i didn't
> >>  >realize how new they were :-)
> >>  >
> >>  >If anyone is running a lower version could they let us know so we
> >>  >can decide whether to convert this code back to php3 or whether we
> >>  >can stick with php4.
> >>  >
> >>  >- Mitra
> >>  >
> >>  >--
> >>  >Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> >>  >02-6684-8096  or 0414-648-0722
> >>  >
> >>  >Life is a Mystery to be Lived, not a Problem to be Solved
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.NET email is sponsored by:
> >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> >http://www.vasoftware.com
> >_______________________________________________
> >apc-aa-general mailing list
> >apc...@li...
> >https://lists.sourceforge.net/lists/listinfo/apc-aa-general
> 

[Apc-aa-coders] Timing improvements

[Mitra <mi...@ea...>]

I just update stringexpand .php3 to use preg_match rather than ereg, 
this made an incredible 10,000 times improvement in speed, i.e. from 
around 15 seconds to run ereg on a multi-line text to just 0.002 
seconds

I knew preg_match was supposed to be faster, but I had no idea just 
how much faster it can be. It might be worth suspecting ereg if other 
parts of the code turn out to be really slow.

In the process of doing this, I added some time debugging code. To 
see what I did try adding


&debug=1&debugtimes=1

to something and see an incremental trace of how long the page has taken.

Also you do add  &time_limit=180

to override the default 30 second timeout in PHP (this only works on 
view.php3). I think 30 seconds is more than reasonable, but I 
couldn't debug to find the slow code without being able to stop it 
timing out.

- Mitra

-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] Changes: site module, edititem,

[Mitra <mi...@ea...>]

Logging in is fine if you just want to edit one item, but if you are 
editing lots of items it really doesn't work. This is the case where 
for example someone is going back and forward from the site to the 
editor looking at how their site looks as they make changes.

The ONLY use-case I can find where what I'm doing has a problem is ...
a: Has superadmin permissions
b: Uses a browser that does HTTP_REFERER (most don't these days)
b: Follows a link on apc-aa to a site run by hackers who grab the 
Session id from the HTTP_REFERER
c: They use that id within the expiry time (how long is that?)

This is a pretty obscure case, and I'm sure I could find much more 
frequent (but also obscure) ways to breach security.

Do you have other Use-cases?

Mitra


At 2:25 AM +0100 29/1/03, Honza Malik wrote:
>On St, 2003-01-29 at 01:55, Mitra wrote:
>>  Ok - I'll put this in, which will fix the current clear security problem.
>>
>>  If you don't want to export AA_CP_Session what other solution would
>>  be better, to allow moving smoothly between viewing and editing items
>>  on a site?
>
>Maybe Anonymous posting form or maybe some solution with simplified user
>account - this user will be able just edit the items in the slice but
>nothing more. Then the exporting of the AA_CP_Session will not be such
>problem than to export the session with my superadmin account.
>The solution, where you have to login each time you want to edit the
>item (it is your solution without exporting sessions) is not so bad,
>too.
>
>    Honza
>
>>     Maybe using cookies for the authentication would be
>>  better? Or maybe you could deal with your "HTTP_REFERER" concern by
>>  linking AA_CP_Session with IP address.
>>
>>  - Mitra
>>
>>
>>  At 12:42 AM +0100 29/1/03, Honza Malik wrote:
>>  >Sorry for no response. I think the addition AA_CP_Session in cache
>>  >str2find string could help.
>>  >
>>  >On the other hand, you probably know I'm not freind of exporting
>>  >AA_CP_Session outside of AA Admin interface (referer problem, ...), so I
>>  >will probably encourage Econnect's administrators to not use this
>>  >feature on our servers. It doesn't mean I do not want this feature in AA
>>  >- I just want to mention possible problems in the FAQ - the ussage of
>>  >such feature is then up to admins.
>>  >
>>  >    Honza
>>  >
>>  >
>>  >On St, 2003-01-29 at 00:04, Mitra wrote:
>>  >>  Honza -
>>  >>
>>  >>  I don't see a reply to this ... do you think adding the AA_CP_Session
>>  >>  to the cache string is a good idea?
>>  >>
>>  >>  - Mitra
>>  >>
>>  >>
>>  >>  At 9:34 PM +1100 20/1/03, Mitra wrote:
>>  >>  > Hmmm -
>>  >>  > This is a good point,
>>  >>  > One alternative would be to add the AA_CP_Session to the cache
>  > >>  > string,
>  > >>  > Even if this is not sufficient, this is something we need to do.
>  > >>  > What do you think?
>  > >>  > - Mitra
>  > >>  > At 10:50 AM +0100 20/1/03, Honza Malik wrote:
>>  >>  > > I found another, much more serious problem in this - caching.
>>  >>  > >
>>  >>  > > If I update an item on such page (you can test on FAQ), then new
>>  >>  > > page is
>>  >>  > > generated from database and my AA_CP_Session id is added. BUT,
>>  >>  > > this page
>>  >>  > > is CACHED (internaly in AA for both - slice.php3 as well as for
>>  >>  > > view.php3), so EVERYONE who is going to the page obtain the page
>>  >>  > > from
>>  >>  > > cache WITH MY SESSION ID.
>>  >>  > >
>>  >>  > > I think we really have to remove export AA_CP_Session ids outside
>>  >>  > > of
>>  >>  > > Admin interface.
>>  >>  > >
>>  >>  > >    Honza
>>  >>  > >
>>  >>  > > On Ne, 2003-01-12 at 22:11, Mitra wrote:
>>  >>  > > > Its a good point, I was trying to think of security holes in it.
>>  >>  > > >
>>  >>  > > > I think this is a bit of a non-worry for a number of reasons.
>>  >>  > > > 1: Most browsers don't send referer URLs any more - really
>>  >  > > > annoying
>>  >  > > > > when you are trying to track things down.
>>  >  > > > > 2: The hacker would have to be on a site you linked to, and
>  > >  > > > react
>>  >  > > > > within three hours.
>>  >>  > > >
>>  >>  > > > I just don't see this as a big security hole.
>>  >>  > > >
>>  >>  > > > - Mitra
>>  >>  > > >
>>  >>  > > >
>>  >>  > > > At 10:05 PM +0100 12/1/03, Honza Malik wrote:
>>  >>  > > > >On Ne, 2003-01-12 at 02:08, Mitra wrote:
>>  >>  > > > >>  The biggest change is that _#EDITITEM should now work in
>>  >>  > > most cases
>>  >>  > > > >>  outside of the admin interface, with the user being prompted
>>  >  > > > for a
>>  >  > > > > >>  userid/password and then returned back to where they came
>>  >  > > > from.
>>  >  > > > > >
>>  >  > > > > >It's nice. Thanks Mitra.
>>  >  > > > > >
>>  >  > > > > >Just one note: It's not secure to add AA_CP_Session to urls
>>  >>  > > outside of
>>  >>  > > > >AA Admin interface (like in FAQ). If there is any link to any
>>  >>  > > other
>>  >>  > > > >webpage (in FAQ), it is possible to get your session id
>>  >>  > > (AA_CP_Session)
>>  >>  > > > >from 'Referer' field. With this id (or url) you are able to
>>  >>  > > access AA
>>  >>  > > > >admin pages without login (for 3 hours, when session id
>>  >>  > > expires).
>>  >>  > > > >
>>  >>  > > > >I would probably prefer to create the link without the session
>>  >>  > > id (with
>>  >>  > > > >f_e) as default (so users have to log in on every item edit)
>>  >>  > > and then
>>  >>  > > > >maybe create optional f_e for those admins, who knows about
>>  >>  > > this problem
>>  >>  > > > >and don't care. At least we have to mention it in the FAQ.
>>  >>  > > > >
>>  >>  > > > >What you think?
>>  >>  > > > >
>>  >>  > > > >    Honza
>>  >>  > > > >
>>  >>  > > > >>  - Mitra
>>  >>  > > > >>
>>  >>  > > > >>
>>  >>  > > > >>
>>  >>  > > > >>  01/12/02 - changed site module to go to prior sibling when
>>  >  > > > deleting
>>  >  > > > > >>  rather than parent
>>  >>  > > > >>  01/12/02 - added default $item=null to new_unalias_recurent
>>  >>  > > to allow
>>  >>  > > > >>  calling from site module without warnings
>>  >>  > > > >>  01/12/02 - fixed adding AA_CP_Session to url in site module
>>  >>  > > AAPage
>>  >>  > > > >>  where it is already there.
>>  >>  > > > >>  01/12/02 - changes to allow _#EDITITEM to be used outside of
>>  >>  > > admin interface
>>  >>  > > > >>  01/12/02 - combined several ways of redirecting to a URL
>>  >>  > > into common
>>  >>  > > > >>  function go_return_or_url
>>  >>  > > > >
>>  >>  > > > >
>>  >>  > > > >
>>  >>  > > > >-------------------------------------------------------
>>  >>  > > > >This SF.NET email is sponsored by:
>>  >>  > > > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2
>>  >>  > > See!
>>  >>  > > > >http://www.vasoftware.com
>>  >>  > > > >_______________________________________________
>>  >>  > > > >Apc-aa-coders mailing list
>>  >>  > > > >Apc...@li...
>>  >>  > > > >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>  >>  > > >
>>  >>  > >
>>  >>  > >
>>  >>  > >
>>  >>  > > -------------------------------------------------------
>>  >>  > > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>>  >>  > > are you planning your Web Server Security? Click here to get a
>>  >>  > > FREE
>>  >>  > > Thawte SSL guide and find the answers to all your  SSL security
>>  >>  > > issues.
>>  >>  > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>>  >>  > > _______________________________________________
>>  >>  > > Apc-aa-coders mailing list
>>  >>  > > Apc...@li...
>>  >>  > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>  >>  > --
>>  >>  > Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>>  >>  > 02-6684-8096  or 0414-648-0722
>>  >>  > Life is a Mystery to be Lived, not a Problem to be Solved
>>  >>
>>  >>
>>  >>
>>  >>  --
>>  >>  Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>>  >>  02-6684-8096  or 0414-648-0722
>>  >>
>>  >>  Life is a Mystery to be Lived, not a Problem to be Solved
>>  >>
>>  >
>>  >
>>  >
>>  >-------------------------------------------------------
>>  >This SF.NET email is sponsored by:
>>  >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>  >http://www.vasoftware.com
>>  >_______________________________________________
>>  >Apc-aa-coders mailing list
>  > >Apc...@li...
>>  >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved

[Apc-aa-coders] Re: [Apc-aa-general] Re: Is everyone running PHP 4.0.6 or better

[Mitra <mit...@ea...>]

Honza -

Can you put a pointer to that file (first time I remember seeing it!) 
in the FAQ and in doc/index.htm

Also ... if we are using PHPdoc then lets say so, and how to use it.

Also ....what do you think about ...

>Outside of a class definition it is best not to access its member 
>variables directly, so for example don't do
>auth->auth[$uid]
>The reason is that it makes it hard to change the internal data 
>representation, which is a part of the reason behind using classes.
>
>Instead create a function in the class that returns what you are 
>looking for, and think ahead - i.e. the worst thing you can do is 
>just to create access functiosn like "function get_auth()". This 
>just adds overhead with no useful encapsulation, instead create 
>useful functions like "function is_authorised($uid)"

Maybe also a suggestion about NOT using session variables except 
where necessary, and maybe we need to document all of these in one 
place?

- Mitra


At 2:13 AM +0100 29/1/03, Honza Malik wrote:
>OK, next release of APC ActionApps will be for PHP 4.0.6 or better.
>I mention this in 'Coding Standards' file:
>http://aa.ecn.cz/aaa/doc/coding.html
>
>    Honza
>
>On St, 2003-01-29 at 00:19, Mitra wrote:
>>  We recieved several replies saying that people are running 4.0.6 or
>>  better, and none saying they were still using PHP 3 so I think we can
>>  go ahead and assume that we can use PHP4 features in apc-aa
>>
>>  - Mitra
>>
>>
>>  At 2:30 PM +1100 23/1/03, Mitra wrote:
>>  >Hi
>>  >
>>  >There is some thinking about using PHP functions that are only in
>>  >PHP4.0.6 or better,
>>  >
>>  >In fact ... they are in the latest CVS version, since i didn't
>>  >realize how new they were :-)
>>  >
>>  >If anyone is running a lower version could they let us know so we
>>  >can decide whether to convert this code back to php3 or whether we
>>  >can stick with php4.
>>  >
>>  >- Mitra
>>  >
>>  >--
>>  >Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>>  >02-6684-8096  or 0414-648-0722
>>  >
>>  >Life is a Mystery to be Lived, not a Problem to be Solved
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>apc-aa-general mailing list
>apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-general


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] Changes: site module, edititem,

[Honza M. <hon...@ec...>]

On St, 2003-01-29 at 01:55, Mitra wrote:
> Ok - I'll put this in, which will fix the current clear security problem.
> 
> If you don't want to export AA_CP_Session what other solution would 
> be better, to allow moving smoothly between viewing and editing items 
> on a site?

Maybe Anonymous posting form or maybe some solution with simplified user
account - this user will be able just edit the items in the slice but
nothing more. Then the exporting of the AA_CP_Session will not be such
problem than to export the session with my superadmin account.
The solution, where you have to login each time you want to edit the
item (it is your solution without exporting sessions) is not so bad,
too.

   Honza 

>    Maybe using cookies for the authentication would be 
> better? Or maybe you could deal with your "HTTP_REFERER" concern by 
> linking AA_CP_Session with IP address.
> 
> - Mitra
> 
> 
> At 12:42 AM +0100 29/1/03, Honza Malik wrote:
> >Sorry for no response. I think the addition AA_CP_Session in cache
> >str2find string could help.
> >
> >On the other hand, you probably know I'm not freind of exporting
> >AA_CP_Session outside of AA Admin interface (referer problem, ...), so I
> >will probably encourage Econnect's administrators to not use this
> >feature on our servers. It doesn't mean I do not want this feature in AA
> >- I just want to mention possible problems in the FAQ - the ussage of
> >such feature is then up to admins.
> >
> >    Honza
> >
> >
> >On St, 2003-01-29 at 00:04, Mitra wrote:
> >>  Honza -
> >>
> >>  I don't see a reply to this ... do you think adding the AA_CP_Session
> >>  to the cache string is a good idea?
> >>
> >>  - Mitra
> >>
> >>
> >>  At 9:34 PM +1100 20/1/03, Mitra wrote:
> >>  > Hmmm -
> >>  > This is a good point,
> >>  > One alternative would be to add the AA_CP_Session to the cache
> >>  > string,
> >>  > Even if this is not sufficient, this is something we need to do.
> >>  > What do you think?
> >>  > - Mitra
> >>  > At 10:50 AM +0100 20/1/03, Honza Malik wrote:
> >>  > > I found another, much more serious problem in this - caching.
> >>  > >
> >>  > > If I update an item on such page (you can test on FAQ), then new
> >>  > > page is
> >>  > > generated from database and my AA_CP_Session id is added. BUT,
> >>  > > this page
> >>  > > is CACHED (internaly in AA for both - slice.php3 as well as for
> >>  > > view.php3), so EVERYONE who is going to the page obtain the page
> >>  > > from
> >>  > > cache WITH MY SESSION ID.
> >>  > >
> >>  > > I think we really have to remove export AA_CP_Session ids outside
> >>  > > of
> >>  > > Admin interface.
> >>  > >
> >>  > >    Honza
> >>  > >
> >>  > > On Ne, 2003-01-12 at 22:11, Mitra wrote:
> >>  > > > Its a good point, I was trying to think of security holes in it.
> >>  > > >
> >>  > > > I think this is a bit of a non-worry for a number of reasons.
> >>  > > > 1: Most browsers don't send referer URLs any more - really
> >  > > > annoying
> >  > > > > when you are trying to track things down.
> >  > > > > 2: The hacker would have to be on a site you linked to, and
> >  > > > react
> >  > > > > within three hours.
> >>  > > >
> >>  > > > I just don't see this as a big security hole.
> >>  > > >
> >>  > > > - Mitra
> >>  > > >
> >>  > > >
> >>  > > > At 10:05 PM +0100 12/1/03, Honza Malik wrote:
> >>  > > > >On Ne, 2003-01-12 at 02:08, Mitra wrote:
> >>  > > > >>  The biggest change is that _#EDITITEM should now work in
> >>  > > most cases
> >>  > > > >>  outside of the admin interface, with the user being prompted
> >  > > > for a
> >  > > > > >>  userid/password and then returned back to where they came
> >  > > > from.
> >  > > > > >
> >  > > > > >It's nice. Thanks Mitra.
> >  > > > > >
> >  > > > > >Just one note: It's not secure to add AA_CP_Session to urls
> >>  > > outside of
> >>  > > > >AA Admin interface (like in FAQ). If there is any link to any
> >>  > > other
> >>  > > > >webpage (in FAQ), it is possible to get your session id
> >>  > > (AA_CP_Session)
> >>  > > > >from 'Referer' field. With this id (or url) you are able to
> >>  > > access AA
> >>  > > > >admin pages without login (for 3 hours, when session id
> >>  > > expires).
> >>  > > > >
> >>  > > > >I would probably prefer to create the link without the session
> >>  > > id (with
> >>  > > > >f_e) as default (so users have to log in on every item edit)
> >>  > > and then
> >>  > > > >maybe create optional f_e for those admins, who knows about
> >>  > > this problem
> >>  > > > >and don't care. At least we have to mention it in the FAQ.
> >>  > > > >
> >>  > > > >What you think?
> >>  > > > >
> >>  > > > >    Honza
> >>  > > > >
> >>  > > > >>  - Mitra
> >>  > > > >>
> >>  > > > >>
> >>  > > > >>
> >>  > > > >>  01/12/02 - changed site module to go to prior sibling when
> >  > > > deleting
> >  > > > > >>  rather than parent
> >>  > > > >>  01/12/02 - added default $item=null to new_unalias_recurent
> >>  > > to allow
> >>  > > > >>  calling from site module without warnings
> >>  > > > >>  01/12/02 - fixed adding AA_CP_Session to url in site module
> >>  > > AAPage
> >>  > > > >>  where it is already there.
> >>  > > > >>  01/12/02 - changes to allow _#EDITITEM to be used outside of
> >>  > > admin interface
> >>  > > > >>  01/12/02 - combined several ways of redirecting to a URL
> >>  > > into common
> >>  > > > >>  function go_return_or_url
> >>  > > > >
> >>  > > > >
> >>  > > > >
> >>  > > > >-------------------------------------------------------
> >>  > > > >This SF.NET email is sponsored by:
> >>  > > > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2
> >>  > > See!
> >>  > > > >http://www.vasoftware.com
> >>  > > > >_______________________________________________
> >>  > > > >Apc-aa-coders mailing list
> >>  > > > >Apc...@li...
> >>  > > > >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> >>  > > >
> >>  > >
> >>  > >
> >>  > >
> >>  > > -------------------------------------------------------
> >>  > > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> >>  > > are you planning your Web Server Security? Click here to get a
> >>  > > FREE
> >>  > > Thawte SSL guide and find the answers to all your  SSL security
> >>  > > issues.
> >>  > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> >>  > > _______________________________________________
> >>  > > Apc-aa-coders mailing list
> >>  > > Apc...@li...
> >>  > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> >>  > --
> >>  > Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> >>  > 02-6684-8096  or 0414-648-0722
> >>  > Life is a Mystery to be Lived, not a Problem to be Solved
> >>
> >>
> >>
> >>  --
> >>  Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> >>  02-6684-8096  or 0414-648-0722
> >>
> >>  Life is a Mystery to be Lived, not a Problem to be Solved
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.NET email is sponsored by:
> >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> >http://www.vasoftware.com
> >_______________________________________________
> >Apc-aa-coders mailing list
> >Apc...@li...
> >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> 

RE: [Apc-aa-coders] Abandoning aadb.sql

[Honza M. <hon...@ec...>]

aadb.sql is removed from CVS.

    Honza

On Po, 2003-01-27 at 12:32, Marek Tichy wrote:
> > But ... lets not lose site of the original question - can we delete 
> > aadb.sql from the system and remove it from the documentation!   We 
> > don't need the wizzard before we do that.
> 
> I'd say "YES"
> 
> YES. YES YES YES !!!!!!!
> 
> 
> Yes 	   Yes    
>  Yes    Yes     
>   Yes  Yes      
>    YesYes 
>     Yes
>      Yes 
>       Yes
>        Yes 
> 
> Is there anything more I could do ? 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Apc-aa-coders mailing list
> Apc...@li...
> https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> 

Re: [Apc-aa-coders] Changes: site module, edititem,

[Mitra <mi...@mi...>]

Ok - I'll put this in, which will fix the current clear security problem.

If you don't want to export AA_CP_Session what other solution would 
be better, to allow moving smoothly between viewing and editing items 
on a site?   Maybe using cookies for the authentication would be 
better? Or maybe you could deal with your "HTTP_REFERER" concern by 
linking AA_CP_Session with IP address.

- Mitra


At 12:42 AM +0100 29/1/03, Honza Malik wrote:
>Sorry for no response. I think the addition AA_CP_Session in cache
>str2find string could help.
>
>On the other hand, you probably know I'm not freind of exporting
>AA_CP_Session outside of AA Admin interface (referer problem, ...), so I
>will probably encourage Econnect's administrators to not use this
>feature on our servers. It doesn't mean I do not want this feature in AA
>- I just want to mention possible problems in the FAQ - the ussage of
>such feature is then up to admins.
>
>    Honza
>
>
>On St, 2003-01-29 at 00:04, Mitra wrote:
>>  Honza -
>>
>>  I don't see a reply to this ... do you think adding the AA_CP_Session
>>  to the cache string is a good idea?
>>
>>  - Mitra
>>
>>
>>  At 9:34 PM +1100 20/1/03, Mitra wrote:
>>  > Hmmm -
>>  > This is a good point,
>>  > One alternative would be to add the AA_CP_Session to the cache
>>  > string,
>>  > Even if this is not sufficient, this is something we need to do.
>>  > What do you think?
>>  > - Mitra
>>  > At 10:50 AM +0100 20/1/03, Honza Malik wrote:
>>  > > I found another, much more serious problem in this - caching.
>>  > >
>>  > > If I update an item on such page (you can test on FAQ), then new
>>  > > page is
>>  > > generated from database and my AA_CP_Session id is added. BUT,
>>  > > this page
>>  > > is CACHED (internaly in AA for both - slice.php3 as well as for
>>  > > view.php3), so EVERYONE who is going to the page obtain the page
>>  > > from
>>  > > cache WITH MY SESSION ID.
>>  > >
>>  > > I think we really have to remove export AA_CP_Session ids outside
>>  > > of
>>  > > Admin interface.
>>  > >
>>  > >    Honza
>>  > >
>>  > > On Ne, 2003-01-12 at 22:11, Mitra wrote:
>>  > > > Its a good point, I was trying to think of security holes in it.
>>  > > >
>>  > > > I think this is a bit of a non-worry for a number of reasons.
>>  > > > 1: Most browsers don't send referer URLs any more - really
>  > > > annoying
>  > > > > when you are trying to track things down.
>  > > > > 2: The hacker would have to be on a site you linked to, and
>  > > > react
>  > > > > within three hours.
>>  > > >
>>  > > > I just don't see this as a big security hole.
>>  > > >
>>  > > > - Mitra
>>  > > >
>>  > > >
>>  > > > At 10:05 PM +0100 12/1/03, Honza Malik wrote:
>>  > > > >On Ne, 2003-01-12 at 02:08, Mitra wrote:
>>  > > > >>  The biggest change is that _#EDITITEM should now work in
>>  > > most cases
>>  > > > >>  outside of the admin interface, with the user being prompted
>  > > > for a
>  > > > > >>  userid/password and then returned back to where they came
>  > > > from.
>  > > > > >
>  > > > > >It's nice. Thanks Mitra.
>  > > > > >
>  > > > > >Just one note: It's not secure to add AA_CP_Session to urls
>>  > > outside of
>>  > > > >AA Admin interface (like in FAQ). If there is any link to any
>>  > > other
>>  > > > >webpage (in FAQ), it is possible to get your session id
>>  > > (AA_CP_Session)
>>  > > > >from 'Referer' field. With this id (or url) you are able to
>>  > > access AA
>>  > > > >admin pages without login (for 3 hours, when session id
>>  > > expires).
>>  > > > >
>>  > > > >I would probably prefer to create the link without the session
>>  > > id (with
>>  > > > >f_e) as default (so users have to log in on every item edit)
>>  > > and then
>>  > > > >maybe create optional f_e for those admins, who knows about
>>  > > this problem
>>  > > > >and don't care. At least we have to mention it in the FAQ.
>>  > > > >
>>  > > > >What you think?
>>  > > > >
>>  > > > >    Honza
>>  > > > >
>>  > > > >>  - Mitra
>>  > > > >>
>>  > > > >>
>>  > > > >>
>>  > > > >>  01/12/02 - changed site module to go to prior sibling when
>  > > > deleting
>  > > > > >>  rather than parent
>>  > > > >>  01/12/02 - added default $item=null to new_unalias_recurent
>>  > > to allow
>>  > > > >>  calling from site module without warnings
>>  > > > >>  01/12/02 - fixed adding AA_CP_Session to url in site module
>>  > > AAPage
>>  > > > >>  where it is already there.
>>  > > > >>  01/12/02 - changes to allow _#EDITITEM to be used outside of
>>  > > admin interface
>>  > > > >>  01/12/02 - combined several ways of redirecting to a URL
>>  > > into common
>>  > > > >>  function go_return_or_url
>>  > > > >
>>  > > > >
>>  > > > >
>>  > > > >-------------------------------------------------------
>>  > > > >This SF.NET email is sponsored by:
>>  > > > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2
>>  > > See!
>>  > > > >http://www.vasoftware.com
>>  > > > >_______________________________________________
>>  > > > >Apc-aa-coders mailing list
>>  > > > >Apc...@li...
>>  > > > >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>  > > >
>>  > >
>>  > >
>>  > >
>>  > > -------------------------------------------------------
>>  > > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>>  > > are you planning your Web Server Security? Click here to get a
>>  > > FREE
>>  > > Thawte SSL guide and find the answers to all your  SSL security
>>  > > issues.
>>  > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>>  > > _______________________________________________
>>  > > Apc-aa-coders mailing list
>>  > > Apc...@li...
>>  > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>  > --
>>  > Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>>  > 02-6684-8096  or 0414-648-0722
>>  > Life is a Mystery to be Lived, not a Problem to be Solved
>>
>>
>>
>>  --
>>  Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>>  02-6684-8096  or 0414-648-0722
>>
>>  Life is a Mystery to be Lived, not a Problem to be Solved
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved

Re: [Apc-aa-coders] Changes: site module, edititem,

[Honza M. <hon...@ec...>]

Sorry for no response. I think the addition AA_CP_Session in cache
str2find string could help. 

On the other hand, you probably know I'm not freind of exporting
AA_CP_Session outside of AA Admin interface (referer problem, ...), so I
will probably encourage Econnect's administrators to not use this
feature on our servers. It doesn't mean I do not want this feature in AA
- I just want to mention possible problems in the FAQ - the ussage of
such feature is then up to admins.

   Honza


On St, 2003-01-29 at 00:04, Mitra wrote:
> Honza -
> 
> I don't see a reply to this ... do you think adding the AA_CP_Session
> to the cache string is a good idea?
> 
> - Mitra
> 
> 
> At 9:34 PM +1100 20/1/03, Mitra wrote:
> > Hmmm -
> > This is a good point,
> > One alternative would be to add the AA_CP_Session to the cache
> > string,
> > Even if this is not sufficient, this is something we need to do.
> > What do you think?
> > - Mitra
> > At 10:50 AM +0100 20/1/03, Honza Malik wrote: 
> > > I found another, much more serious problem in this - caching.
> > > 
> > > If I update an item on such page (you can test on FAQ), then new
> > > page is
> > > generated from database and my AA_CP_Session id is added. BUT,
> > > this page
> > > is CACHED (internaly in AA for both - slice.php3 as well as for
> > > view.php3), so EVERYONE who is going to the page obtain the page
> > > from
> > > cache WITH MY SESSION ID.
> > > 
> > > I think we really have to remove export AA_CP_Session ids outside
> > > of
> > > Admin interface.
> > > 
> > >    Honza
> > > 
> > > On Ne, 2003-01-12 at 22:11, Mitra wrote:
> > > > Its a good point, I was trying to think of security holes in it.
> > > >
> > > > I think this is a bit of a non-worry for a number of reasons.
> > > > 1: Most browsers don't send referer URLs any more - really
> > > annoying
> > > > when you are trying to track things down.
> > > > 2: The hacker would have to be on a site you linked to, and
> > > react
> > > > within three hours.
> > > >
> > > > I just don't see this as a big security hole.
> > > >
> > > > - Mitra
> > > >
> > > >
> > > > At 10:05 PM +0100 12/1/03, Honza Malik wrote:
> > > > >On Ne, 2003-01-12 at 02:08, Mitra wrote:
> > > > >>  The biggest change is that _#EDITITEM should now work in
> > > most cases
> > > > >>  outside of the admin interface, with the user being prompted
> > > for a
> > > > >>  userid/password and then returned back to where they came
> > > from.
> > > > >
> > > > >It's nice. Thanks Mitra.
> > > > >
> > > > >Just one note: It's not secure to add AA_CP_Session to urls
> > > outside of
> > > > >AA Admin interface (like in FAQ). If there is any link to any
> > > other
> > > > >webpage (in FAQ), it is possible to get your session id
> > > (AA_CP_Session)
> > > > >from 'Referer' field. With this id (or url) you are able to
> > > access AA
> > > > >admin pages without login (for 3 hours, when session id
> > > expires).
> > > > >
> > > > >I would probably prefer to create the link without the session
> > > id (with
> > > > >f_e) as default (so users have to log in on every item edit)
> > > and then
> > > > >maybe create optional f_e for those admins, who knows about
> > > this problem
> > > > >and don't care. At least we have to mention it in the FAQ.
> > > > >
> > > > >What you think?
> > > > >
> > > > >    Honza
> > > > >
> > > > >>  - Mitra
> > > > >>
> > > > >>
> > > > >>
> > > > >>  01/12/02 - changed site module to go to prior sibling when
> > > deleting
> > > > >>  rather than parent
> > > > >>  01/12/02 - added default $item=null to new_unalias_recurent
> > > to allow
> > > > >>  calling from site module without warnings
> > > > >>  01/12/02 - fixed adding AA_CP_Session to url in site module
> > > AAPage
> > > > >>  where it is already there.
> > > > >>  01/12/02 - changes to allow _#EDITITEM to be used outside of
> > > admin interface
> > > > >>  01/12/02 - combined several ways of redirecting to a URL
> > > into common
> > > > >>  function go_return_or_url
> > > > >
> > > > >
> > > > >
> > > > >-------------------------------------------------------
> > > > >This SF.NET email is sponsored by:
> > > > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2
> > > See!
> > > > >http://www.vasoftware.com
> > > > >_______________________________________________
> > > > >Apc-aa-coders mailing list
> > > > >Apc...@li...
> > > > >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> > > >
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> > > are you planning your Web Server Security? Click here to get a
> > > FREE
> > > Thawte SSL guide and find the answers to all your  SSL security
> > > issues.
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > > _______________________________________________
> > > Apc-aa-coders mailing list
> > > Apc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> > --
> > Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> > 02-6684-8096  or 0414-648-0722 
> > Life is a Mystery to be Lived, not a Problem to be Solved
> 
> 
> 
> -- 
> Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> 02-6684-8096  or 0414-648-0722 
> 
> Life is a Mystery to be Lived, not a Problem to be Solved
> 

Re: [Apc-aa-coders] Changes: site module, edititem,

[Mitra <mi...@mi...>]

Honza -

I don't see a reply to this ... do you think adding the AA_CP_Session 
to the cache string is a good idea?

- Mitra


At 9:34 PM +1100 20/1/03, Mitra wrote:
>Hmmm -
>
>This is a good point,
>
>One alternative would be to add the AA_CP_Session to the cache string,
>
>Even if this is not sufficient, this is something we need to do.
>
>What do you think?
>
>- Mitra
>
>
>At 10:50 AM +0100 20/1/03, Honza Malik wrote:
>>I found another, much more serious problem in this - caching.
>>
>>If I update an item on such page (you can test on FAQ), then new page is
>>generated from database and my AA_CP_Session id is added. BUT, this page
>>is CACHED (internaly in AA for both - slice.php3 as well as for
>>view.php3), so EVERYONE who is going to the page obtain the page from
>>cache WITH MY SESSION ID.
>>
>>I think we really have to remove export AA_CP_Session ids outside of
>>Admin interface.
>>
>>    Honza
>>
>>On Ne, 2003-01-12 at 22:11, Mitra wrote:
>>>  Its a good point, I was trying to think of security holes in it.
>>>
>>>  I think this is a bit of a non-worry for a number of reasons.
>>>  1: Most browsers don't send referer URLs any more - really annoying
>>>  when you are trying to track things down.
>>>  2: The hacker would have to be on a site you linked to, and react
>>>  within three hours.
>>>
>>>  I just don't see this as a big security hole.
>>>
>>>  - Mitra
>>>
>>>
>>>  At 10:05 PM +0100 12/1/03, Honza Malik wrote:
>>>  >On Ne, 2003-01-12 at 02:08, Mitra wrote:
>>>  >>  The biggest change is that _#EDITITEM should now work in most cases
>>>  >>  outside of the admin interface, with the user being prompted for a
>>>  >>  userid/password and then returned back to where they came from.
>>>  >
>>>  >It's nice. Thanks Mitra.
>>>  >
>>>  >Just one note: It's not secure to add AA_CP_Session to urls outside of
>>>  >AA Admin interface (like in FAQ). If there is any link to any other
>>>  >webpage (in FAQ), it is possible to get your session id (AA_CP_Session)
>>>  >from 'Referer' field. With this id (or url) you are able to access AA
>>>  >admin pages without login (for 3 hours, when session id expires).
>>>  >
>>>  >I would probably prefer to create the link without the session id (with
>>>  >f_e) as default (so users have to log in on every item edit) and then
>>>  >maybe create optional f_e for those admins, who knows about this problem
>>  > >and don't care. At least we have to mention it in the FAQ.
>>  > >
>>  > >What you think?
>>  > >
>>  > >    Honza
>>  > >
>>  > >>  - Mitra
>>  > >>
>>  > >>
>>>  >>
>>>  >>  01/12/02 - changed site module to go to prior sibling when deleting
>>>  >>  rather than parent
>>>  >>  01/12/02 - added default $item=null to new_unalias_recurent to allow
>>>  >>  calling from site module without warnings
>>>  >>  01/12/02 - fixed adding AA_CP_Session to url in site module AAPage
>>>  >>  where it is already there.
>>>  >>  01/12/02 - changes to allow _#EDITITEM to be used outside of 
>>>admin interface
>>>  >>  01/12/02 - combined several ways of redirecting to a URL into common
>>>  >>  function go_return_or_url
>>>  >
>>>  >
>>  > >
>>  > >-------------------------------------------------------
>>  > >This SF.NET email is sponsored by:
>>  > >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>  > >http://www.vasoftware.com
>>>  >_______________________________________________
>>>  >Apc-aa-coders mailing list
>>>  >Apc...@li...
>>>  >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>>are you planning your Web Server Security? Click here to get a FREE
>>Thawte SSL guide and find the answers to all your  SSL security issues.
>>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>>_______________________________________________
>>Apc-aa-coders mailing list
>>Apc...@li...
>>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>
>
>--
>Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
>02-6684-8096  or 0414-648-0722 
>
>Life is a Mystery to be Lived, not a Problem to be Solved


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved

[Apc-aa-coders] Re: PHPdoc like comments

[Mitra <mi...@mi...>]

At 7:06 PM +0100 28/1/03, Jakub Adamek wrote:
>your code in include/zids.php3 is nice formatted and commented. I 
>only do not understand why you did not use the PHPdoc formatting 
>described in this list? Are you going to use it in the future or do 
>you have some reason against?

I didn't know that a decision had been made on this, we had a 
conversation on coding standards, but it didn't get concluded - I do 
not have the email in front of me. My basic opinion is that formal 
doc standards are NOT particularly useful, since they usually 
document the obvious, and do not document the subtle stuff which is 
what really needs recording.

If we are using PHPdoc - or any other coding standards - and they (or 
a link to them) are posted to the FAQ, then I'll be happy to follow 
them and to update zids.php3 and stringexpand.php3 to follow them. At 
this point I don't have a pointer to the PHPdoc rules.

>
>And I didn't find a remark about the author (which I assume is just 
>you) of the file.

Thanks for pointing it out, comment added ...

-  Mitra


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved