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

[Phplib-users] alternate auth method

[Tim S. <ti...@oc...>]

Hello,

Im after some help, I am attempting to authenticate from a windows
application that launches a browser, users enter their details into
the application and it opens a browser with username=foo&password=md5hash
in the URL.

I have extended the auth class as explained in the documentation:

class Example_Auth extends Auth
{
  var $classname        = "Example_auth"; # Object serialization support

  var $lifetime         =  15;
  
  ## DB_Sql subclass and database table to use
  var $database_class = "DB_Example";
  var $database_table = "auth_user";

  ## Some magic value to make our uids harder to guess.
  var $magic = "Abracadabra";

  ## Use an own login form
  function auth_loginform() {
    global $sess;
    include("templates/login_error.php");

  }
  
  function auth_validatelogin() {
    global $username, $password;    ## form variables from loginform.ihtml
    
    $this->auth["uname"]=$username;
    $uid   = false;
    
    $query = sprintf(
      "select password,user_id from %s where username = '%s'",
      $this->database_table,$username);
    $this->db->query($query);
    
    while($this->db->next_record()) {

     if($password == md5($this->db->f("password")."secret_string"))
     {
      $uid = $this->db->f("user_id");
      $this->auth["perm"] = "admin";//$this->db->f("perms");
     }
    }
    
    return $uid;
  }
}

This method works, however, when authentication suceeds, the user
is still redirected to the error page, and if they refresh the 
browser then they get to the actual content. What I want is for
users to gain access immeadiatly of they authenticate correctly,
but be redirected to an error page if they fail. the loginform is
replaced by the application.

Can anyone help/point me in the right direction?

Thanks, Tim
 
-- 
+----------------------------------------------+
Tim Stebbing,
ti...@oc..., www.oceanablue.com.au
Software Development Services.
+----------------------------------------------+

[Phplib-users] PHPlib 7.4 pre 1 & PHP4 4.1.2

[Fabio F. <fe...@in...>]

I'm trying to migrate from debian potato with PHP 3.0.18 & PHPLIB 7.2c to woody with PHP 4.1.2 & PHPLIB 7.4 pre 1 but I got strange error like this:

   Warning: PostgreSQL query failed: ERROR: Attribute 'val' not found in
   /var/www/phplib/db_pgsql.inc on line 69
   Database error: Invalid SQL: select val from active_sessions where sid
   = 'nobody' and name = 'Test_User'
   PostgreSQL Error: 1 (ERROR: Attribute 'val' not found )
   Session halted.

There is a phplib package ready for PHP4? Do I use the unstable csv tree?

Thanks.

P.s. I've renamed active_sessions p_* to * (i.e. p_val to val, etc) and now seems to work.

-- 
   ___
  (o.o)
 {(___)}
==="="===
Fabio "Nutella" Ferrero || nu...@in... || 051.624.55.26 || ICQ: 4101811
// Internet Images s.r.l. >> http://www.interim.it >> Tel://051.624.19.09

Re: [Phplib-users] PHP 4.3.0

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

On 19 Jun 2002, Daniel Bondurant wrote:

> should we use ZE2/PHP 4.3 as an excuse to finally get rid of all php3
> legacy code, fix all known problems, review all the code, etc?
>
> Basically, I am suggesting make phplib 8.0 require PHP 4.3.0.
> then put phplib 7.4 in maintenance mode.
>
>

I think that's the current take on things.  Once 7.4 is finalized (hoping
to get that done soon) phplib-8.0 talks can begin in full.

-n

------
nathan hruby
na...@ds...
------

Re: [Phplib-users] PHP 4.3.0

[Daniel B. <bo...@io...>]

should we use ZE2/PHP 4.3 as an excuse to finally get rid of all php3
legacy code, fix all known problems, review all the code, etc?

Basically, I am suggesting make phplib 8.0 require PHP 4.3.0.
then put phplib 7.4 in maintenance mode.

Re: [Phplib-users] PHP 4.3.0

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

Is that a GLOBALS::delete() or an all namespcae thingy?

Oh waitaminit.. 'delete' is a reserved word, which means it's probably a
langauge construct which means no.. scope don't matter becasue it'll be
interpeted at parse time, not execution time..

God, that's dumb (well, the idea is good, the naming is perhaps not
insightful as one could hope for).  I doubt we're the only people with a
delete() function, why doesn't ZE2 call it something more intuitive like..
oh.. obj_delete()?  rm_object(), del_obj()? obj_del()?

Argh.

Other than that there seems to be a lot of nifty stuff in ZE2.  4.3.0 is
still marked as alpha and I doubt it'll be seeign a lot of light on
production servers anytime soon while the bugs get shaken out of ZE2;
however, we probably need to fix this RSN before it bites us.

Daniel, can you please file a bug on this in the SF trackers?  I will try
to get a fix in this weekend and release a 7.4.pre2 after that.

Anyone on the php-dev list know if this issue has been bandied about
before?

FWIW, delete() just drops the session from the database table.  It's not a
private API function but it's also not something you need to call if you
feel confident enough with the builtin GC of the session classes (which
also use delete() I think).

This will chnage the API by some, though in  short term we'll need to add
a boolean $ZE2 flag that when flase will present a stub delete() that maps
to the renamed function and perhaps issues a warning or soemthing.

-n
------
nathan hruby
na...@ds...
------

On Tue, 18 Jun 2002, Daniel Bondurant wrote:

> looking at the release notes for PHP 4.3.0.  There will be some trouble
> with phplib and the Zend 2.0 engine.
> http://www.php.net/ZEND_CHANGES.txt
>
> First thing I noticed was:
>     * Forced deletion of objects.
>
>       The Zend Engine 1.0 had no means to force deletion of an object
>       if there are still references to it. The newly introduced delete
>       statement calls the object's destructor and frees it even if the
>       object is referenced by some other places in the engine. Other
>       references to the deleted object become stale and trying to
>       access them results in a fatal error.
>
>       Note that if you have a user-defined function delete() in an old
>       script, this script will yield a parser error with the Zend
>       Engine 2.0, since 'delete' is now a reserved word.
>
>
> session.inc and session4.inc both have delete() functions.
> There will probably be some other problems, but I don't know the
> internals of phplib enough to hunt them all down.
>

[Phplib-users] PHP 4.3.0

[Daniel B. <bo...@io...>]

looking at the release notes for PHP 4.3.0.  There will be some trouble
with phplib and the Zend 2.0 engine.
http://www.php.net/ZEND_CHANGES.txt

First thing I noticed was:
    * Forced deletion of objects.

      The Zend Engine 1.0 had no means to force deletion of an object
      if there are still references to it. The newly introduced delete
      statement calls the object's destructor and frees it even if the
      object is referenced by some other places in the engine. Other
      references to the deleted object become stale and trying to
      access them results in a fatal error.

      Note that if you have a user-defined function delete() in an old
      script, this script will yield a parser error with the Zend
      Engine 2.0, since 'delete' is now a reserved word.


session.inc and session4.inc both have delete() functions.
There will probably be some other problems, but I don't know the
internals of phplib enough to hunt them all down.

[Phplib-users] Database errors not showing?

[Peter B. <re...@f2...>]

Hi,

Recently (with 4.1.X+) I've been finding that database errors do not appear 
in any error messages the database class returns.  A common output would be:
Database error: Invalid SQL: UPDATE sendcard SET notify='0' where 
id=1024329448640
MySQL Error: ()
Session halted.

Does anyone know if something's changed in the MySQL API that prevents this 
from working, or is there another explanation?

Thanks
Peter

Re: [Phplib-users] Re: Templates/SSL/IE5 Problem

[S. <bj...@ba...>]

* Andrew Crawford wrote:
> >>Cannot find server or DNS Error

* SSL & MSIE & Form-Submit & "Page or DNS not found"

  append the following line to httpd.conf:

  SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown


* SSL & href="javascript:":

  wrong onClick Handler within MSIE 5.5. Either
  Service Pack 1 helps or the workaround as mentioned in

  http://support.microsoft.com/support/kb/articles/Q269/6/82.ASP

-- 
PHP-Support * realitätsnahe Performance-Messungen mit Code-Analyse
    Webapplikationsentwicklung * PHP-Schulungen * Consulting
    
             0700-THINKPHP -*- bj...@th...

RE: [Phplib-users] latest version

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

Check out the latest php-lib-stable branch. You'll get everything you need.

Layne Weathers
Ifworld Inc. 

Re: [Phplib-users] Radio Button problem

[Peter K. <su...@si...>]

Hello Ron,

the value of single radio buttons ist set with the $value-parameter in
show_element($name, $value). You should omit the checked-element in 
add_element. And add a multiple-element. And you don't need two add_element's!

Usage:

$form->add_element(array( 
  "name"=>"release", 
  "type"=>"radio",
  "value"=>"Y",
  "multiple"=>1
  )); 
 
 .....
 
 $form->show_element("release","Y");	
 $form->show_element("release","N");
 ....
 
 This produces two radio buttons with values "Y" and "N". The "Y"-Button 
 will be checked (because of "value"=>"Y" in add_element)
 
 hope this helps
 
 Peter Kursawe

[Phplib-users] latest version

[Rogers, P. <Pau...@mo...>]

Dear All

Can anyone suggest the best way to get an up to date phplib?  Should I start
with the latest stable version and add the cvs or alternatively start with
the development version and add cvs?  Should the cvs branch I use be the
stable or development?  I have seen quite alot of correpondence on this
relating to which branch best addresses a particular issue but wondered what
peoples views are on what the best way to get an up todate system that
addresses the most no of problems.

Many thanks


Paul


*****************************************************************************
This email and any attachments transmitted with it are confidential
and intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the sender and do not store, copy or disclose the content
to any other person.

It is the responsibility of the recipient to ensure that opening this
message and/or any of its attachments will not adversely affect
its systems. No responsibility is accepted by the Company.
*****************************************************************************

[Phplib-users] Re: Templates/SSL/IE5 Problem

[Andrew C. <An...@Ev...>]

Greetings,

I never received any response when I posted this back in January but, it 
came up again and I finally figured out what was wrong.  More specifically, 
I figured out how to compensate for this particular aspect of IE being 
broken.  This is not a phplib-specific issue but, the problem didn't show 
up for me until I was using phplib with SSL and templates.  I thought I 
would share the solution for posterity.

Basically, IE doesn't behave correctly (i.e. standards-compliantly) in 
conducting GET and POST operations with SSL servers with keepalive enabled:

    http://www.quikstore.com/download/ssl_timeout_problem/ssl_problem.txt

Setting the KeepAliveTimeout to 65 seconds and MaxKeepAliveSessions to 300 
in the Apache httpd.conf file seems to have resolved the issue for at least 
some of the test cases.

It may also be helpful to force MSIE clients to fallback to using SSL2, 
rather than permitting them to use SSL3.  This can be done with a variation 
of the fixes described on this page (the SetEnvIf and SSLCipherSuite items):

    http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#io-ie

I hope that helps someone else sometime.

Andrew Crawford
An...@Ev...

On 11 Jan 2002 at 00:32:03 -0700, I wrote:
>I wrote a PHP script (standalone, no phplib components) to accept some 
>data input through a secure (SSL) web form, present that information for 
>review, and then process it.  It works great.
>
>I modified the script so that it uses phplib templates (from phplib 
>version 7.2d) for all of the output (the original form, the review page, 
>and the final results page.)  It works great ... except in IE 5 for Windows.
>
>In IE 5, the initial form loads fine.  I fill in some data and press the 
>submit button.  IE pops up a dialogue that says:
>
>>You are about to leave a secure internet connection.  It will be possible 
>>for others to view the information you send. [Yes] [No] [More Info]
>
>This message should not appear.  The connection is secure (well, as secure 
>as it gets for web transactions - I know Bruce Schnier would have 
>comments.)  I changed all of the relative references in my template to 
>absolute references, including the "https://".  I changed all the graphics 
>in the page and even the reference for the style sheet.  So, I see nothing 
>in the page that should cause it to retrieve anything via anything but https.
>
>If I hit "Yes" in response to the dialogue, I get a "this page cannot be 
>displayed" error page, culminating in this error message:
>
>>Cannot find server or DNS Error
>
>I can then hit refresh and get back to the blank form with all input lost.
>
>If I hit "No" in response to the pop-up dialogue, it returns to the 
>populated form and lets me try again.
>
>Either way, on the second try, there is no pop-up dialogue and the script 
>proceeds as it should (as it does in all other browsers I have tested, 
>including IE 5 for MacOS.)  When submitting the okay for the review, the 
>same thing happens.
>
>The problem disappears when accessing the same form with a regular http 
>connection.  So, this appears to be a problematic interaction among IE 5, 
>SSL, and phplib templates.
>
>I loathe IE for always being part of problems like this but, it is in such 
>widespread use, I have to support it.  Anyone have any guesses about what 
>might be causing this or how I can fix it?
>
>This is my first foray into using phplib templates (though I have been 
>using phplib for other things for quite some time) so, this could easily 
>be a known issue or a stupid user problem.  I will be hesitant to use 
>phplib templates in other projects until I can figure out what is wrong 
>here.  So, any insight would be appreciated.
>
>BTW, I notice that the initial comments block in template.inc appears to 
>contain the wrong description:
>
>>/*
>>  * Session Management for PHP3
>>  *
>>  * (C) Copyright 1999-2000 NetUSE GmbH
>>  *                    Kristian Koehntopp
>>  *
>>  * $Id: template.inc,v 1.5 2000/07/12 18:22:35 kk Exp $
>>  *
>>  */
>
>Shouldn't it be "Templates for PHP" or something rather than "Session 
>Management?"
>
>Thank you for any suggestions you can render.

Re: [Phplib-users] session.use_cookie

[Giancarlo P. <gia...@na...>]

Giancarlo Pinerolo wrote:
> 
> Isn't cookie is an acronym of
> 'not interchangeable among clients that support cookies'?
> 

A change of propagation, once started, should not happen. 
If our aim is trust cookies because they go as close as possible to be
bound to the single client, we should also get suspicious when this
client, that we trust unique and at a certain point cookie-able, has
changed his mode.
Unless someone disables his cookies just amid the way, of  which I don't
know the results.

So if a client has changed his mode, and one of these was cookie,
something is wrong with session.use_cookies=1 ... or at least we might
want to be able to decide it on a per basis.

I mean this should be our interest.

I don't know if these PHP SOAP extensions to PHP presume any level of
access or credential, but that could be related. How is a SOAP service
granted?

Giancarlo

[Phplib-users] Radio Button problem

[Ron P. <ro...@cn...>]

I cannot get phplib ooh forms to set the values on radio buttons. It =
always checks the last value in the array. This is my snippet.

$form->add_element(array(=20
"name"=3D>"release",=20
"type"=3D>"radio",=20
"checked"=3D>1,=20
"value"=3D>"Y"=20
));=20

$form->add_element(array(=20
"name"=3D>"release",=20
"type"=3D>"radio",=20
"checked"=3D>0,=20
"value"=3D>"N"=20
));

This is the only part of the ooh forms I can't get to work right. Any =
help would be appreciated.

Ron Phillips
Web Development
-------------------------------------------------------
Charleston Newspapers Interactive
http://www.cn-interactive.com

Phone: (304) 348-5167
Email: ro...@cn...

[Phplib-users] session.use_cookie

[Giancarlo P. <gia...@na...>]

Isn't cookie is an acronym of 
'not interchangeable among clients that support cookies'?


Giancarlo

> > You say that a proper interpretation of
> > session use_cookies
> > mean
> > "If cookies are enabled, PHP will use them" (cfr)?
> >

Re: [Phplib-users] cookie_mode, fallback_mode, security

[Giancarlo P. <gia...@na...>]

D Rothe wrote:
> 
> Basic question here:-
> Could someone briefly explain why having a SID in the URL is so much more
> vulnerable to interception than being passed back via a cookie? (I
> did not understand Sascha Schumann's 'social engineering' reasoning) If,
> say, the connection is secure is not 'all' the data (including all the
> URL) also encrypted?

this is not  aproblem of transport, but initiation, that happens before.
Its behaviour is the same whatever.

in fact as it is now, it is impossible to set php in that way.

I attach you my interpretation of the meaning of session.use_cookies, as
I wrote to Sascha Schumann.
This supposes that you can know if a session preexisted. But I am not
too concentrated today ;-) so maybe you can check it for logic? Sent it
anyway...


Giancarlo

> Sorry to annoy you.
> 
> You say that a proper interpretation of 
> session use_cookies 
> mean
> "If cookies are enabled, PHP will use them" (cfr)?
> 
> In a session environment can't you (we) simply trigger the change 
> of  a 'mode' session environment? That would limit the possibility to
> downgrade, and limit the use of mode 'get' only among clients with
> cookies disabled, which fits exactly the interpretation given. 
> 
> This supposes that, knowing neither how to read nor how to write, if you
> find a SID in the url you try to use cookies *anyway*. 
> With this respect I noticed a difference in behavior among these
> versions:
> 
> php 4.06 gets the SID from the URL, but leaves a cookie and keeps on
> relying on that
> 
> php 4.2.1 gets the sid from the URL, leaves no cookie and keeps relying
> on the SID in url.
> 
> The behavior of 4.06 was more sane. 
> 
> Giancarlo
>

Re: [Phplib-users] cookie_mode, fallback_mode, security

[D R. <da...@er...>]

Basic question here:-
Could someone briefly explain why having a SID in the URL is so much more
vulnerable to interception than being passed back via a cookie? (I
did not understand Sascha Schumann's 'social engineering' reasoning) If,
say, the connection is secure is not 'all' the data (including all the
URL) also encrypted?

Thanks
David

----- Original Message -----
From: "Giancarlo Pinerolo" <gia...@na...>
To: "phplib-users" <php...@li...>
Sent: Thursday, June 13, 2002 9:34 AM
Subject: [Phplib-users] cookie_mode, fallback_mode, security


People that disable cookies know that they have to reenable them before
doing their home banking.

In fact the session mode="cookie" combined with fallback_mode="cookie"
and block_alien_sid setting will never, ever allow a SID to be forcedly
taken from a basically untrustable origin: the URL, that is user input.

The session manage of php4 had no possibility to block it, but I wrote
to Sascha Schumann and I got this patch what should add a
session.use_only_cookies to php.ini.

So I think this will take soon the session4 level of security to that of
the stable cvs branch.

I want to stress the importance of such a setting, and the fact that, as
php as been since session inception, there has been no way to setup php
NOT to give anyway priority to a SID in the URL.
This flaw could allow a whole series of stealth appropriation or
reappropriation of session statuses.

This is it

Giancarlo

> Hi,
>
>     I have now committed source for an additional option which enables
>     administrators to protect their users from this whole class
>     of attacks.
>
>     By enabling `session.use_only_cookies´, all data sources but
>     cookies will be disabled.  Attacks which rely on the ability
>     of passing session ids in URLs will become ineffective
>     immediately.
>
>     Please note that this class of attacks relies on social
>     engineering.  To the same extent, your users could be
>     manipulated to enter their credentials into a faked
>     login screen or make them available to the attacker through
>     alternative means.
>
>     The option `session.use_only_cookies´ has been committed to
>     the PHP CVS which means that it will be available with the
>     next PHP release.  You can upgrade existing PHP deployments
>     by applying this patch:
>
>     http://apache.org/~sascha/use-only-cookies.txt
>
>     Regards,
>     - Sascha

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=dntextlink

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

[Phplib-users] cookie_mode, fallback_mode, security

[Giancarlo P. <gia...@na...>]

People that disable cookies know that they have to reenable them before
doing their home banking.

In fact the session mode=3D"cookie" combined with fallback_mode=3D"cookie=
"
and block_alien_sid setting will never, ever allow a SID to be forcedly
taken from a basically untrustable origin: the URL, that is user input.

The session manage of php4 had no possibility to block it, but I wrote
to Sascha Schumann and I got this patch what should add a
session.use_only_cookies to php.ini.

So I think this will take soon the session4 level of security to that of
the stable cvs branch.

I want to stress the importance of such a setting, and the fact that, as
php as been since session inception, there has been no way to setup php
NOT to give anyway priority to a SID in the URL.
This flaw could allow a whole series of stealth appropriation or
reappropriation of session statuses.

This is it

Giancarlo

> Hi,
>=20
>     I have now committed source for an additional option which enables
>     administrators to protect their users from this whole class
>     of attacks.
>=20
>     By enabling `session.use_only_cookies=B4, all data sources but
>     cookies will be disabled.  Attacks which rely on the ability
>     of passing session ids in URLs will become ineffective
>     immediately.
>=20
>     Please note that this class of attacks relies on social
>     engineering.  To the same extent, your users could be
>     manipulated to enter their credentials into a faked
>     login screen or make them available to the attacker through
>     alternative means.
>=20
>     The option `session.use_only_cookies=B4 has been committed to
>     the PHP CVS which means that it will be available with the
>     next PHP release.  You can upgrade existing PHP deployments
>     by applying this patch:
>=20
>     http://apache.org/~sascha/use-only-cookies.txt
>=20
>     Regards,
>     - Sascha

Rép.: Re: [Phplib-users] new.auth.inc

[Giancarlo <gia...@na...>]

But did you see that there are two examples of page.inc?
One is named page.inc_SPLASHFORM, and works as normal phplib: the form is splashed on a page by itself. This is a global beahvior. 

The other one is named page.inc_DEFERFORM, and the showup of the form is deferred for later use.
You have to use this one. An example is in the showoff.php3_DEFERFORM.

Did you read the README?

Gian

Re: [Phplib-users] again auth.inc and perm.inc !

[Tarique S. <ta...@sa...>]

On Mon, 10 Jun 2002, Michael Chaney wrote:

> On Mon, Jun 10, 2002 at 05:22:39PM +0200, Giancarlo Pinerolo wrote:
> > You mean we should integrate it into phplib? Or that we should migrate
> > to phpauth?
> 
> Whatever you want to do.  It's all GPL'd.

I am sure you meant LGPL'd ?

else it would be not possible to use it in commercial projects

Tarique

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

Re: [Phplib-users] new.auth.inc

[Andrey L. <an...@nk...>]

On Mon, 2002-06-10 at 22:00, Giancarlo Pinerolo wrote:

> var $nobody has no more sense because
>=20
> any page that may go for both authd/not_authed needs auth class=20
> user & perm are optional, and depend on your needs
>=20
> I realized that after I published the patch.
>=20
> you can use your default_auth class, or your auth,
> without difference.
> auth->[uid]=3D=3D nobody is not checked anymore.
>=20

If so, why difference exists? If $nobody is false, all if's in your
new.auth.inc->start() fails and auth->start() returns false.
then new.page.inc do the folowing:
      if (!$auth->start())
         {
         page_showform();
         $sess->freeze();
         exit;
         }

We've got the same behaviour as in phplib's auth version: page_showform
is shown from that moment and forever until one reloads browser.

Actually if auth_preauth method is overrided as Matteo Sgallaverni
suggested On Mon, 2002-06-10 at 01:10. everething seems to work fine
with new.auth.inc, but IMHO its not a RIGHT way of using auth.=20

Well may be i'm wrong...:) Anyway i's seems that everyone here is
writing his own The Ultimate And The Best auth class and nobody using
that from library:) i really don't want to write another one:)

--=20
Andrey Lebedev
Naujoji Komunikacija

Re: [Phplib-users] again auth.inc and perm.inc !

[Michael C. <mdc...@mi...>]

On Mon, Jun 10, 2002 at 05:22:39PM +0200, Giancarlo Pinerolo wrote:
> You mean we should integrate it into phplib? Or that we should migrate
> to phpauth?

Whatever you want to do.  It's all GPL'd.

> I've seen phpauth, but phplib has a wealth of features that phpauth
> doesn't have. I thinkk actual users of phplib would miss them.

Name one.  There are no features missing that I use (and plenty of
features that I've added that are needed in phplib), but some people
may want templates.  It should be possible to bring the code over
with no changes.

> If you are proposing to integrate, let's have a look.
> My auth.inc works 100% within the phplib framework. Any site using
> phplib will not notice the substitution. 
> In fact the new method start is really barebone, and the
> login_in_process state flag can be added in a breeze.
> To integrate phpauth into the eisting phplib frame I think would require
> more work than that.

Given that phplib's auth is broken, I don't care to make a drop-in
replacement.  Some of the problems are fundamental to its design, such
as the following mess:

if ($auth && $auth->is_authenticated() && $auth->is_authenticated()!='form') ...

I would rather *not* emulate that.  I also want to get away from
including tons of files, I'd rather just call functions since you don't
have the confusing scoping issues that file inclusion may bring.

I could go on, but you get the point.  I cover most of this in my docs,
anyway, read them to understand most of the issues behind the divergence
from phplib's auth class.

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

Re: [Phplib-users] again auth.inc and perm.inc !

[Giancarlo P. <gia...@na...>]

Matteo Sgalaberni wrote:

> IMHO actual phplib auth is correct and don't have all problems that
> you describe. If you want to mantain another auth mantain it by
> yourself.

The problem is that in the last years most of the activity of the
maintainers of phplib has been to 'handle out' workarounds and
unsupported patchess on these topics: login forms within pages,
cancel_login, auth_nobody, back button not possible, etc.
And everytime I said: there is some rot behind that we'd better fix once
for all. If for you is OK you can guard you copy of phplib, and keep on
using it. Me, I already started to give up on passing patches to
something I know is broken.

Giancarlo

Re: [Phplib-users] new.auth.inc

[Giancarlo P. <gia...@na...>]

Andrey Lebedev wrote:
> 
> Hi,
> I like an idea of new auth class by Giancarlo, but i'm actually can't
> make it work as i wish. I hope Gian or any body who are using this patch
> can help...:)
> 
...

> now when $nobody is false, the last thing outputed is "this is a login
> form.".
> 
> when $nobody us set to true, i see whole page, but nothing except
> auth_preauth is calling.
> 

var $nobody has no more sense because

any page that may go for both authd/not_authed needs auth class 
user & perm are optional, and depend on your needs

I realized that after I published the patch.

you can use your default_auth class, or your auth,
without difference.
auth->[uid]== nobody is not checked anymore.

I have now posted the latest version.
there are two page.inc examples:

new.page.inc_SPLASHFORM
new.page.inc_DEFERFORM

and two showoff.php3 examples

showoff.php3_SPLASHFORM
showoff.php3_DEFERFORM


TODO
-Throughoutly check behaviour
-Test all the way when !perm->have_perm(whatever) and login 
 form is presented and submitted
-The intermediate login_in_progress swich stuff.I'll add it 
 in the future, also to be compatible with those who have the
 cancel_login stuff ;-(
-Put all this choice (have/not_have an intermediate state a la
 'form') under a nice switch?



Giancarlo

Re: [Phplib-users] again auth.inc and perm.inc !

[Matteo S. <sg...@sg...>]

On Mon, Jun 10, 2002 at 05:22:39PM +0200, Giancarlo Pinerolo wrote:
> > and I've spent that year fixing them.  Please don't duplicate effort.
> 
> You mean we should integrate it into phplib? Or that we should migrate
> to phpauth?
IMHO actual phplib auth is correct and don't have all problems that
you describe. If you want to mantain another auth mantain it by
yourself. And who want to migrate to phpauth or whatever is free to do
this.

Don't touch phplib auth.inc. 

> I've seen phpauth, but phplib has a wealth of features that phpauth
> doesn't have. I thinkk actual users of phplib would miss them.

You think a lot of things. First read
http://www.kill-9.it/guido/rfc1855.txt. Your quoting is awfull.

> If you are proposing to integrate, let's have a look.
> My auth.inc works 100% within the phplib framework. Any site using
> phplib will not notice the substitution. 
It probably works fine, but IMHO it is very dirty coded. 

> But it's all 'a debatre', to be discussed.
The answer to this debate IMHO is in an italian way: "anche no".

Sincerly

Matteo

-- 
    Matteo Sgalaberni                  |     Web    : http://www.sgala.com
    --                                 |     E-Mail : ma...@sg...
    System and Application Engineer    |
-------------------------------------------------------------------------------