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

[Phplib-users] phplib app integration

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

I have been following the interesting discussion between Gian, Ben and
other, but I want to jump back from the details for a minute. I think
this builds on what you guys have been saying but I need to say it to
see if I understand in it. So here goes ...

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

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

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. 

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.

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.

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

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.

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

-Steve

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

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

[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] stuff in the $sess->auth[] array

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

You know you can put all sort of stuff under there, under the
$sess->auth[] array.

It will last as much as your session, even less if you set an expire for
auth, so it will not be persistent. But next login can be reloaded..
And it will be visible, if you'll use php4 default session, which gets
stored in /tmp as a csv file..

So my question is:
what could you reasonably think to put there?
Someone wrote an extension to stock ACL permissions on objects that
would be stored there.
Others  place the user full name and surname, or email.

In fact it can be an easy shortcut to defining a User class, and using
that instead. And can save some I/O as everything stays just in the
session record..

So one may think it is OK to store there things as 'how many more
salamis I can buy at discount price' or, for the vicious, 'list of
tables where I am authorized to gamble a free fiche'. 
Missing guidelines for that. And this leads to more uncompatible auths.

I myself only recently realized that Auth and User were not
inter-dependent, so always coupled Auth with User, let Auth almost 
untouched, and put stuff I needed into User.

 - Gian

[Phplib-users] db_pgsql metadata & question on auth

[Oliver Duke-W. <ol...@ge...>]

Hi,

[Using phplib 7.2d w/ php 4.0.6]

I've encountered a problem with the function db_pgsql->metadata(); the
function derives its information by doing "select * from $table", which can
take a long time on a large table, and also choke the memory if the table is
large enough.  

Am I missing anything obvious if I change it to 'select * from $table limit
0'?  This will cause only the field metadata to be returned, and performance
will not therefore be dependent on the table size.  This works for the example
I'm currently playing with, and I can't see why it should fail anywhere else.

Having said, that it may be that the best performance would be gained by using
the pg_ catalog tables, in the same way that psql does; i.e. the metadata
could be retrieved as:

SELECT a.attname,format_type(a.atttypid, a.atttypmod),a.attlen 
FROM pg_class c, pg_attribute a 
WHERE c.relname = $table 
AND a.attrelid = c.oid and a.attnum > 0 
ORDER BY a.attnum

However, I'm not sure whether any performance gain would be noticeable...

On a completely unrelated issue, I've had a problem trying to use a 'cancel'
button on a login form if I set register_globals to 'off' in php.  (I'm using
a default auth, and including a 'login' button on each page, which then
includes a login form via the login_if())

The auth code as is checks for the existence of the value indicated by
$auth->cancel_login; however given that the http variables do not get
automatically globally imported, this check fails.

I've tried pretty numerous permutations of setting cancel_login in my local
extension of auth to e.g. HTTP_POST_VARS['my_button_name'], but without
success.  Instead the only way I've been able to use the button is by changing
line 72 of the original auth.inc from:

          if ($$cl) {

to:

          if (isset ($GLOBALS['HTTP_POST_VARS'][$cl])) {

which is not as generalised as one might like, and certainly seems to be the
wrong way of solving the problem.

Can anyone suggest the 'correct' way to do this?

Cheers,

Oliver
-- 
Oliver Duke-Williams  <ol...@ge...>   Tel 0113 233 3286
Centre for Computational Geography, University of Leeds, UK

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] 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] 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] Re: [phplib] auth login/logout logging (was: current users?)

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

On Wed, Aug 22, 2001 at 07:50:29PM +0200, giancarlo pinerolo wrote:
> Session lifetime not = 0 is a tricky choice.

Session lifetime not = 0 is not recommended. lifetime = 0
creates dateless session cookies, which have a different
security state from dated cookies (lifetime <> 0) in many
browsers and in P3P.

Also, if you reject cookies with lifetime = 0, rejecting one
cookie is enough - you will not receive more cookies. Using
dated cookies, PHPLIB must refresh that cookie on each time a
page is served, and you'll have to reject that cookie again and
again on each page (unless your browser provides proper cookie
management). This is very annoying.

I strongly recommend undated session cookies, that is, setting
$sess->lifetime = 0;


Keep in mind that $auth->lifetime and $sess->lifetime are
entirely different things.

Kristian

[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

[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] auth login/logout logging (was: current users?)

[Layne W. <la...@if...>]

> Then, thinking, another choice for the login/logout logtable, would be
> to write a new couple of login/logout ( with logout time =
> login time +
> expiration) records every time the  expiration time is renewed, in
> practice at every page_open... Maybe that would be heavy on
> performance.

That's pretty much how I did it. Every page has to check auth anyway, so the
new expiration time is renewed and available. My normal pages do so much
database activity that one more query, even a slow insert, does not make
much of a measurable difference.


> And then how to provide for implementations that do not use
> expire time for auth?

I had forgotten that people did that. My first thought would be to set a
time limit for logging/statistical purposes only. This would be similar to
using a web server log analysis tool like Analog or Webalizer were I specify
that hits from the same ip/user agent within x number of minutes constitutes
a user session. It is neither very sophisticated nor accurate, but is useful
to a degree as long as I am aware of the problems.


Layne Weathers
Ifworld Inc

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

[Phplib-users] auth login/logout logging (was: current users?)

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

Session lifetime not = 0 is a tricky choice.
But you say that you left the 'session-only' page open in the browser,
so that wouldn't matter anyway here...
Otherwise session lifetime > 0 should be deprecated, that should go into
User space.

Layne Weathers wrote:
> 
> > > 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'...
> 
> No, I was talking about two different cases. The first was the multiple
> processes. 

Which is the 'start button/IE ' I suppose. New IE instance...


> The second is:
> 1. I go to the site and get a session id
> 2. I go to a protected area, login, and am now authorized
> 3. I leave my computer and the auth timeout (15 or 30 minutes default)
> expires
> 4. The session doesn't expire for about a day by default, so I still have
> that session id
> 5. I come back to my computer, my stateless browser still has the last page
> I was on, which was built when I was authorized
> 6. I click a link
> 7. Since I am unauthorized due to inactivity, I login again

That makes full sense then, if you didn't close that 'session-only'
browser instance.

> For my purpose, I chose to count multiple logins on one session id as a
> single login. Many times the users would be on a long phone call and auth
> would expire. Other people may want to separate the two, so it would be nice
> to have the option as a flag in a class extension.
> 

OK, got you now.

Then, thinking, another choice for the login/logout logtable, would be
to write a new couple of login/logout ( with logout time = login time + 
expiration) records every time the  expiration time is renewed, in
practice at every page_open... Maybe that would be heavy on performance.

And then how to provide for implementations that do not use expire time
for auth?

Thinking.....

-Gian

> 
> Different auths, same session.
> 
> Layne Weathers
> Ifworld Inc
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phplib-users

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

[Layne W. <la...@if...>]

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

Thanks for the clarification. The last time this was brought up I thought I
was going crazy.


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

Yes, but only as part of my HTML/JavaScript/StyleSheets compatibility test
suite. I just tested and Netscape does not behave like IE - all windows
share session cookies regardless of how they were initiated.


Layne Weathers
Ifworld Inc

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

[Layne W. <la...@if...>]

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

No, I was talking about two different cases. The first was the multiple
processes. The second is:
1. I go to the site and get a session id
2. I go to a protected area, login, and am now authorized
3. I leave my computer and the auth timeout (15 or 30 minutes default)
expires
4. The session doesn't expire for about a day by default, so I still have
that session id
5. I come back to my computer, my stateless browser still has the last page
I was on, which was built when I was authorized
6. I click a link
7. Since I am unauthorized due to inactivity, I login again

Different auths, same session.


Layne Weathers
Ifworld Inc

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

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

[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

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?

[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

[Phplib-users] How do I ...?

[White, B. <rc...@sb...>]

Hi All,
I managed to get session  auth , perms working properly, but need to extend
the session, auth and perms to a page called from an oohform.  How do I do
that?
Bob White

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

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