phplib-users — A list for users of phplib to talk / discuss phplib

Re: [Phplib-users] DB class

[Richard A. <rh...@ju...>]

At 2:17 PM +0200 5/9/01, Guenther Theilen wrote:

>I've got a table with about 100 columns (value either 0 or 1).
>Now I choose exactly one row with $db->query ("SELECT...")
>For each column there is a picto. The name of the picto is
>name_of_column.gif
>I want to show all the pictos where the value in the column is 1.
>Of course one way would be like this:
>$test=$db->f("foo")
>if ($test==1)
>   {show foo.gif}
>
>With about 100 columns which even might change in the next time, this
>seems quite complicated to me.
>Is there a more elegant way to get the names of the coloumns where the
>value is 1 out of $db?


Hi Guenther,

I see you have a solution already, but for the record, this is how I
would go about this:

<?php
error_reporting(2047);

/*
  # Database definition including sample data:
  #
  # MySQL dump 6.6
  #
  # Host: localhost    Database: j0
  #--------------------------------------------------------
  # Server version        3.23.7-alpha-log

  #
  # Table structure for table 'idtable'
  #
  CREATE TABLE idtable (
    id int(11) DEFAULT '0' NOT NULL,
    foo int(11) DEFAULT '0' NOT NULL,
    PRIMARY KEY (id,foo)
  );

  #
  # Dumping data for table 'idtable'
  #

  INSERT INTO idtable VALUES (1,2);
  INSERT INTO idtable VALUES (2,1);
  INSERT INTO idtable VALUES (3,1);
  INSERT INTO idtable VALUES (3,2);
  INSERT INTO idtable VALUES (3,3);
  INSERT INTO idtable VALUES (3,4);

  #
  # Table structure for table 'footable'
  #
  CREATE TABLE footable (
    foo int(11) DEFAULT '0' NOT NULL,
    gif char(12),
    PRIMARY KEY (foo)
  );

  #
  # Dumping data for table 'footable'
  #

  INSERT INTO footable VALUES (1,'foo1.gif');
  INSERT INTO footable VALUES (2,'foo2.gif');
  INSERT INTO footable VALUES (3,'foo3.gif');

*/

  include "db_mysql.inc";
  $db = new DB_Sql;

  echo "<pre>\n";

  for ($cc = 1; $cc <=3 ; $cc++) {
    $db->query("select idtable.id, idtable.foo, footable.gif " .
               "from idtable, footable " .
               "where idtable.id=$cc and footable.foo=idtable.foo");
    while ($db->next_record()) {
      echo " id = " . $db->Record["id"] . "\n";
      echo "foo = " . $db->Record["foo"] . "\n";
      echo "gif = " . $db->Record["gif"] . "\n";
      echo "\n";
    }
  }

  echo "</pre>\n";

?>

Re: [Phplib-users] phpLib Wrapper for PEAR

[Bob B. <bo...@iN...>]

Hi --

Preliminary results of PEAR vs phpLib timing tests ... each function did a 
basic SELECT plus a sys-procedure look-up-and-query, and the function was 
repeated 100 times in a set.  The sets of 100 have themselves been repeated 
several times, and the results are within 2/10,000ths of a second for each 
function over a total of about 10,000 queries.  The straight connection to 
the database (not a p_connect) was not timed ...

         PEAR            0.0058 seconds each over a set of 100
         phpLib          0.0062 seconds each over a set of 100

Each function, repeated 100 times, performed the following steps on a MySQL 
database table where field1 is the Primary Key and field10 and field11 are 
each keys. "$timer" is a class which returns microsecond elapsed times, 
"proc()" looks up the requested sys procedure, and "execproc()" inserts the 
variables then executes the query.

<PSEUDOCODE>
   $timer->start()
   SELECT field1,field4,field10,field11 FROM table ORDER BY field1 LIMIT 10
   seek(2)
   proc("dailySummaryAll")
   $argv = array(LONGDATE=>"0901",SHORTDATE=>"901")
   execproc($argv)
   $timer->stop()
   $runTot += $timer->gettime()
</PSEUDOCODE>

Next up: we'll time connections, then inserts, joins and heavier 
calculations ...

We're doing this because the "complaints" about PEAR being slower didn't 
seem to bear out, based on "gut feelings".  So we're doing head-to-head 
tests with PHP4 on a production server with MySQL ...

Any suggestions, requests, thoughts, contrary results, ...???

Bob.

At 07:29 PM 9/4/01 -0700, you wrote:
>Hi --
>
>Has anyone actually written a class to use phpLib function names but with 
>PEAR classes doing the work ...?
>
>We worked one up late last month (including sys procedures), and have it 
>working just fine using the latest PEAR and its DB class with MySQL ... we 
>are going to do some apples-to-apples speed tests this week using scripts 
>on a production site which is quite db intensive.
>
>But if anyone else has worked on this, I'd love to swap scripts, or hear 
>of your experiences, problems, etc. ...
>
>Nothing like "just doing it" as the best way to decide whether to keep 
>developing dynamic web sites with PHP4, phpLib and MySQL, or to 
>incorporate PEAR ...
>
>Bob.
>
>
>_______________________________________________
>Phplib-users mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phplib-users

phplibWiki--databaseHowto, was--RE: [Phplib-users] DB class

[<bm...@14...>]

Hey Martin,

Would you like to put your code snippet on the phplibWiki

   http://phplibwiki.15gram.com/hm/wiki/wiki.php

under the databaseHowto section.

   http://phplibwiki.15gram.com/hm/wiki/wiki.php?edit=DatabaseHowto

If you have trouble, email me and I will put it on for you.
Trying the get the wiki started. It would be a great place
to collect all these gems, don't you think??

Regards
-bm

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of Martin
Larsen
Sent: Wednesday, September 05, 2001 7:43 AM
To: php...@li...
Subject: Fw: [Phplib-users] DB class


Sorry.. Forgot to forward this to the list also. :-(


> Hi Guenther...
>
> > With about 100 columns which even might change in the next time,
> this
> > seems quite complicated to me.
> > Is there a more elegant way to get the names of the coloumns where
> the
> > value is 1 out of $db?
>
> foreach($db->Record as $key=>$val) {
>     if ($val == 1) {
>         show($key . '.gif');
>    }
> }
>
> Just from the top of my head. :-) But atleast it should give you a
> hint of a direction you could try.
>
> Regards,
> Martin
>

_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

Re:[Phplib-users] DB class

[Guenther T. <th...@eq...>]

Hi Martin,

you wrote:

>> foreach($db->Record as $key=>$val) {
>>     if ($val == 1) {
>>         show($key . '.gif');
>>    }
>> }
>>
>> Just from the top of my head. :-) But atleast it should give you a
>> hint of a direction you could try.

It did... ;-)
Works perfectly. Thanks.

Guenther

Fw: [Phplib-users] DB class

[Martin L. <mar...@ho...>]

Sorry.. Forgot to forward this to the list also. :-(


> Hi Guenther...
>
> > With about 100 columns which even might change in the next time,
> this
> > seems quite complicated to me.
> > Is there a more elegant way to get the names of the coloumns where
> the
> > value is 1 out of $db?
>
> foreach($db->Record as $key=>$val) {
>     if ($val == 1) {
>         show($key . '.gif');
>    }
> }
>
> Just from the top of my head. :-) But atleast it should give you a
> hint of a direction you could try.
>
> Regards,
> Martin
>

[Phplib-users] DB class

[Guenther T. <th...@eq...>]

Hi,

I've got a table with about 100 columns (value either 0 or 1).
Now I choose exactly one row with $db->query ("SELECT...")
For each column there is a picto. The name of the picto is
name_of_column.gif
I want to show all the pictos where the value in the column is 1.
Of course one way would be like this:
$test=$db->f("foo")
if ($test==1)
   {show foo.gif}

With about 100 columns which even might change in the next time, this
seems quite complicated to me.
Is there a more elegant way to get the names of the coloumns where the
value is 1 out of $db?


thanks
Guenther

-- 
eqi Web-Design + Infanterieweg 30 + 26129 Oldenburg
Tel: 0441 / 77 81 333   +   Fax: 0441 / 99 89 02 20
mailto:th...@eq...   +         http://www.eqi.de

[Phplib-users] phpLib Wrapper for PEAR

[Bob B. <bo...@iN...>]

Hi --

Has anyone actually written a class to use phpLib function names but with 
PEAR classes doing the work ...?

We worked one up late last month (including sys procedures), and have it 
working just fine using the latest PEAR and its DB class with MySQL ... we 
are going to do some apples-to-apples speed tests this week using scripts 
on a production site which is quite db intensive.

But if anyone else has worked on this, I'd love to swap scripts, or hear of 
your experiences, problems, etc. ...

Nothing like "just doing it" as the best way to decide whether to keep 
developing dynamic web sites with PHP4, phpLib and MySQL, or to incorporate 
PEAR ...

Bob.

[Phplib-users] PhplibWiki

[<bm...@14...>]

Hey guys!

Lately there were some talk about starting a wiki for phplib.
Here is one I just set up

 http://phplibwiki.15gram.com/

If someone else has already set up another wiki, please let me know
I'd rather support that and not cause confusion with dual efforts.

The wiki is currently mostly empty. If you see any mistakes do
let me know. Even better, go ahead and correct it.



Regards
-bm
bm...@14...

Re: [Phplib-users] Add db feature ?

[Chris J. <ch...@ch...>]

I agree that sequences are more important.

insert_id() is difficult to implement it reliably for all databases.  I've
never needed to use it for any project I've worked on, either.

..chris

----- Original Message -----
From: "Richard Archer" <rh...@ju...>


At 2:45 PM +0200 26/8/01, Guillaume Desclaux wrote:

>So, don't you think that we should add the function insert_id() in db
>class to retrieve easily the id generated by a query INSERT into table
>where the table key id is auto_increment ?

>From my point of view, it is much easier to maintain the code if all the
DB classes perform nextid() in the same manner. That said, the databases
which don't support table locking must implement nextid differently.

I think it is more important to implement sequences for the DB classes
that are missing them (ODBC most notably, but also mssql, msql and I
think some others). I plan to work on this today.

And besides, if it ain't broke, don't fix it ;)

 ...Richard.

[Phplib-users] (no subject)

[Marko K. <Mar...@mc...>]

Hi,

I am regularyly checking the list archives phplib-user at sourcefourge,
but still there is absolutely nothing displayed.

Does somebody know when this will eventually function?

Good to know that this list is closing down, but what about the new list?

Is it possibly necessary to subscribe to the list to be able to read it?
Maybe geocrawler is still not set up properly?

Thanks in advance,
Marko

                    O _ O
                     0 0
 ------------------m-\o/-m------------------------------------------
 Dr. Marko K"aning    ^          Tel/Fax: +49-89 6213 3367 / 2087
 OSRAM / FL-M                    email  : Mar...@mc...

[Phplib-users] VAL in active_sessions doesn`t change

[Kalle S. <ka...@ca...>]

Hi all,

having tried different versions of PHPLIB on different machines
(Win2k; Win98, freeBSD) I always end up with session tracking
running. But the Value of active_sessions VAL field doesn't change at all.

So I guess I missed a important point.
Any hints, where I schould look?

Thanks to all

Kalle

Re: [Phplib-users] Example_Session_Custom... missing arguments for ct_sql.inc ???

[Richard A. <rh...@ju...>]

At 9:41 AM -0700 29/8/01, Alan T. Miller wrote:

>I am trying to use the session4 custom in the local4.inc file from CVS.

Watch out, most of the stuff in the -devel CVS tree is still a little
rough around the edges.


>get the following error when I try to impliment a page with sessions using
>the custom storage:
>
>Warning: Missing argument 1 for ac_release_lock() in
>c:\inetpub\wwwroot\mydomain.com\php-lib\php\db\mysql\ct_sql.inc on line 42
>
>Warning: Missing argument 2 for ac_release_lock() in
>c:\inetpub\wwwroot\mydomain.com\php-lib\php\db\mysql\ct_sql.inc on line 42

This is because the ac_get_lock and ac_release_lock functions in
ct_sql.inc require two arguments:
  function ac_get_lock($name, $sid) {
  function ac_release_lock($name, $sid) {

yet user4.inc and session4_custom.inc all call that function with no
arguments at all:
      $this->that->ac_get_lock();
      $this->that->ac_release_lock();

Is it even necessary to perform locking if you're using PHP4 sessions?
I notice the calls to ac_get_lock and ac_release_lock are commented
out in session4.inc!

Post a bug to the SourceForge Bug Tracker (better yet, post a patch ;)

 ...Richard.

[Phplib-users] Example_Session_Custom... missing arguments for ct_sql.inc ???

[Alan T. M. <am...@ho...>]

I am trying to use the session4 custom in the local4.inc file from CVS. I
get the following error when I try to impliment a page with sessions using
the custom storage:

Warning: Missing argument 1 for ac_release_lock() in
c:\inetpub\wwwroot\mydomain.com\php-lib\php\db\mysql\ct_sql.inc on line 42

Warning: Missing argument 2 for ac_release_lock() in
c:\inetpub\wwwroot\mydomain.com\php-lib\php\db\mysql\ct_sql.inc on line 42


I looked up line 42 and see the following:

$query = sprintf("SELECT get_lock('%s-%s-%s')",
$this->database_lock_semaphore, $name, $sid);

I am assuming by this that the problem is in either the
"database_lock_semaphore variable because earlier it is defined as:

var $database_lock_semaphore = "";

and that wold mean it was blank. Or, the error is something that is just
beyond me.


Can someone help suggest something? I have been looking around trying to
figure out what is going on here. I think it has something to do with the
$database_lock_semaphore variable being blank, but after searching the
documentation, I cannot find anything on that or what it is.


Thanks in advance.

Alan

Re: [Phplib-users] Add db feature ?

[Richard A. <rh...@ju...>]

At 2:45 PM +0200 26/8/01, Guillaume Desclaux wrote:

>I know the function nextid($seq_name) in db class exists... but many
>databases implement their own sequence mechanism (like auto_increment in
>mysql, or sequence in Oracle, etc...)
>So, don't you think that we should add the function insert_id() in db
>class to retrieve easily the id generated by a query INSERT into table
>where the table key id is auto_increment ?

From my point of view, it is much easier to maintain the code if all the
DB classes perform nextid() in the same manner. That said, the databases
which don't support table locking must implement nextid differently.

I think it is more important to implement sequences for the DB classes
that are missing them (ODBC most notably, but also mssql, msql and I
think some others). I plan to work on this today.

And besides, if it ain't broke, don't fix it ;)

 ...Richard.

Re: [Phplib-users] Add db feature ?

[nathan r. h. <na...@ds...>]

On Sun, 26 Aug 2001, Guillaume Desclaux wrote:

> Hi,
>
> I know the function nextid($seq_name) in db class exists... but many
> databases implement their own sequence mechanism (like auto_increment in
> mysql, or sequence in Oracle, etc...)
> So, don't you think that we should add the function insert_id() in db
> class to retrieve easily the id generated by a query INSERT into table
> where the table key id is auto_increment ?
>

That's a MySQL specfic thing.  If you feel like it, you can add a method
last_id() for each DB class and use whatever native calls it takes to get
it, or emulate it if possible.  In reaility, db_sequence makes a whole lot
more sense for db portability and atomic operation.

-n
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
nathan hruby / digital statement
na...@ds...
http://www.dstatement.com/

Public GPG key can be found at:
http://www.dstatement.com/nathan-gpg-key.txt
ED54 9A5E 132D BD01 9103  EEF3 E1B9 4738 EC90 801B
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[Phplib-users] Add db feature ?

[Guillaume D. <gde...@pr...>]

Hi,

I know the function nextid($seq_name) in db class exists... but many
databases implement their own sequence mechanism (like auto_increment in
mysql, or sequence in Oracle, etc...)
So, don't you think that we should add the function insert_id() in db
class to retrieve easily the id generated by a query INSERT into table
where the table key id is auto_increment ?

Guillaume

Re: [Phplib-users] ACL auth/perm (was: preexisting perm integration)

[Ben C. <php...@be...>]

Just one minor thing... the package name is phpBugTracker. :)

On Sat, Aug 25, 2001 at 12:02:51PM +0200, giancarlo pinerolo wrote:
> There is a new class proposed for handling the auth on objects.
> It's in the CVS tree. 
> 
> this is its intructory message:
> http://www.geocrawler.com/lists/3/SourceForge/14160/0/6431668/
> 
> the classes in CVS are the acl_* ones
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phplib/php-lib/php/auth/
> 
> I looked at it, and for me that should go into the User class, for the
> reason I explain here
> http://www.geocrawler.com/lists/3/SourceForge/14160/0/6479265/
> 
> with three advantages:
> 
> - you untouch the Auth class, so leave place for integrating past-future
> packages/apps
> - you have a live representation of that, which for me is more a 'state'
> then a 'registered user credentials' (see my msg to phplib-core:
> - you are not forced to redump every live [auth] modification to that
> table (which is something you cannot pretend anyway to be done by
> phplib), because youll' find the latest 'live' representation in the
> USer class. This is what the author of PHPBugTraq found useful, 
> ( http://www.geocrawler.com/lists/4/Web/195/0/6466737/ )
> and recalls to that discussion with kk about 'what  and why should you
> keep fringes of data in the User array without dumping it to a
> structured table'. The conclusion is that mostly depens on
> stats/live_stats requirements...
> 
> 
> - Gian
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] ACL auth/perm (was: preexisting perm integration)

[giancarlo p. <gia...@na...>]

There is a new class proposed for handling the auth on objects.
It's in the CVS tree. 

this is its intructory message:
http://www.geocrawler.com/lists/3/SourceForge/14160/0/6431668/

the classes in CVS are the acl_* ones
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phplib/php-lib/php/auth/

I looked at it, and for me that should go into the User class, for the
reason I explain here
http://www.geocrawler.com/lists/3/SourceForge/14160/0/6479265/

with three advantages:

- you untouch the Auth class, so leave place for integrating past-future
packages/apps
- you have a live representation of that, which for me is more a 'state'
then a 'registered user credentials' (see my msg to phplib-core:
- you are not forced to redump every live [auth] modification to that
table (which is something you cannot pretend anyway to be done by
phplib), because youll' find the latest 'live' representation in the
USer class. This is what the author of PHPBugTraq found useful, 
( http://www.geocrawler.com/lists/4/Web/195/0/6466737/ )
and recalls to that discussion with kk about 'what  and why should you
keep fringes of data in the User array without dumping it to a
structured table'. The conclusion is that mostly depens on
stats/live_stats requirements...


- Gian

Re: [phplib] Re: [Phplib-users] preexisting perm integration

[giancarlo p. <gia...@na...>]

giancarlo pinerolo wrote:

> 
> Michael Bonfert wrote:
> >
> > Hi,
> >
> > apart from the auth and user problem we have to keep in mind that there
> > are different approaches to perm.
> > At present phplib has a level-based perm policy. Think about an object
> > based perm policy.
> >
> > e.g. a discussion board software with different boards. You have at least
> > 2 objecttypes board and boardmessages.
> > The boardmessages live in the context of their board. You have different
> > priv's on these objects. e.g.
> >     bboard_create_forum
> >     bboard_create_message
> >     bboard_write_forum
> >     bboard_write_message
> >     bboard_read_forum
> >     bboard_read_message
> >     bboard_delete_forum
> >     bboard_delete_message
> >     bboard_moderate_forum


I think that a 'privilege scheme on objects' presumes two things:

You have objects and groups of objects. Each object (or group of)
requires certain priv. So to each obj are associated a series of
'required privs'

Then you have users and groups of users. Each user or group has (can
prove to have) certain privs.

When you check the permission, you compare the list of 'required' privs
one one side, with the list of provided permissions by the user. And
this can risult in a third lst, which is what you can do on there.

Phplib can hold the permission/privs associated to the users. I am not
sure it will provide holding perms requirements for objects. It can hold
the third list above for each user, the result of the comparison between
an object's requirement list , ant that user provided permissions. In
practice which objects, after having compared the two, he can access.


And you can use phplib to get or set the permissions the user  will be
able to present to a requiring object.

You can write routines like

show_login_form_if_perms_are_NO_OK($userperms,$objperms)

but of course you have to write that.


Ant then objects as well belong to gropus, an probably the comparison
betwwen the twoo lists can be made on group belonging on both sides...

Gian

> >
> > Assume you have different boards (board1 and board2).
> >
> ...
> 
> Well, this is all very application specific. An authentication
> service/scheme whatever, can tell you or confirm you the identity, the
> group belonging, and give you a list of perms associated.  By perms I
> mean the 'names' of these perms. Nothing more. It can give you a method
> to check if 'a name of a certain perm' is associated with the user. It
> has not to take any further action though. That's the application realm.
> The fact that phplib somehow automatically handled out login forms is
> misleading.
> 
> And then consider that these 'perms on objects' are very fluid: for
> example I can have a perm on playing 'gameB' if I obtained as much
> scores to 'gameA'... The presence of any single checkbox can depend on a
> certain perm.. How can nphplib manage the 'enforcment' of that? The
> application is provided with a persistent per_user storage, you can keep
> there a list of the actual, live, user perms, or store an object of
> yours  that  hands these out... I mean, every condition, every 'if'
> statement,  is sortof a perm...
> 
> Giancarlo
> 
> > board1 ist moderated by user1, every user can read,create,write a message
> > but only the owner and moderator can delete a message.
> > user1 gets all priv. above on board1. Alle msgs of board1 live in the
> > context of board1 so these objects inherit the privs of board1 => the
> > moderator is able to delete all msgs of board1.
> > Other user have the common privs
> > bboard_read_forum,bboard_read_message,bboard_write_message.
> > 'bboard_delete_message' is assigned only to their own msgs.
> >
> > board2 is moderated by user2 ...
> >
> > This example shows that  permission is a little bit more complex than
> > level based.
> > 'Can this party perform this operation on this target'.
> >
> > There could also be other approaches to perm.
> > I think phplib should be open to integrate 'preexisting perms',  too.
> >
> > bye Michael
> >

Re: [Phplib-users] preexisting perm integration

[giancarlo p. <gia...@na...>]

Michael Bonfert wrote:
> 
> Hi,
> 
> apart from the auth and user problem we have to keep in mind that there
> are different approaches to perm.
> At present phplib has a level-based perm policy. Think about an object
> based perm policy.
> 
> e.g. a discussion board software with different boards. You have at least
> 2 objecttypes board and boardmessages.
> The boardmessages live in the context of their board. You have different
> priv's on these objects. e.g.
>     bboard_create_forum
>     bboard_create_message
>     bboard_write_forum
>     bboard_write_message
>     bboard_read_forum
>     bboard_read_message
>     bboard_delete_forum
>     bboard_delete_message
>     bboard_moderate_forum
> 
> Assume you have different boards (board1 and board2).
> 
...

Well, this is all very application specific. An authentication
service/scheme whatever, can tell you or confirm you the identity, the
group belonging, and give you a list of perms associated.  By perms I
mean the 'names' of these perms. Nothing more. It can give you a method
to check if 'a name of a certain perm' is associated with the user. It
has not to take any further action though. That's the application realm.
The fact that phplib somehow automatically handled out login forms is
misleading.

And then consider that these 'perms on objects' are very fluid: for
example I can have a perm on playing 'gameB' if I obtained as much
scores to 'gameA'... The presence of any single checkbox can depend on a
certain perm.. How can nphplib manage the 'enforcment' of that? The
application is provided with a persistent per_user storage, you can keep
there a list of the actual, live, user perms, or store an object of
yours  that  hands these out... I mean, every condition, every 'if'
statement,  is sortof a perm...

Giancarlo





> board1 ist moderated by user1, every user can read,create,write a message
> but only the owner and moderator can delete a message.
> user1 gets all priv. above on board1. Alle msgs of board1 live in the
> context of board1 so these objects inherit the privs of board1 => the
> moderator is able to delete all msgs of board1.
> Other user have the common privs
> bboard_read_forum,bboard_read_message,bboard_write_message.
> 'bboard_delete_message' is assigned only to their own msgs.
> 
> board2 is moderated by user2 ...
> 
> This example shows that  permission is a little bit more complex than
> level based.
> 'Can this party perform this operation on this target'.
> 
> There could also be other approaches to perm.
> I think phplib should be open to integrate 'preexisting perms',  too.
> 
> bye Michael
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] preexisting perm integration

[Michael B. <bon...@fi...>]

Hi,

apart from the auth and user problem we have to keep in mind that there
are different approaches to perm.
At present phplib has a level-based perm policy. Think about an object
based perm policy.

e.g. a discussion board software with different boards. You have at least
2 objecttypes board and boardmessages.
The boardmessages live in the context of their board. You have different
priv's on these objects. e.g.
    bboard_create_forum
    bboard_create_message
    bboard_write_forum
    bboard_write_message
    bboard_read_forum
    bboard_read_message
    bboard_delete_forum
    bboard_delete_message
    bboard_moderate_forum

Assume you have different boards (board1 and board2).

board1 ist moderated by user1, every user can read,create,write a message
but only the owner and moderator can delete a message.
user1 gets all priv. above on board1. Alle msgs of board1 live in the
context of board1 so these objects inherit the privs of board1 => the
moderator is able to delete all msgs of board1.
Other user have the common privs
bboard_read_forum,bboard_read_message,bboard_write_message.
'bboard_delete_message' is assigned only to their own msgs.


board2 is moderated by user2 ...


This example shows that  permission is a little bit more complex than
level based.
'Can this party perform this operation on this target'.

There could also be other approaches to perm.
I think phplib should be open to integrate 'preexisting perms',  too.

bye Michael

Re: [Phplib-users] Re: [phplib] current users?

[Chris J. <ch...@ch...>]

----- Original Message -----
From: "Kristian Koehntopp" <kr...@ko...>
To: "Adam Robertson" <ad...@ra...>
Cc: "'giancarlo pinerolo'" <gia...@na...>;
<ph...@li...>; "'phplib-users'"
<php...@li...>
Sent: Wednesday, August 22, 2001 3:11 PM
Subject: [Phplib-users] Re: [phplib] current users?


On Wed, Aug 22, 2001 at 06:07:54PM +0100, Adam Robertson wrote:
> Thats on IE anyway, dunno about nutscrape but does anyone really use it
> anymore?

Just because the use at my employer's main web site is so odd, here's the
Analog stats for it :-)

Listing browsers, sorted by the number of requests.

   reqs: browser
-------: -------
1088683: Netscape
 336760: MSIE
     72: SpaceBison
     18: Netscape (compatible)

Listing the first 20 browsers by the number of requests, sorted by the
number of requests.

  reqs: browser
------: -------
414663: Mozilla/4.7 [en] (WinNT; U)
406999: Mozilla/4.08 [en] (WinNT; I ;Nav)
140610: Mozilla/4.08 [en] (Win95; U ;Nav)
 98166: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
 70737: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
 30758: Mozilla/4.0 (compatible; MSIE 5.01; Windows 95)
 27882: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
 27115: Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)
 25850: Mozilla/4.61 [en] (Win95; U)
 24614: Mozilla/4.06 [en] (Win95; U ;Nav)
 22456: Mozilla/4.0 (compatible; MSIE 5.5; Windows 95)
 17198: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)
 10615: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
  9325: Mozilla/4.74 [en] (Win98; U)
  8899: Mozilla/4.08 [en] (Win98; U ;Nav)
  6859: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
  6719: Mozilla/4.73 [en] (Win98; U)
  6159: Mozilla/4.08 [en] (Win95; I ;Nav)
  6042: Mozilla/4.07 [en] (Win95; I ;Nav)
  6033: Mozilla/4.08 [en] (WinNT; U ;Nav)

Re: [Phplib-users] phplib app integration

[giancarlo p. <gia...@na...>]

Stephen Woodbridge wrote:
...
> 
> An application is accessible by an authorized user.
> An application provides access based on the authorization level of the
> user.
> Different application need to have different authorization levels for
> its users.
> A single user might have different authorization levels depending on the
> application.
> The information to define a user is different for different apps.

I am supposing that we are having user/groups/perms, as in a new design
see:
http://www.geocrawler.com/archives/3/195/2001/7/150/6234214/

With such, you could set a new group, 'bugtraq users', with permissions
'users' (or add the user to a group 'users' with permissions
'bugtraq_users', or both) 
That design doesn't actually allows to add groups to groups, but maybe
is better. Too much confusion then.

A single user can belong to more than a group and more than one
permission can be assigned to each individual users or to groups.


> 
>     I think this much is correct, did I miss anything?
> 
> This seems to imply that phplib needs a generic Auth module that is
> application and user independent - its job would be to asertain if a
> user is how they say they are via their password, then return there
> unique user id.
> 

It is already so.

> Applications need to register themselves at installation with the Auth
> module and define there authorization levels.

I'd say that the admin should add the groups and perms the installation
needs.

> 
> There needs to be a generic User module the defines and or updates a
> user and assigns him a unique id. If the user already has an identity,
> then he can login and only update those fields that are required for the
> new application.

This part is missing. How to automate the differences in what is
required by different apps is hard. If the sites only requires name and
email, and appA requires address, an user that is already registered
should complete his  registration info to use appA. That is add the
address which is missing..

> 
> There needs to be a way for an application create a new user or extend
> an existing user to be authorized at some level for that application.
> 

For an application, I wouldn't pretend phplib to be able to do this. I
see difficult here anyway. This has to be done. Some major stuff should
go in the auth_user table (or related, because someoe keeps the
auth_user table at minimum, and join it to other user_related tables, eg
user_anagraphic, user_history, etc.) Minor stuff could have a place in
the $user->$BigBagName[app] array as user persistent stuff. Stuff that
wouldn be too much needed for stats.

> Applications need to register user specific data they might want to
> store for a user with the user module if there is a common one used by
> all apps.

As I said, here is only a questio of using the same class name and top
data contaner name. Avoid the intialization of user stored objects by
extended methods of th user class. Use application methods. In practice
use only the name and root container structure of the user class. Write
the methods that treat this data in the application, not as new methods
of the user class.

> 
> Then you have a common user login that will allow him/her to move
> between authorized applications.
> 

Hopefully

> This also seems to imply that the application does not nessisarily own
> the User of the Auth tables and they might not been in the same database
> as the application tables, especially if there are multiple databases.

Recomandable. I like this. It can use an Auth class whose name is a
defined constant, not even knows the name of the Auth class (and the
User and session class BTW...) 
Dreams?

- Gian

> 
> This is grain for the mill, feel free to grind it up :)
> 
> -Steve

Re: [phplib] Re: [Phplib-users] Re: preexisting auth integration

[Ben C. <php...@be...>]

Yeah, I was meaning a table full of users, not the actual arrays.  I'll be putting some thinking into this over the weekend (and pushing back my next release a little) to add some flexibility to my auth in phpbt.

On Fri, Aug 24, 2001 at 12:29:16AM +0200, giancarlo pinerolo wrote:
> giancarlo pinerolo wrote:
> > 
> > Ben Curtis wrote:
> > 
> > > So, that was a tangent, and certainly work in easing integration b/w phplib-based apps is needed... but back to phpbugtracker. :)  I probably should break out the username/login and email address into separate fields, giving the admin flexibility to choose whether or not to use the email address as the login.  I think the changes will appear sometime in the next few weeks, so maybe I'll report back and have you critique it again. :)  Of course, that still leaves the question of how to nicely get a pre-existing app's user list into phpbt and vice-versa...
> > >
> 
> Sorry. I supposed here, by 'pre-existing app's user list', you meant the
> array struct, the user persistent slice of data. 
> 
> > 
> > Here the ideas come to a bitter end... but here is less important,
> > because we are talking about per_user data, not per_site authentication.
> > What can I say... if you put it all under an array in user, naming the
> > array an the class something uniquely findable by a mass search  &
> > replace, th eadmin can have an easier life.
> 
> If, with 'pre-existing app's user list', you intended the  list of users
> in the site's phplib 'auth_user' table, once your app respects the 3 or
> 4 fields definitions necessary to phplib auth, user_id, username,
> password etc, (you can add extra table fields though), it uses that same
> table. Or vv. the admin uses phpbt auth_user table to add his future
> users, if he's new to phplib. Of course this all presumes that one wants
> to merge all his users, and differencing them by other means (eg the
> existance of a user's persistant phpbt array). I wouldn't like to have
> as many users tables as applications. But I don't know all the cases.. 
> 
> G
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [phplib] Re: [Phplib-users] Re: preexisting auth integration

[giancarlo p. <gia...@na...>]

giancarlo pinerolo wrote:
> 
> Ben Curtis wrote:
> 
> > So, that was a tangent, and certainly work in easing integration b/w phplib-based apps is needed... but back to phpbugtracker. :)  I probably should break out the username/login and email address into separate fields, giving the admin flexibility to choose whether or not to use the email address as the login.  I think the changes will appear sometime in the next few weeks, so maybe I'll report back and have you critique it again. :)  Of course, that still leaves the question of how to nicely get a pre-existing app's user list into phpbt and vice-versa...
> >

Sorry. I supposed here, by 'pre-existing app's user list', you meant the
array struct, the user persistent slice of data. 

> 
> Here the ideas come to a bitter end... but here is less important,
> because we are talking about per_user data, not per_site authentication.
> What can I say... if you put it all under an array in user, naming the
> array an the class something uniquely findable by a mass search  &
> replace, th eadmin can have an easier life.

If, with 'pre-existing app's user list', you intended the  list of users
in the site's phplib 'auth_user' table, once your app respects the 3 or
4 fields definitions necessary to phplib auth, user_id, username,
password etc, (you can add extra table fields though), it uses that same
table. Or vv. the admin uses phpbt auth_user table to add his future
users, if he's new to phplib. Of course this all presumes that one wants
to merge all his users, and differencing them by other means (eg the
existance of a user's persistant phpbt array). I wouldn't like to have
as many users tables as applications. But I don't know all the cases.. 

G