phplib-users

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

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

What I propose is to make Auth a very aseptic class. Kind of
client-server. Loosely coulpled. No html ouptut, no form handling. That
stuff should be handled, eventually, by the application, maybe in
page.inc. (if it is a web
application... Auth has to be a more abstract concept). 
If we think to auth as a client-server commodity, what requests auth
(the application), is the client. PHPlib Auth is the server. So Client
(application) side, anyway

And every login/logout being written in a log file

This would solve all the problems with poping-out pages,
back/cancel-login buttons, log/reg mode. In the sense that these have to
be handled application-side.

I have already tranformed it this way,, for my use.

I got some ideas from 
http://www-106.ibm.com/developerworks/webservices/library/ws-xpc2/
and
http://www-106.ibm.com/developerworks/webservices/library/ws-xpc2/listing2.html


Basically three methods:

authenticate (an alias for start())
get_account_info
set_account_info

I wrote a lot about this ("Auth: I will not give up on this") on
phplib-core, but nobody commented.
PEAR Auth is wrong too, in this light, because it handles form output,
with
error message, etc

I attach the auth.inc I have been playing with a few hours only (not too
checked..), and page inc.

Giancarlo


Kristian Koehntopp wrote:
> 
> On Tue, Aug 21, 2001 at 10:32:21PM -0700, Bryan McGuire wrote:
> > Due to the stateless nature of http, this is dodgy at best.  You
> > understand this, and you need to educate your client on the nature of
> > http and its limitations.  Suppose that I am browsing an online store
> > and  the phone  rings.
> 
> While you cannot tell who is currently "online" due to the
> stateless nature of http, you could in theory tell which users
> currently have valid authentications. PHPLIB does not properly
> support this, though, because this is a vertical query and
> PHPLIB keeps authentication data in a unstructured session BLOB
> which does not lend itself well to any kind of vertical query.
> 
> We already had a similar discussion a few weeks ago on this
> list.
> 
> If you want to be able to answer such questions as "how many
> users are currently authenticated", you need to keep
> authentication data outside of the session BLOB in a structured
> table. Only then you will be able to run vertical queries on
> such data efficiently. This is effectively a major rewrite of
> Auth, or a very large subclass of Auth.
> 
> Kristian
> 
> --
> Abbestellen mit Mail an:   php...@li...
> Kommandoliste mit Mail an: php...@li...

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

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

Layne Weathers wrote:

> When I implemented this, I found I had to collate times. On Windows, most
> browsers open new windows as a separate process (with separate session
> cookies), 

What? Can't beleive that. 

> For my purpose, I chose to count multiple logins on one session id as a
> single login.

Here you contradict your previuos assertion, because you say 'one
session id'...

I'll have to try this with the IE next reboot.
That'd break everything... 

- Gian

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

[Adam R. <ad...@ra...>]

> > When I implemented this, I found I had to collate times. On
> Windows, most
> > browsers open new windows as a separate process (with
> separate session
> > cookies),
>
> What? Can't beleive that.
>

If you open a new window with ALT+N or from the FILE menu or via a link you
will have the same cookie. If you start a new copy of IE from the start menu
or an icon you will get a new one.

Thats on IE anyway, dunno about nutscrape but does anyone really use it
anymore?

HTH
Adam

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

[Kristian K. <kr...@ko...>]

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?

http://www.koehntopp.de/zugriffe/usage_200107.html#TOPAGENTS

1	432130	43.32%	MSIE 5
2	169736	17.02%	HTTrack 3
3	 88557	 8.88%	Mozilla/4
4	 59988	 6.01%	HTTrack 2
5	 35299	 3.54%	MSIE 6
6	 19837	 1.99%	MSIE 3
7	 14102	 1.41%	Scooter-W3-1.0
8	 13586	 1.36%	Mozilla/3
9	 11283	 1.13%	WebZIP/3.80 (http://www.spidersoft.com)
10	  9911	 0.99%	MSIE 4
11	  9110	 0.91%	Konqueror/2
12	  9002	 0.90%	Mozilla/5
13	  7488	 0.75%  WebCopier v.2.2
14	  7340	 0.74%	TV33_Mercator_1-1.0
15	  6663	 0.67%	Teleport Pro/1.29
16	  6028	 0.60%	ArchitextSpider
17	  5535	 0.55%	Wget/1.5.0
18	  5501	 0.55%	Mozilla/3.01 (compatible;)
19	  5000	 0.50%  Googlebot/2.1 (+http://www.googlebot.com/bot.html)
20	  4984	 0.50%	Offline Explorer/1.9

Total Hits	  997528
Total Files	  784443
Total Pages	  629136
Total KBytes	13108042

Kristian

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)

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

[Kristian K. <kr...@ko...>]

On Wed, Aug 22, 2001 at 06:52:47PM +0200, giancarlo pinerolo wrote:
> I'll have to try this with the IE next reboot.

MSIE and Exlorer can be configured to run each window in a
separate subprocess or as a threaded single-process image. Be
sure you find that setting and to verify how it is set.

Kristian

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

[Stephen W. <wo...@me...>]

giancarlo pinerolo wrote:
> 
> What I propose is to make Auth a very aseptic class. Kind of
> client-server. Loosely coulpled. No html ouptut, no form handling. That
> stuff should be handled, eventually, by the application, maybe in

[snip large and useful post]

I am sorry, I did not comment earlier, but I thought you were right on
track with your ideas and suggestions.

I have wanted to create a login capability similar to PHP-Nuke (ie:
login form on the pages rather than a separate page) for my phplib
applications. I will try to use your ideas and the code you supplied on
your post here.

Thank you for your efforts and contibutions to the list.

-Steve

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

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

For all the discussion about this type of functionality on this phplib list and the previous one, it's really not that difficult to implement.  I have a login area on every page with my application, phpBugTracker (http://phpbt.sourceforge.net/).  All you have to do is use the default auth and handle the login form yourself instead of relying on auth_loginform().

On Wed, Aug 22, 2001 at 09:00:07AM -0400, Stephen Woodbridge wrote:
> giancarlo pinerolo wrote:
> > 
> > What I propose is to make Auth a very aseptic class. Kind of
> > client-server. Loosely coulpled. No html ouptut, no form handling. That
> > stuff should be handled, eventually, by the application, maybe in
> 
> [snip large and useful post]
> 
> I am sorry, I did not comment earlier, but I thought you were right on
> track with your ideas and suggestions.
> 
> I have wanted to create a login capability similar to PHP-Nuke (ie:
> login form on the pages rather than a separate page) for my phplib
> applications. I will try to use your ideas and the code you supplied on
> your post here.
> 
> Thank you for your efforts and contibutions to the list.
> 
> -Steve
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phplib-users

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

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

Ben Curtis wrote:
> 
> For all the discussion about this type of functionality on this phplib list and the previous one, it's really not that difficult to implement.  I have a login area on every page with my application, phpBugTracker (http://phpbt.sourceforge.net/).  All you have to do is use the default auth and handle the login form yourself instead of relying on auth_loginform().

I suppose you mean 'auth_preauth' instead of 'default auth'..

Thatì's Ok. but when someone installs your package on a site that
already has phplib, but doesn't use preauth (or uses his devidsed form
of), 
he's going to have big problems integratig the two, mostly if he,
logically, 
wants to keep its base of current users (and groups in the near future)

For me the very first, next logical thing to auth is keeping a log of
logins/logouts. More than handling the form interaction, which is
something that I'd throw out to the application side. 

Your application should tell the admin: 
if you don't hae already, pick-up and install phplib, with any auth you
like (crc/no crc, log/reg, md5/no_md5. Do as you like). 
Then add new groups of users, ar extend the existing ones, to provide 
the desired permission to work with muy phpBugTraq app.  Of course, do
not use preauth.

I mean, this is the idea. Would this make any sense  with the way your
package works?

Giancarlo

> 
> On Wed, Aug 22, 2001 at 09:00:07AM -0400, Stephen Woodbridge wrote:
> > giancarlo pinerolo wrote:
> > >
> > > What I propose is to make Auth a very aseptic class. Kind of
> > > client-server. Loosely coulpled. No html ouptut, no form handling. That
> > > stuff should be handled, eventually, by the application, maybe in
> >
> > [snip large and useful post]
> >
> > I am sorry, I did not comment earlier, but I thought you were right on
> > track with your ideas and suggestions.
> >
> > I have wanted to create a login capability similar to PHP-Nuke (ie:
> > login form on the pages rather than a separate page) for my phplib
> > applications. I will try to use your ideas and the code you supplied on
> > your post here.
> >
> > Thank you for your efforts and contibutions to the list.
> >
> > -Steve
> >
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > http://lists.sourceforge.net/lists/listinfo/phplib-users
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phplib-users

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

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

I myself wrote:

> Your application should tell the admin:
> if you don't hae already, pick-up and install phplib, with any auth you
> like (crc/no crc, log/reg, md5/no_md5. Do as you like).
> Then add new groups of users, ar extend the existing ones, to provide
> the desired permission to work with muy phpBugTraq app.  Of course, do
> not use preauth.

I'd add:

write the name of your auth class in all my page_open statements, or
better, let my application use a site-wide defined constant that holds
the name of the auth class in use on your site....

is it so foolish? Wouldn't it be less hassle for you, package writer,
too?

- Gian

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

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

No, I do not mean preauth, I mean what I said -- default auth, as according to the phplib documentation.  By using var $nobody in my extension of the Auth class, default authentication is used when someone browses to the public pages of phpBugTracker.  When a user chooses to login, I check for that form submission -- note, I do not use login_if() -- and process the login by calling my extension of auth_validatelogin().

As far as integration is concerned, since I extend the Auth class as per the phplib documentation, a user wanting to integrate my package with the rest of his code would just replace my auth_validatelogin(), either by editing or by changing the class extension.  My installation instructions do tell the user to install phplib if not already installed, and that's all they have to do, since I extend the basic Auth class.

Perhaps you should take a look at what I've done to see how I've done it.

On Wed, Aug 22, 2001 at 06:26:20PM +0200, giancarlo pinerolo wrote:
> Ben Curtis wrote:
> > 
> > For all the discussion about this type of functionality on this phplib list and the previous one, it's really not that difficult to implement.  I have a login area on every page with my application, phpBugTracker (http://phpbt.sourceforge.net/).  All you have to do is use the default auth and handle the login form yourself instead of relying on auth_loginform().
> 
> I suppose you mean 'auth_preauth' instead of 'default auth'..
> 
> That?'s Ok. but when someone installs your package on a site that
> already has phplib, but doesn't use preauth (or uses his devidsed form
> of), 
> he's going to have big problems integratig the two, mostly if he,
> logically, 
> wants to keep its base of current users (and groups in the near future)
> 
> For me the very first, next logical thing to auth is keeping a log of
> logins/logouts. More than handling the form interaction, which is
> something that I'd throw out to the application side. 
> 
> Your application should tell the admin: 
> if you don't hae already, pick-up and install phplib, with any auth you
> like (crc/no crc, log/reg, md5/no_md5. Do as you like). 
> Then add new groups of users, ar extend the existing ones, to provide 
> the desired permission to work with muy phpBugTraq app.  Of course, do
> not use preauth.
> 
> I mean, this is the idea. Would this make any sense  with the way your
> package works?
> 
> Giancarlo
> 
> > 
> > On Wed, Aug 22, 2001 at 09:00:07AM -0400, Stephen Woodbridge wrote:
> > > giancarlo pinerolo wrote:
> > > >
> > > > What I propose is to make Auth a very aseptic class. Kind of
> > > > client-server. Loosely coulpled. No html ouptut, no form handling. That
> > > > stuff should be handled, eventually, by the application, maybe in
> > >
> > > [snip large and useful post]
> > >
> > > I am sorry, I did not comment earlier, but I thought you were right on
> > > track with your ideas and suggestions.
> > >
> > > I have wanted to create a login capability similar to PHP-Nuke (ie:
> > > login form on the pages rather than a separate page) for my phplib
> > > applications. I will try to use your ideas and the code you supplied on
> > > your post here.
> > >
> > > Thank you for your efforts and contibutions to the list.
> > >
> > > -Steve
> > >
> > > _______________________________________________
> > > Phplib-users mailing list
> > > Php...@li...
> > > http://lists.sourceforge.net/lists/listinfo/phplib-users
> > 
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > http://lists.sourceforge.net/lists/listinfo/phplib-users
> 
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phplib-users

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

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

Ben Curtis wrote:
> 
> No, I do not mean preauth, I mean what I said -- default auth, as according to the phplib documentation.  By using var $nobody in my extension of the Auth class, default authentication is used when someone browses to the public pages of phpBugTracker.  When a user chooses to login, I check for that form submission -- note, I do not use login_if() -- and process the login by calling my extension of auth_validatelogin().


http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/phpbt/phpbt/include.php?rev=1.37&content-type=text/plain

Gave a look at that. Nice hacks there.. as 

  if (!$username) return 'nobody';

or
 
  if (!$q->num_rows()) {
      return 'nobody';

;-))


But if I were to integrate that into my existing auth, I confess I'd get
quite stuck. I don't use the email as login. And I see that you don't
use the 'user' storage class. That could be a more suitable place to
store things like 'bug_list_fields', first name, last name, etc.,
instead of extending the sess[auth] array...

The idea should be: extend what you want, but leave and use the (any)
existing auth. Add users and grups to the auth tables if you need. Stuff
like: lists of prerogatives, permission/permitted on objects, allowed
paths or visitable documents, whatever, should stay in user. 

Apart from hat, I think you decided to provide your particular auth
extension because of the way 'page' and 'forms' where displayed... which
would confirm my opinion. The invasive handling of form interaction by
auth, obliges a package writer to provide his own. 
Which is  absurd.

- Gian

> As far as integration is concerned, since I extend the Auth class as per the phplib documentation, a user wanting to integrate my package with the rest of his code would just replace my auth_validatelogin(), either by editing or by changing the class extension.  My installation instructions do tell the user to install phplib if not already installed, and that's all they have to do, since I extend the basic Auth class.
> 
> Perhaps you should take a look at what I've done to see how I've done it.
> 
> On Wed, Aug 22, 2001 at 06:26:20PM +0200, giancarlo pinerolo wrote:
> > Ben Curtis wrote:
> > >
> > > For all the discussion about this type of functionality on this phplib list and the previous one, it's really not that difficult to implement.  I have a login area on every page with my application, phpBugTracker (http://phpbt.sourceforge.net/).  All you have to do is use the default auth and handle the login form yourself instead of relying on auth_loginform().
> >
> > I suppose you mean 'auth_preauth' instead of 'default auth'..
> >
> > That?'s Ok. but when someone installs your package on a site that
> > already has phplib, but doesn't use preauth (or uses his devidsed form
> > of),
> > he's going to have big problems integratig the two, mostly if he,
> > logically,
> > wants to keep its base of current users (and groups in the near future)
> >
> > For me the very first, next logical thing to auth is keeping a log of
> > logins/logouts. More than handling the form interaction, which is
> > something that I'd throw out to the application side.
> >
> > Your application should tell the admin:
> > if you don't hae already, pick-up and install phplib, with any auth you
> > like (crc/no crc, log/reg, md5/no_md5. Do as you like).
> > Then add new groups of users, ar extend the existing ones, to provide
> > the desired permission to work with muy phpBugTraq app.  Of course, do
> > not use preauth.
> >
> > I mean, this is the idea. Would this make any sense  with the way your
> > package works?
> >
> > Giancarlo
> >
> > >
> > > On Wed, Aug 22, 2001 at 09:00:07AM -0400, Stephen Woodbridge wrote:
> > > > giancarlo pinerolo wrote:
> > > > >
> > > > > What I propose is to make Auth a very aseptic class. Kind of
> > > > > client-server. Loosely coulpled. No html ouptut, no form handling. That
> > > > > stuff should be handled, eventually, by the application, maybe in
> > > >
> > > > [snip large and useful post]
> > > >
> > > > I am sorry, I did not comment earlier, but I thought you were right on
> > > > track with your ideas and suggestions.
> > > >
> > > > I have wanted to create a login capability similar to PHP-Nuke (ie:
> > > > login form on the pages rather than a separate page) for my phplib
> > > > applications. I will try to use your ideas and the code you supplied on
> > > > your post here.
> > > >
> > > > Thank you for your efforts and contibutions to the list.
> > > >
> > > > -Steve
> > > >
> > > > _______________________________________________
> > > > Phplib-users mailing list
> > > > Php...@li...
> > > > http://lists.sourceforge.net/lists/listinfo/phplib-users
> > >
> > > _______________________________________________
> > > Phplib-users mailing list
> > > Php...@li...
> > > http://lists.sourceforge.net/lists/listinfo/phplib-users
> >
> >
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > http://lists.sourceforge.net/lists/listinfo/phplib-users
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] preexisting auth integration

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

Yep. 
You must pardon me. I know I have the defect that when I start hammering
everyone with some of my ideas, I become less perceptive on other
people's ideas. I should listen more and give more value at others
then...

I downloaded the latest cvs of phpbugtraq and it is a very nice
application.

And I'd be glad to try to apply to it those kinda 'guidelines for
respecting preexisting auth' that I am trying to endorse/enforce.

So I took a look at the phpbt auth stuff.

PHPlib's auth_user table comes with a predefined set of fields:

user_id
username
password 
perms

As kk wrote in a recent message, you could freely add more fields to
that table if you need, as long as you keep these, without compromising
the way phplib auth works.

I understand that a bug traquing applicaton needs users' email. And a
valid one too. So phpbt checks that by sending an email with a random
chosen password to the address entered.
This as I see is not a two-step confirmation. No reply is expected from
the user receiving the email with the passwd upon registering.
In fact I see that you are writing the user record with the random
assigned password and send it by email, in one single go, in the
registering action (newaccount.php -> do_form())

This is interesting because it poses another side question: what should
be if it was a two-phase action? I mean, if the email pretended to
receive a  confirmation? What would be the state of that user in the
meanwhile? registered? pending (something similar to the actual
$auth[uid]='form' state)?
These are all ideas and problems that come out when somebody (me) starts
to apply a theary to some practical case. I see that most applications
that require an email confirmation for a registration, tend to keep a
separate file/table for pending_subs, and only after clearing that, the
actual registration takes place. To dig...

Anyway, back to phpbt, as it is a one-phase registration, the problem
doesn't apply here.

Now keep in mind that I am analyzing you app under *my* point of view,
basically because I am trying to see if/how it could conform to *my*
idea on 'guidelines for respecting preexisting auth'. I am not meaning
that you should have made the same thoughts, by no mean. You chose to do
it that way and it is perfectly sane. I just choose phpbt because you
are actually one of the first package developers that seems to show some
interest in this theory, and I see that phpbugtraq is one of the rare
phplib-based apps that do not come bundled with phplib, which is already
a great thing. 

So you are needing the email here. The fact that you made the login-nick
be the emailaddr, is an optional choice. One could have already his
logins that are not the email addresses, or that are. That makes little
difference. What makes the difference is that you used a different table
definition. The field 'username' in phpbt user tables doesn't exist
anymore, it is called 'email' phpbt, proably for semplicity and
reminding admins that it contains in fact the email addr. A minor
reason, that (in *my* theory, remember), brings to a major unconsistency
and integration problems

So how to integrate this in a site that doesn't store emailaddr in the
'username' field? Simply add an extra 'email' field, and store it there.
In brief: 

-if there is a  preexisting auth and already uses the emailaddr as
login-nick, and it is stored in the 'username' field of the table, 
he'd have to add and 'email' field anyway for your app to work. It 
will not break anything on his site.

-if there is a preexisting auth that uses a user-chosen login nickname
(and stores it in the 'username' field), add an 'email' field to the
table and store it there. Again, it won't break anything.

-if there is no preexisting auth, but you want to let the admin install
more phplib-based packages afterwards without hassle, give him a choiche
while setting up phpbt and his site auth: he could set a nickname in
'username' and the emailaddr in a 'email' field  if he wanted to have
nickname!=emailaddr, otherwise store the emailaddr in both the
'username' and in the extra 'email' fields. But keep the table field
named 'username' in any case.

And when phpbt makes its SELECT to validate, it always select the
username/password fields. and gets the email from the 'email' field. If
then the username also contains the email, you can't care less, it's the
admin choice.

Pls tell me if I am wrong.

Giancarlo




I myself  wrote:

> But if I were to integrate that into my existing auth, I confess I'd get
> quite stuck. I don't use the email as login. And I see that you don't
> use the 'user' storage class. That could be a more suitable place to
> store things like 'bug_list_fields', first name, last name, etc.,
> instead of extending the sess[auth] array...
> 
> The idea should be: extend what you want, but leave and use the (any)
> existing auth. Add users and grups to the auth tables if you need. Stuff
> like: lists of prerogatives, permission/permitted on objects, allowed
> paths or visitable documents, whatever, should stay in user.
> 
> Apart from hat, I think you decided to provide your particular auth
> extension because of the way 'page' and 'forms' where displayed... which
> would confirm my opinion. The invasive handling of form interaction by
> auth, obliges a package writer to provide his own.
> Which is  absurd.
> 
> - Gian
> 
> > As far as integration is concerned, since I extend the Auth class as per the phplib documentation, a user wanting to integrate my package with the rest of his code would just replace my auth_validatelogin(), either by editing or by changing the class extension.  My installation instructions do tell the user to install phplib if not already installed, and that's all they have to do, since I extend the basic Auth class.
> >
> > Perhaps you should take a look at what I've done to see how I've done it.
> >
> > On Wed, Aug 22, 2001 at 06:26:20PM +0200, giancarlo pinerolo wrote:
> > > Ben Curtis wrote:
> > > >
> > > > For all the discussion about this type of functionality on this phplib list and the previous one, it's really not that difficult to implement.  I have a login area on every page with my application, phpBugTracker (http://phpbt.sourceforge.net/).  All you have to do is use the default auth and handle the login form yourself instead of relying on auth_loginform().
> > >
> > > I suppose you mean 'auth_preauth' instead of 'default auth'..
> > >
> > > That?'s Ok. but when someone installs your package on a site that
> > > already has phplib, but doesn't use preauth (or uses his devidsed form
> > > of),
> > > he's going to have big problems integratig the two, mostly if he,
> > > logically,
> > > wants to keep its base of current users (and groups in the near future)
> > >
> > > For me the very first, next logical thing to auth is keeping a log of
> > > logins/logouts. More than handling the form interaction, which is
> > > something that I'd throw out to the application side.
> > >
> > > Your application should tell the admin:
> > > if you don't hae already, pick-up and install phplib, with any auth you
> > > like (crc/no crc, log/reg, md5/no_md5. Do as you like).
> > > Then add new groups of users, ar extend the existing ones, to provide
> > > the desired permission to work with muy phpBugTraq app.  Of course, do
> > > not use preauth.

Re: [Phplib-users] preexisting auth integration

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

At 11:38 AM +0200 23/8/01, giancarlo pinerolo wrote:

>This is interesting because it poses another side question: what should
>be if it was a two-phase action?

The applications I have written that use a two-stage password have a
"verified" column in the database. Initially that contains a 0 and once
the user has been verified it changes to a 1.

If emails to the user start bouncing, this can be changed back to a 0
or perhaps to a 3.


>be the emailaddr, is an optional choice. One could have already his
>logins that are not the email addresses, or that are.

The big advantage of using the email address as the login is that users
rarely forget their email address, and you have assurance that if they
forget their password you have an email address to send a new one to.

 ...R.

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

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

> I see that most applications
> that require an email confirmation for a registration, tend to keep a
> separate file/table for pending_subs, and only after clearing that,
the
> actual registration takes place.

I've developed a two-phase email registration with by integrating email
and a state field in the auth_user table...
When the user registers his account I don't demand the password... and I
store a random password for him in the table... with the state flag to
"unregistered"... Then the user receive an email with the password. He
can use the password just one time to avoid "email piracy" : when he
connects with the temporary password and the state "unregistered", I
change the password automatically and force the user to put its own
password before he can do anything... then I store the good password and
I turn the state flag to "registered"...
To do that I've not modified the auth class... just create an extend
class in my local.inc...

Guillaume

[Phplib-users] Re: preexisting auth integration

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

On Thu, Aug 23, 2001 at 11:38:00AM +0200, giancarlo pinerolo wrote:
> Yep. 
> You must pardon me. I know I have the defect that when I start hammering
> everyone with some of my ideas, I become less perceptive on other
> people's ideas. I should listen more and give more value at others
> then...

Well, we all tend to have our perception colored by our experience and frame of reference, right?  :)

> 
> I downloaded the latest cvs of phpbugtraq and it is a very nice
> application.

Thanks for taking a look at it, and thanks for the compliment.  Also, thanks for the nice analysis and suggestions below...

> 
> And I'd be glad to try to apply to it those kinda 'guidelines for
> respecting preexisting auth' that I am trying to endorse/enforce.
> 
> So I took a look at the phpbt auth stuff.
> 
> PHPlib's auth_user table comes with a predefined set of fields:
> 
> user_id
> username
> password 
> perms
> 
> As kk wrote in a recent message, you could freely add more fields to
> that table if you need, as long as you keep these, without compromising
> the way phplib auth works.

Right, I saved that thread so I when I get a few spare minutes I can implement those ideas into my schema.  It is definitely a flexible and valuable way to manage users.

> 
> I understand that a bug traquing applicaton needs users' email. And a
> valid one too. So phpbt checks that by sending an email with a random
> chosen password to the address entered.
> This as I see is not a two-step confirmation. No reply is expected from
> the user receiving the email with the passwd upon registering.
> In fact I see that you are writing the user record with the random
> assigned password and send it by email, in one single go, in the
> registering action (newaccount.php -> do_form())

Yeah, I really geared this towards an internal testing/dev team, so stuffing the user table with bad email addresses and kicking out lots of emails wouldn't be an issue.  

> 
> This is interesting because it poses another side question: what should
> be if it was a two-phase action? I mean, if the email pretended to
> receive a  confirmation? What would be the state of that user in the
> meanwhile? registered? pending (something similar to the actual
> $auth[uid]='form' state)?
> These are all ideas and problems that come out when somebody (me) starts
> to apply a theary to some practical case. I see that most applications
> that require an email confirmation for a registration, tend to keep a
> separate file/table for pending_subs, and only after clearing that, the
> actual registration takes place. To dig...

Like the posts in response to this on the other list, if I were to do a two-phase sign-up, I would insert the record as an inactive user, and then bump that up to regular user upon first login.  I also liked the idea of forcing a password change at that point.

> 
> Anyway, back to phpbt, as it is a one-phase registration, the problem
> doesn't apply here.
> 
> Now keep in mind that I am analyzing you app under *my* point of view,
> basically because I am trying to see if/how it could conform to *my*
> idea on 'guidelines for respecting preexisting auth'. I am not meaning
> that you should have made the same thoughts, by no mean. You chose to do
> it that way and it is perfectly sane. I just choose phpbt because you
> are actually one of the first package developers that seems to show some
> interest in this theory, and I see that phpbugtraq is one of the rare
> phplib-based apps that do not come bundled with phplib, which is already
> a great thing. 
> 
> So you are needing the email here. The fact that you made the login-nick
> be the emailaddr, is an optional choice. One could have already his
> logins that are not the email addresses, or that are. That makes little
> difference. What makes the difference is that you used a different table
> definition. The field 'username' in phpbt user tables doesn't exist
> anymore, it is called 'email' phpbt, proably for semplicity and
> reminding admins that it contains in fact the email addr. A minor
> reason, that (in *my* theory, remember), brings to a major unconsistency
> and integration problems
> 
> So how to integrate this in a site that doesn't store emailaddr in the
> 'username' field? Simply add an extra 'email' field, and store it there.
> In brief: 
> 
> -if there is a  preexisting auth and already uses the emailaddr as
> login-nick, and it is stored in the 'username' field of the table, 
> he'd have to add and 'email' field anyway for your app to work. It 
> will not break anything on his site.
> 
> -if there is a preexisting auth that uses a user-chosen login nickname
> (and stores it in the 'username' field), add an 'email' field to the
> table and store it there. Again, it won't break anything.
> 
> -if there is no preexisting auth, but you want to let the admin install
> more phplib-based packages afterwards without hassle, give him a choiche
> while setting up phpbt and his site auth: he could set a nickname in
> 'username' and the emailaddr in a 'email' field  if he wanted to have
> nickname!=emailaddr, otherwise store the emailaddr in both the
> 'username' and in the extra 'email' fields. But keep the table field
> named 'username' in any case.
> 
> And when phpbt makes its SELECT to validate, it always select the
> username/password fields. and gets the email from the 'email' field. If
> then the username also contains the email, you can't care less, it's the
> admin choice.
> 
> Pls tell me if I am wrong.
> 

You raise some valid points, which I have been thinking about as one of the users of my package wants to separate the login username from the email address.  I have a little experience in integrating the auths from two phplib-based packages (trying to get phpBB v2 working with a pre-existing site).  Now, in this case, the phpBB guys saw fit to eviscerate phplib and re-invent the wheel.  Regardless of how relevant that may be to this conversation, the point is I had to gut their stuff to check against our login/auth while putting enough data in their tables to get phpBB to work.  In the end that meant all the user interactions in the pre-exising app (login, logout, user info modification) had to be copied over to the relevant places in their tables.

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...

> Giancarlo
> 
> 
> 
> 
> I myself  wrote:
> 
> > But if I were to integrate that into my existing auth, I confess I'd get
> > quite stuck. I don't use the email as login. And I see that you don't
> > use the 'user' storage class. That could be a more suitable place to
> > store things like 'bug_list_fields', first name, last name, etc.,
> > instead of extending the sess[auth] array...
> > 
> > The idea should be: extend what you want, but leave and use the (any)
> > existing auth. Add users and grups to the auth tables if you need. Stuff
> > like: lists of prerogatives, permission/permitted on objects, allowed
> > paths or visitable documents, whatever, should stay in user.
> > 
> > Apart from hat, I think you decided to provide your particular auth
> > extension because of the way 'page' and 'forms' where displayed... which
> > would confirm my opinion. The invasive handling of form interaction by
> > auth, obliges a package writer to provide his own.
> > Which is  absurd.
> > 
> > - Gian
> > 
> > > As far as integration is concerned, since I extend the Auth class as per the phplib documentation, a user wanting to integrate my package with the rest of his code would just replace my auth_validatelogin(), either by editing or by changing the class extension.  My installation instructions do tell the user to install phplib if not already installed, and that's all they have to do, since I extend the basic Auth class.
> > >
> > > Perhaps you should take a look at what I've done to see how I've done it.
> > >
> > > On Wed, Aug 22, 2001 at 06:26:20PM +0200, giancarlo pinerolo wrote:
> > > > Ben Curtis wrote:
> > > > >
> > > > > For all the discussion about this type of functionality on this phplib list and the previous one, it's really not that difficult to implement.  I have a login area on every page with my application, phpBugTracker (http://phpbt.sourceforge.net/).  All you have to do is use the default auth and handle the login form yourself instead of relying on auth_loginform().
> > > >
> > > > I suppose you mean 'auth_preauth' instead of 'default auth'..
> > > >
> > > > That?'s Ok. but when someone installs your package on a site that
> > > > already has phplib, but doesn't use preauth (or uses his devidsed form
> > > > of),
> > > > he's going to have big problems integratig the two, mostly if he,
> > > > logically,
> > > > wants to keep its base of current users (and groups in the near future)
> > > >
> > > > For me the very first, next logical thing to auth is keeping a log of
> > > > logins/logouts. More than handling the form interaction, which is
> > > > something that I'd throw out to the application side.
> > > >
> > > > Your application should tell the admin:
> > > > if you don't hae already, pick-up and install phplib, with any auth you
> > > > like (crc/no crc, log/reg, md5/no_md5. Do as you like).
> > > > Then add new groups of users, ar extend the existing ones, to provide
> > > > the desired permission to work with muy phpBugTraq app.  Of course, do
> > > > not use preauth.

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

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

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...
> 

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.

All this is but the contour to the phpbugtraq application, which is a
very specialized one and I raise my hat to it. I'd surely adopt that in
the available choice. Nice app, nice language, nice developers.

ciao
Gian

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

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

[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] 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

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
> >

[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-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] 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