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

[Phplib-users] phpList & changing preferences

[Mike G. <mi...@op...>]

Hello Michiel,

Couple of problems with 1.7.1 that I've noticed thus far.  Might just be
my install..  But I can't seem to change preferences:

http://www.billblaikie.org/lists/?p=preferences&uid=12d9d3bc007ee4d2c9f37ebeebe8e553


When you are unsubscribing it seems to toss in no header and the phplist
footer (though it must not be referring to config/footer.inc as that's
just a symbolic link to my footer. The unsubscribe works (which is the
most important thing), but would like the consistency of the
header/footer files:

http://www.billblaikie.org/lists/?p=unsubscribe&hash=12d9d3bc007ee4d2c9f37ebeebe8e553 
I'd also like to know if we can assume that the admin directory doesn't
need a separate password on it now with the default login structure. 
This would be ideal so folks wouldn't have to login twice.

Probably would have better thought out questions but I've been writing
this with a screaming child under foot.

Mike
-- 
Mike Gifford, OpenConcept Consulting, http://www.openconcept.ca
Open Source Web Applications for Social Change.
Featured Clients - http://kenora.clc-ctc.ca | http://kingston.clc-ctc.ca
We are drowning in information, but starved for knowledge. - John 
Naisbilt

[Phplib-users] phplib-php4 object resumption differences

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

Now I realize a basic difference among the two, and really appreciate sound 
phplib ideas like pt, classname, persistent slots etc.

Let's see the auth object as an example, which seems I never know enough.

In phplib It has 2 fashions: default_auth and normal.
When phplib sess stores the object, it stores text, wich is in fact code that 
is evalued at runtime. This text says: generate a new class by that class 
name, and instantiate these varalues and properties. It does not reinsantiate 
all properties, but only those that were marked as persistent_slots. In 
practice it generates a new object with the name and definition available at 
runtime, and merges into theat the persistent_slots found.

php4, on the other hand, stores full object and reinstiantiates them 
automatically at startup, with all the values like they were. At runtime 
these values are reloaded, ALL the values are  taken back. It is not a merge.
I think this is a major difference

With persistent slot you don't leave unconscoiusly, unaccounted or unwanted 
data around. 
Wheren't we of phplib, those who leave the id and nothing  more, for greater 
security? 
I read that in every example article about 'good session mangmnt rules': 
leave a minimud md5 ID, and hook most values in the db...So note  that with 
php4 everything is written in the sess_ file, plaintext, passwd etc, if you 
don't provide tu unset everything not needd before page_close.

Which is much the same as a reversing persistent_slot, but uglier

ciao bonanotte

Gian

Re: [Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net

[Joe S. <jo...@be...>]

On Thu, Sep 26, 2002 at 12:11:28PM -0500, Joe Stewart wrote:
> > 
> > 
> > >>  maybe references to the session variables should be put into $_SESSION
> > >>  in Session::register as well, since $HTTP_SESSION_VARS and $_SESSION
> > >>  are not the same arrays. That would eliminate freeze in Session. I
> > >>  don't like that freeze idea :)
> >  
> > JS> In practice this hasn't worked for me.  I'd like to get rid of that ugly 
> > code in sess->>freeze too.  It was just proof-of-concept.
> >
> 
> Okay, got this to work too with Gian's session4.inc.new with only one 
> small change.
>

Sorry to follow up my own post, but I was wrong.   I can't make this work 
and I'm not going to spend a lot of time trying.  It works as posted with 
the sess->freeze method.  I'm still not understanding that the state would 
be saved with register_globals off by saving a variable to $_SESSION 
earlier in the script.  
 
> So, corresponding patches, etc will be updated accordingly.
> 

done.  Some modifications to the demo files was done too.

Joe

Re: [Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net

[Joe S. <jo...@be...>]

On Thu, Sep 26, 2002 at 11:49:56AM +0400, Maxim Derkachev wrote:
> 
> Sorry, I meant page.inc, not prepend.php, which is used to include all
> the necessary classes. Page.inc itself just for such conditionals.
> 
> JS> It also moves code that is required for session4.inc to work 
> JS> correctly in this state out of the class.
> Well ... but that would be much more efficient :)
> 
Like I said, I'm open.  Just using extract would be fine ( outside any 
function I guess?)

> Variables may be registered in both ways, by using $sess->register()
> or by direct assignment to $_SESSION keys. So, we should mind both
> ways in is_registered and unregister. I suspect
> session_register/session_unregister/session_is_registered know nothing
> about $_SESSION array. $_SESSION and $HTTP_SESSION_VARS (the old way)
> are different arrays, and not linked to each other.
> 

yes, this seems to be the case.

> JS> I ask because Gian's patch basically chose the _SESSION route if globals 
> JS> off.  He and I found that the session_register, session_unregister, and 
> JS> is_registered all function as before.  See his added note to the patch on 
> JS> sf.net.
> JS> The one anomaly he found is on the same iteration that the session
> JS> variable is registered, he could use $_SESSION[variablename] to get the 
> JS> variable contents.  I have not been able to get this to work ( It could be 
> JS> my test).  
> 

Okay, got it to work.  It was my test. Note however that the contents of 
$_SESSION[variablename] are not kept up to date if register_globals is 
off.

A simple test in pages/index.php3:

             printf("<h1>Per Session Data: %s</h1>\n", ++$s);
add---->     printf("<h1>Per Session Data: %s</h1>\n", $_SESSION['s']);


> Yes, I saw the note, but if they changed the behavior once, nothing
> prevents them from changing things again, e.g. for performance
> reasons. The documented behavior is that those functions don't work
> with register_globals=off.
> 

totally agree.

> 
> 
> >>  maybe references to the session variables should be put into $_SESSION
> >>  in Session::register as well, since $HTTP_SESSION_VARS and $_SESSION
> >>  are not the same arrays. That would eliminate freeze in Session. I
> >>  don't like that freeze idea :)
>  
> JS> In practice this hasn't worked for me.  I'd like to get rid of that ugly 
> code in sess->>freeze too.  It was just proof-of-concept.
>

Okay, got this to work too with Gian's session4.inc.new with only one 
small change.

So, corresponding patches, etc will be updated accordingly.

Any problem moving the require statement for session4.inc out of 
session4_custom.inc? 

thanks,

Joe 

> -- 
> Best regards,
> Maxim Derkachev mailto:max...@bo...
> IT manager,
> Symbol-Plus Publishing Ltd.
> phone: +7 (812) 324-53-53
> www.books.ru, www.symbol.ru 
> 

[Phplib-users] new_user_md5.php

[Marko K. <M.K...@os...>]

Hi,

I noticed that in new_user_md5.php one should probably insert
a
	reset($HTTP_POST_VARS);

otherwise the walk through the args doesn't work if the user already did
something with with that array!

Bye,
Marko

Re: Re[2]: [Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net

[Dr T. S. <ta...@sa...>]

On Thu, 26 Sep 2002, Marko Kaening wrote:

> Session work, auth works, user4 works, the only quirck is that oohforms
> doesn't work without complete restore of all POST parameters.


From the notes in the PHPlib manual
===================================
The following file contains patch for OOHForms to work with 
register_globals off

http://www.sanisoft.com/phplib/oohforms_patch.zip
===================================

Cheers
Tarique

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

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

Re[2]: [Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net

[Marko K. <M.K...@os...>]

> Because of 'files' in Your $sess->module. Should be 'user' for the
> custom storage, like db.
aaaaaaaaaaaaaaaaaaaaaaarghhhhhh,
well, of course, I am so stupid... Totally forgot this point. I saw it in
the code and I used it this way with 'user' in my old application. But
since I took Joe's code as is I certainly didn't change the module=files
setting. Now I understand why everything worked just fine with standard
php4 sessions and your style...
THANKS, Maxim.

Now my app works fully with "register_globals=off", php3-, php4- and
php4-custom sessions!!!!!!!!!!! I only have to revise most of my scripts
concerning all these GET-variables which I still use on my page.

Since I don't use default auth I don't seem to have problems anymore.
Session work, auth works, user4 works, the only quirck is that oohforms
doesn't work without complete restore of all POST parameters.

Bye,
Marko

Re[2]: [Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net

[Maxim D. <max...@bo...>]

Hello Marko,

Thursday, September 26, 2002, 12:49:52 PM, you wrote:
MK> But, what is strange is that the session4_custom still doesn't seem to
MK> work properly, as it is coded now. Though I use a Session_Custom with
$sess->module set to 'files' there are no entries created in the mysql db,
MK> instead I see the usual php4 /tmp/sess* file appearing...

MK> Any idea why this is so?

Because of 'files' in Your $sess->module. Should be 'user' for the
custom storage, like db.


-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

[Phplib-users] Re: my tests say good

[Dr T. S. <ta...@sa...>]

On Thu, 26 Sep 2002, Giancarlo wrote:

Hello Gian,

> test 1: plain phplib 
> ------
> this is jus php-lib-stable, fresh co from cvs, Register_globals On,
> PLUS this change in defauth.php3

I just sent a somewhat identical mail 

Also I found the horrible hack which I had used to cancel the login on a
default_auth page 

$auth->login_if($again AND $auth->auth["uid"] == "nobody" AND
!$cancel_login );

BUT this is very bugging. Someone long back had submitted a patch which
prevented this - will have to search


Tarique

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

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

Re: [Phplib-users] PHPlib release

[Dr T. S. <ta...@sa...>]

On Thu, 26 Sep 2002, Giancarlo wrote:

> I think this worked somehow in session3. There are some quirks with 

No - I dont think this ever worked or for that matter is supposed to work 

That is the precise reason the cancel_login button was put there :-(

I dont remember where I had abused this feature long back when I was a
novice to make it work

So the sequence of events is this

1) You go to a page which has Auth you are shown a login form
2) You hit the browser back button and go to a page without Auth - this is
fine
3) BUT if you *now* hit a page with default_Auth you will still be shown a
login form - unless you have coded a cancel_login button you are stuck :-(
 
4) However if you hit a default_auth page without previously going to a
page with auth, default_auth will work fine BUT again if you go to a page
with auth it will *NOT* show the login but tell you that you are logged in
as nobody

Guess it is a problem with $this->auth["uid"] in auth class getting set as
"form" / "nobody" in case 3 and 4 respectively

So the caveat is - DO NOT mix auth and default_auth 

HTH
Tarique

P.S. Thanks for the effort you are putting in :-) 

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

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

Re: [Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net

[Marko K. <M.K...@os...>]

Hi Joe and Maxim,


I got Joe's code from the snapshot up and running with
'register_globals=off' eventually.

I struggled a lot to get my app back to live, but to the cost of not
allowing anymore appended SIDs to my urls with 'session_trans_id=0'. It
doesn't hurt much, since it looks like it makes sense to use cookies
instead.

But, what is strange is that the session4_custom still doesn't seem to
work properly, as it is coded now. Though I use a Session_Custom with
$sess->module set to 'files' there are no entries created in the mysql db,
instead I see the usual php4 /tmp/sess* file appearing...

Any idea why this is so?

Greetings,
Marko

[Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net

[Maxim D. <max...@bo...>]

Hello Joe,

Wednesday, September 25, 2002, 8:33:33 PM, you wrote:
>>  This could be also done in prepend.php by doing extract($_SESSION);
 
JS> Yes. This would put more conditionals in prepend which I personally don't 
JS> like.

Sorry, I meant page.inc, not prepend.php, which is used to include all
the necessary classes. Page.inc itself just for such conditionals.

JS> It also moves code that is required for session4.inc to work 
JS> correctly in this state out of the class.
Well ... but that would be much more efficient :)


>> in Ssssion::is_registered:
>>  return session_is_registered($var_name);
>>  should be
>>  return (session_is_registered($var_name) || 
>>  isset($_SESSION[$var_name]));
 
>>  in Session::unregister:
>>  $ok = $ok && session_unregister ( trim($var_name) );
>>  should be
>>  $var_name = trim($var_name);
>>  $ok = $ok && (session_unregister($var_name) || 
>>  unset($_SESSION[$var_name]));
 
JS> What effect should you see with this change?

Variables may be registered in both ways, by using $sess->register()
or by direct assignment to $_SESSION keys. So, we should mind both
ways in is_registered and unregister. I suspect
session_register/session_unregister/session_is_registered know nothing
about $_SESSION array. $_SESSION and $HTTP_SESSION_VARS (the old way)
are different arrays, and not linked to each other.

JS> I ask because Gian's patch basically chose the _SESSION route if globals 
JS> off.  He and I found that the session_register, session_unregister, and 
JS> is_registered all function as before.  See his added note to the patch on 
JS> sf.net.
JS> The one anomaly he found is on the same iteration that the session
JS> variable is registered, he could use $_SESSION[variablename] to get the 
JS> variable contents.  I have not been able to get this to work ( It could be 
JS> my test).  

Yes, I saw the note, but if they changed the behavior once, nothing
prevents them from changing things again, e.g. for performance
reasons. The documented behavior is that those functions don't work
with register_globals=off.



>>  maybe references to the session variables should be put into $_SESSION
>>  in Session::register as well, since $HTTP_SESSION_VARS and $_SESSION
>>  are not the same arrays. That would eliminate freeze in Session. I
>>  don't like that freeze idea :)
 
JS> In practice this hasn't worked for me.  I'd like to get rid of that ugly 
code in sess->>freeze too.  It was just proof-of-concept.

If we register variables the both ways in the both session arrays,
freeze hs nothing to do in Session4, cause the standard savehandler
itself knows where to look for the session variables (though, it needs to be in
Session4_Custom)




-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: [Phplib-users] php4 session saves whole obj properties, includeud db pass

[Maxim D. <max...@bo...>]

Hello Giancarlo,

Wednesday, September 25, 2002, 10:31:30 PM, you wrote:

G> I am disappointed, again, in discovering that.
G> every property of the class is saves, and in each /tmp/sess_ there's 
G> everything for the connection,included puser an pass in cleartext.

G> phplib used to save only the persisten vars.

PHP4 has a trick to avoid that. All the classes that can be fed to
serialize may define methods __sleep and __wakeup. __sleep is called
just before serialization, and __wakeup is called just after
unserialization. So, we should simply define those methods in Auth and
other classes that are meant to be persistent and use DB -
__sleep should unset db handle, __wakeup should define it.

-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: [Phplib-users] php4 session saves whole obj properties, includeud db pass

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

Il 00:29, gioved=EC 26 settembre 2002, Michael Chaney ha scritto:
> On Wed, Sep 25, 2002 at 11:59:04PM +0200, Giancarlo wrote:

> > > I always erase passwords.

> > You mean you=20
> >
> > unset ($db->Host);
> > unset ($db->User);
> > unset ($db->Database);
> > unset ($db->PAssword);
> >
> > before page_close/freeze?


> I see no reason to make the $db variable persistent, and plenty of
> reason to not do that.
>
> Michael

Oh yes.. Great!=20
Also I apprecieated when you suggested a good setup for Virtual host ini=20
settings.
Have to find that message back.


Gian=20

Re: [Phplib-users] php4 session saves whole obj properties, includeud db pass

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

On Wed, Sep 25, 2002 at 11:59:04PM +0200, Giancarlo wrote:
> Il 00:02, gioved=EC 26 settembre 2002, Michael Chaney ha scritto:
> > On Wed, Sep 25, 2002 at 08:31:30PM +0200, Giancarlo wrote:
> > > I am disappointed, again, in discovering that.
> > > every property of the class is saves, and in each /tmp/sess_ there's
> > > everything for the connection,included puser an pass in cleartext.
> > >
> > > phplib used to save only the persisten vars.
> >
> > I always erase passwords.
> >
>=20
> You mean you=20
>=20
> unset ($db->Host);
> unset ($db->User);
> unset ($db->Database);
> unset ($db->PAssword);
>=20
> before page_close/freeze?

I see no reason to make the $db variable persistent, and plenty of
reason to not do that.

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

Re: [Phplib-users] php4 session saves whole obj properties, includeud db pass

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

Il 00:02, gioved=EC 26 settembre 2002, Michael Chaney ha scritto:
> On Wed, Sep 25, 2002 at 08:31:30PM +0200, Giancarlo wrote:
> > I am disappointed, again, in discovering that.
> > every property of the class is saves, and in each /tmp/sess_ there's
> > everything for the connection,included puser an pass in cleartext.
> >
> > phplib used to save only the persisten vars.
>
> I always erase passwords.
>

You mean you=20

unset ($db->Host);
unset ($db->User);
unset ($db->Database);
unset ($db->PAssword);

before page_close/freeze?

Gian

Re: [Phplib-users] php4 session saves whole obj properties, includeud db pass

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

On Wed, Sep 25, 2002 at 08:31:30PM +0200, Giancarlo wrote:
> I am disappointed, again, in discovering that.
> every property of the class is saves, and in each /tmp/sess_ there's 
> everything for the connection,included puser an pass in cleartext.
> 
> phplib used to save only the persisten vars.

I always erase passwords.

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

[Phplib-users] interstitial?

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

;-))

> However, I've lost all interstitial auth/perm.  I know you explained this,
> but I don't find it workable.

This word, interstitial, is becoming popular. Remembers me the dentist.
What do you men here for 'i?ve lost all interstitial auth/perm ?

An interstice is a narrow passage, isn't it? 
An interstite is something so narrow, that you can pass through only one by 
one. 
So i suppose that by  'interstitial' we were speaking about the 
login_in_progress blocking state. 
Where you need a cancel login to get free of a there-but-not-yet-born auth 
object in session



>
> Using different include/require files for parts the application doesn't
> sit well.
>
> I use the interstitial checks to prompt a login for such things as admin

And what is intersitial check?

> One feature needed for interstitial use is the preservation of GET and
> POST variables.

Preservation of get post variables, yes. I got this. 
The splashform model is needed if you want to direct someone to a URL with 
GET (I am not sure POST too) parameters that auth will intercept,, show a 
login form if needed, an pass on to the page that was originally requested.

I think this can be done only with the splashform behaviour. It works like 
that already, as auth did. You point a link to a protected page, and phplib 
splases the login form, and after you successfully login you are taken to the 
real page. All these have the same url, so get and maybe post data too can be 
carried through this login process

Anyway with my auth, a page that contains a form that points to a 
login/register page can be well without  auth class, or an auth class and 
deferred form behaviour (visible, with different contents, by both suthed an 
unauthed users, as default_auth)


>  This can be done by registering them in auth_loginform()
> and restoring in auth_validatelogin() but would be much more elegant
> designed into auth.
>
> Joe

Re: [Phplib-users] Template problems

[Mike G. <Mik...@sa...>]

I'm with you on this!

Dr Tarique Sani wrote:

> On Thu, 26 Sep 2002, Richard Archer wrote:
>
> > I'm not a big fan of user comments on docs, but I never stopped to
> > think about why. That post explains a lot!
>
> Well I always have found notes to be a treasure trove of tips and tricks
> and that is why I went thru the trouble of setting one up for PHPlib and
> also see to it that incorrect or inconsequential entries do not last more
> than a few hours
>
> > Perhaps the user comments on the PHPLIB docs should be used to
> > highlight to the doc editors (*wave* Tarique ;) where the docs need
> > enhancing. Sort of like the SF trackers are to the code.
>
> Eeps! please dont start that dangerous trend - I already delete several
> bug reports and queries a week which I get despite all ... ...
>
> Tarique
>
> --
> =============================================================
> PHP Applications for E-Biz: http://www.sanisoft.com
>
> Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
> =============================================================
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

--
_______________________________________________________________________
Michael D Green
SaeSolved:: Custom-Built Web Applications  --  http://www.saesolved.com
1552 Beachview Drive, Virginia Beach, VA 23464-7225, USA;  757.467.1552
http://www.everypeople.net                   http://www.sitewidgets.com
_______________________________________________________________________

Re: [Phplib-users] Re: blocking mode vs default_auth

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

Il 19:30, mercoled=EC 25 settembre 2002, Chris Johnson ha scritto:
>
> So, Gian, are you saying that your new Auth class provides both behavio=
rs,
> but that your "splash login page" although it looks the same to the
> user, it is distinctly functionally different from the current PHPLIB
> blocking method?

By blocking mode, interstitial mode, we are not talking about access, or=20
blocking access.

We are talking about blocking the authentication process, in a 'login_in=20
progress' state,=20
or, more clear, 'we_have_sent_the_form_and_expect_loginfields', so the=20
session is blocked until we get the cancel_login
Effects:=20
-If you had just visited an unprotected page, you can't click 'back', you=
 =20
need to press cancel_login.
-If you open an unpreotected page in a new browser window you get the log=
in=20
form,=20
-etc

 because you presistent session it has an $auth object in it, with=20
auth[uid]=3D"form", that is you are not logged on, but you have the auth =
object=20
to either clear or fully start.


>
> I'm having a hard time understanding.  I don't want users to be able
> to see ANY protected page without logging in, and ALL of my pages are
> protected pages.  The way it works now using the PHPLIB blocking method=
,
> all I have to do is call page_open() and it is assured that they are
> blocked until they have logged in and gotten a session ID in a cookie
> (fallback to GET).  Does your "splash form" behavior in your new Auth
> do that?

yes, access blocking is same as before.

Gian

RE: [Phplib-users] Template problems

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

At 01:08 PM 9/25/2002 -0500, bpopp wrote:
>I've never really seen this done, and I'm not sure it would work, but you
>could add a rating system which automatically expired comments not meeting a
>certain ranking. If the comment doesn't have a high enough rating after,
>say, a month, you sort it lower in the list. The problem is going to be that
>some comments may depend on others which failed to make the grade (and were
>hidden).
>
>-bpopp

I'd be against that if the posts dropped off completely.  The problem is 
that some users may post solutions to particularly rare but, hard to 
resolve problems or, may post about problems that most users don't 
understand ... until they are forced to deal with them by encountering the 
specific conditions that produce the problem.  As long as even those posts 
could be pulled up by a search or enough skimming, ranking might work okay.


Andrew Crawford
An...@Ev...

[Phplib-users] php4 session saves whole obj properties, includeud db pass

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

I am disappointed, again, in discovering that.
every property of the class is saves, and in each /tmp/sess_ there's 
everything for the connection,included puser an pass in cleartext.

phplib used to save only the persisten vars.

...my arms fall aside...

Gian

RE: [Phplib-users] Template problems

[Brian P. <bp...@ct...>]

The biggest problem with user comments is the idle chatter and repetition
that develops if strict moderation isn't enforced. The PHP manual is the
best I've seen, but it can still get off-track sometimes. 

I've never really seen this done, and I'm not sure it would work, but you
could add a rating system which automatically expired comments not meeting a
certain ranking. If the comment doesn't have a high enough rating after,
say, a month, you sort it lower in the list. The problem is going to be that
some comments may depend on others which failed to make the grade (and were
hidden). 

-bpopp

-----Original Message-----
From: Chris Johnson [mailto:ch...@ch...]
Sent: Wednesday, September 25, 2002 12:36 PM
To: Richard Archer
Cc: php...@li...
Subject: Re: [Phplib-users] Template problems


On Thu, Sep 26, 2002 at 12:18:58AM +1000, Richard Archer wrote:
> At 10:09 -0400 25/9/02, Rob Hutton wrote:
> 
> >removed at any time.  I have found it much more effective to eithe
provide a
> >tutorials page in the docs, or put them in the documentation area of the
> >site, not to expect people to go digging through  the user comments to
find
> 
> 
> Interesting.
> 
> I'm not a big fan of user comments on docs, but I never stopped to
> think about why. That post explains a lot!
> 
> Perhaps the user comments on the PHPLIB docs should be used to
> highlight to the doc editors (*wave* Tarique ;) where the docs need
> enhancing. Sort of like the SF trackers are to the code.
> 
>  ...R.

I would agree.  It would be best if PHPLIB gurus and project workers
could review any user comments they come across for correctness and
usefulness and then somehow get the actual documentation updated to
reflect them.

I suppose, if nothing else, we could post follow-up user comments
stating "this is correct and is very helpful -- please add".  Then
someone who has time and who knows how to modify the docs and has
access could actually do the cut/paste, editing and formatting into
the docs themselves.

-- 
    ..chris


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Template problems

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

On Thu, Sep 26, 2002 at 12:18:58AM +1000, Richard Archer wrote:
> At 10:09 -0400 25/9/02, Rob Hutton wrote:
> 
> >removed at any time.  I have found it much more effective to eithe provide a
> >tutorials page in the docs, or put them in the documentation area of the
> >site, not to expect people to go digging through  the user comments to find
> 
> 
> Interesting.
> 
> I'm not a big fan of user comments on docs, but I never stopped to
> think about why. That post explains a lot!
> 
> Perhaps the user comments on the PHPLIB docs should be used to
> highlight to the doc editors (*wave* Tarique ;) where the docs need
> enhancing. Sort of like the SF trackers are to the code.
> 
>  ...R.

I would agree.  It would be best if PHPLIB gurus and project workers
could review any user comments they come across for correctness and
usefulness and then somehow get the actual documentation updated to
reflect them.

I suppose, if nothing else, we could post follow-up user comments
stating "this is correct and is very helpful -- please add".  Then
someone who has time and who knows how to modify the docs and has
access could actually do the cut/paste, editing and formatting into
the docs themselves.

-- 
    ..chris

[Phplib-users] Re: blocking mode vs default_auth

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

On Wed, Sep 25, 2002 at 09:58:07AM +0200, Giancarlo wrote:
> Il 05:43, mercoledì 25 settembre 2002, hai scritto:
> >
> > I currently have a large application which uses the old blocking Auth
> > method and it is the right thing for that application -- all users must
> > be authenticated and there are no default facilities.
> >
> 
> Then what you want is:
> wherever I instantiate the auth feature, if the user bears no authentication, 
> a splash login page is shown by auth itself, your script does not have to 
> check anything. Just instantiating the auth class will do it. You don't 
> really want blocking mode. You wat a splash form behaviour handled by auth 
> itself.
> 
> Others, or you in other apps,  my want:
> 
> whenever I instantiate the auth feature, auth returns me a value that says if 
> the user bears authentication or not. And my script, not auth, decides what 
> to do, when to do it. You don't want blocking mode here either. You want to 
> handle the situation by yourself knowing if the user is logged or not. Tha 
> auths class outputs nothing, it just returns you a value that says if he is 
> logged in or not
> 
> They are two different things, but they eat the tail one each other, as it is 
> now.
> 
> My auth class, with the splashform behaviour, suits your need perfectly the 
> same as before. 
> The 'form' aim (preveting registration with a single POST, maybe from a batch 
> script), is not needed once we are sure, for example, that a new session can 
> be obtained by simply appending ?Example_session=foo to the URL request. The 
> effect is the same as that of having previously requested a login form: 
> prevents single POST registration
> 
> 
> Gian

So, Gian, are you saying that your new Auth class provides both behaviors,
but that your "splash login page" although it looks the same to the
user, it is distinctly functionally different from the current PHPLIB
blocking method?

I'm having a hard time understanding.  I don't want users to be able
to see ANY protected page without logging in, and ALL of my pages are
protected pages.  The way it works now using the PHPLIB blocking method,
all I have to do is call page_open() and it is assured that they are
blocked until they have logged in and gotten a session ID in a cookie
(fallback to GET).  Does your "splash form" behavior in your new Auth
do that?

Thanks!

-- 
    ..chris