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

RE: [Phplib-users] Doc suggestions

[Johnson, K. <kjo...@zo...>]

> Requiring cookies to be enabled is a sure-fire way to guarantee your
> site will break for a small but significant percentage of users.
> 

The most recent statistics I have seen say that 10% of users have cookies
disabled.

Kirk

Rp.: Re: [Phplib-users] Doc suggestions

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

 Richard Archer <rh...@ju...> a écrit le  5/7/02 6:52:

>Requiring cookies to be 
>enabled is a sure-fire way to 
>guarantee your
>site will break for a small but 
>significant percentage of 
>users.
>

but I said that cookies_only should be enforced only after authentication. 
The same people that disable their cookies know too well how to reenable them before reading their email or usenet on yahoo, or managing their bank account.

Then why should everyone pay with a general downgrade in their privacy, just to mock a few and their false beleive to have an increased privacy from this?


>In my opinion, setting a site 
>up in this manner is 
>extremely poor form,
>and I would hate to see the 
>docs recommending this as 
>the preferred
>installation option.
>

IMO not even mentioning it is wrong.

I would like to know which other major scripting language allows any session propagation other than cookie. And which allows the creation of 'unpredictable' session ids provided by the user. Anyone has any insight with asp or coldfusion?

Gian

Re: [Phplib-users] Doc suggestions

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

At 18:40 +0200 4/7/02, Giancarlo wrote:
>Among the many useful suggestions one can read in the docs, I can't
>see any that would state how, for a proper auth, and well before SSL,
>short expire etc. , only a cookie_only propagation mode (mode=cookie,
>fallback=cookie) can guarantee the max security available.

Requiring cookies to be enabled is a sure-fire way to guarantee your
site will break for a small but significant percentage of users.

In my opinion, setting a site up in this manner is extremely poor form,
and I would hate to see the docs recommending this as the preferred
installation option.

 ...R.

Re: [Phplib-users] Doc suggestions

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

Gian,

G> Among the many useful suggestions one can read in the docs, I can't see any that
G> would state how, for a proper auth, and well before SSL, short expire etc.

That is a good point.

G> , only a cookie_only propagation mode
G> (mode=cookie, fallback=cookie) can guarantee the max security available.
And this begin to sound to me like a soap opera. I see this install
just like an option only, not as a must. It does not add substantial
security, while impose tight limits on user behavior. I don't buy this
statement. Only descent usage of your own head can guarantee the max
security available, even with GET fallback mode.

G> I don't know if this info is missing because is too obvious, or because you
G> are not fully convinced of it, or what else.
G> And in fact, by proposing Php4 session (which cannot handle cookie_only mode) for
G> everything, such a setup  is even discouraged .
As well as use of PHP4 because of it is buggy, immature, insecure and miss some
features :)

You made your best to convince everybody in this list and somewhere
else. There would be an OPTION in PHP4 soon to enable cookie-only
session installs, and this can be easily incorporated in session class
or whatever as an OPTION too.
Did you benchmark the speed gain of using PHP4 sessions instead of good old
PHPLib's to discourage use of PHP4 sessions? Well, I don't intend to change you
point of view. But I and many others do have our own.
So, don't think we're so stupid. I do understand your considerations,
but I treat them as highly overestimated.



-- 
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] Doc suggestions

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

On 4 Jul 2002, Giancarlo wrote:

> Among the many useful suggestions one can read in the docs, I can't
> see any that would state how, for a proper auth, and well before SSL,
> short expire etc. , only a cookie_only propagation mode (mode=cookie,
> fallback=cookie) can guarantee the max security available.

Why not add a note in the docs yourself?

Cheers
Tarique

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

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

[Phplib-users] Doc suggestions

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

Among the many useful suggestions one can read in the docs, I can't see any that would state how, for a proper auth, and well before SSL, short expire etc. , only a cookie_only propagation mode (mode=cookie, fallback=cookie) can guarantee the max security available.

I don't know if this info is missing because is too obvious, or because you are not fully convinced of it, or what else. 
And in fact, by proposing Php4 session (which cannot handle cookie_only mode) for everything, such a setup  is even discouraged .

Gian

[Phplib-users] Re: [Phplib-core] Bug Smackdown

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

On Wed, 3 Jul 2002, Maxim Derkachev wrote:

> CVS - session4.inc & session4_custom.inc in the php-lib/php/session
> and phplib4 stuff (I see it in various places), which is not mine.
> By the way, the docs at Tarique's site concerning PHP4 sessions
> (http://www.sanisoft.com/phplib/manual/php4_sessions.php ) are all
> about phplib4.

Have updated the docs wuth respect to above (included part of the mail as
well)

Working on  "A Complete Idiot's Guide (tm) to PHPlib" which will cover the
vhost / .htaccess based install ;)

Cheers
Tarique

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

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

[Phplib-users] Hello...hello...hello...

[<ro...@cu...>]

The archives don't have any messages for a year!  Is this list still active?
 More importantly, what's the status of PHPLib?

[Phplib-users] Re: [Phplib-core] Bug Smackdown

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

Max,

YOU ROCK!  I would marry you but I don't think I could handle Russian
winters, you'd need to take me to Havanna ;)

I will delve into the CVS this week and try to get everything sussed out.
I bet the reason the current docs have the phplib4 info is beacuse the
wrong class is in the -stable CVS.  That would be my fault.


On Wed, 3 Jul 2002, Maxim Derkachev wrote:

> Hello Nathan,
>
> Wednesday, July 03, 2002, 12:18:02 AM, you wrote:
>
> nrh> Also, can someone tell me what *exactly* max's aptches are in the php-lib
> nrh> cvs tree?  I still haven't the foggiest what the frell is missing.  Begin
> nrh> to feel stupid, quite I do.
>
> Well, it's a source of many troubles, misunderstanding and tricky "walkthroughs",
> so I'll try to explain what's exactly going on there.
> History first. More than a year ago there was a discussion in the list on

[snip previous]

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

[Phplib-users] Re: [Phplib-core] Bug Smackdown

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

Hello Nathan,

Wednesday, July 03, 2002, 12:18:02 AM, you wrote:

nrh> Also, can someone tell me what *exactly* max's aptches are in the php-lib
nrh> cvs tree?  I still haven't the foggiest what the frell is missing.  Begin
nrh> to feel stupid, quite I do.

Well, it's a source of many troubles, misunderstanding and tricky "walkthroughs",
so I'll try to explain what's exactly going on there.
History first. More than a year ago there was a discussion in the list on
possibility of adaptation of session class to PHP4 sessions. This
brought to us 3 (three!!!) implementations of native sessions with
PHPLib API. The first was by Teodor Cimpoesu, who, as he noted, did a
quick and dirty hack to show that this is possible. The class was
mainly old session class with some parts changed to calls to PHP4
session API, the other parts (storage, SID propagation and such) just
commented out. The second was by Barendt Scholtus (excuse me, Barendt,
if I misspell), who did the similar job to Teodor, but also changed
user.inc and page.inc in the similar way. He named his effort as
phplib4, and it remains by that name in the CVS now in the unsup
directory. Both implementations just used to be simple and limited wrappers
over PHP4 session module, conforming to the PHPLib API.
Then, I introduced my session4_custom, which was almost fully
rewritten implementation, which was intended not only to conform to
the PHPLib (public) API and use native PHP4 session module, but also provided a
custom save handler, which used PHPLib's CT_*-style containers as a
session data storage, and an interface to the php.ini's session module
settings from within the Session class. Session4_custom could not only store
data in the CT_* containers (custom save handler), but also use native save
handlers - files, mm and so on. Also, because of the incompatibilities
of the new session4_custom with the old User class ideology, I
introduced the new rewritten User class - User4, which was no longer depend on
Session, with compatible public API but very different guts.
Prepend.php & page.inc were also changed a bit to reflect the session
changes.
Then, Ulf Wendel came and said he need clean and working class
urgently. He began to hack session4_custom. He splet the
Session4_custom class in two parts, the first class with common session API
(now in session4.inc), the second with the custom save handler (now in session4_custom.inc),
which extended the first.
As a result, the Teodor's class had been acquired by the new Session4
class, the session4_custom was simplified, both were put to
php-lib/php/session CVS directory, and Barendt's phplib4 moved to unsup
directory.
So, there's two implementations of PHP4 native sessions in the PHPLib
CVS - session4.inc & session4_custom.inc in the php-lib/php/session
and phplib4 stuff (I see it in various places), which is not mine.
By the way, the docs at Tarique's site concerning PHP4 sessions
(http://www.sanisoft.com/phplib/manual/php4_sessions.php ) are all
about phplib4.


-- 
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] Bug Comment

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

Hey folsk,

Can people who use the auto_init function please take a look at the below
linked bug and leave a comment.  I'm not sure this is a bug or design
feature, and if changing would cause problems for those using auto_init()

[ 499079 ] inclusion of auto_init on new sessions
(https://sourceforge.net/tracker/index.php?func=detail&aid=499079&group_id=31885&atid=403611)

thanks

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

Rp.: [Phplib-users] Sessions where are we going??

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

 Donncha O Caoimh <don...@tr...> a écrit le  2/7/02 15:45:

>Right, you want to fix the 
>problems, so do I, and others 
>do too, but if nobody 
>else objects, I think the 
>"secret key" cookie solution 
>might be a way to fix 
>the propogation problem. I 

And what about 'get' mode? 
Because you know that will work only in a 'cookie_or_nicht' env. And how do you enforce that whity PHP4 propagatîon? There does not exist a settiag yet for that.

Gian


>suppose it's best to leave it a 
>few days and get 
>comments from others of 
>course. I'll have a bash at it 
>on our LAN here and 
>mail some code to the list 
>when I have it running.
>
>Donncha.

Re: Rp.: Re: Rp.: Re: [Phplib-users] Sessions where are we going??

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

On 2 Jul 2002, Giancarlo wrote:

>
> It is already damn difficult to have people accept the idea of using a
> new session after auth, only once... And BTW, did you discover a way
> to have PHP4 issue a new id when one already exists? This is the basis
> for both the new changes I'd port to session4: block_alien_sid
> creation and clone sess on authenticated (and I'd add a config to have
> a cookie_or_noway mode 'only' after authentication)
>

Argh!  This is not for phplib-7.x, this is development for phplib-8.0.  If
you'd like to help, please help fix the documented bug in the tracker so
we can begin working on v8 and stop mucking about with 7.x!

Sessions have  *never* been secure!  This is known fact and allways has
been.  There's no easy solution to fixing it either without a good bit of
overhead.  Use SSL, short timeouts and a high GC if you're truly paranoid
about session duplications.  I really fail to see the real threat of
someone using their own session_id other than the fact that *if* someone
were to get ahold of a session_id that was still valid that could be used
against a user.  Then again, that's why auth has it's *own* timer..   If
someone were able to steal a cookie, they would need phyiscal access to
one computer or at least unadluterated access to where that info is
stored.  Having either means than an attacker can do much more than steal
a session -- session stealing is trivial.

The session4 support in the 7.x tree right now is EXPERIMENTAL (as well as
incomplete)!  If you're using it on a production site without a full
understanding of what *exactly* it's doing, you're makeing a foolish
decision.  It is there simply for people to test and *log bugs against* so
it can be fixed and redesigned to replace the origianl php3 based
session.inc in php-lib-stable as is.

> As maybe you know, I don't have 'write access' to cvs anymore, I am
> declaratedly lobbying.
>

Gian, it was your choice to resign.  Please stop being a drama queen about
it.  If you want CVS write access back, please simply ask one of the
project admins and we'll be happy to reinstate you.  I frankly have
utterly no idea why you decided to resign in the first place.

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

Re: Rp.: Re: [Phplib-users] Sessions where are we going??

[Donncha O C. <don...@tr...>]

What I'm proposing is a little different to what you described below. I=20
implemented something similar to protect an app. The secret key was=20
associated with the username.=20
With my proposal I'm associating the key with the session, therefore=20
protecting the session, not the username so that the same username could =
be=20
used multiple times, but the one session couldn't be hijacked by a 3rd pa=
rty.

Donncha.

On Tuesday 02 July 2002 17:54, Mike Green wrote:
> Donncha O Caoimh wrote:
> > I think it's probably an idea worth looking at, does anyone else
> > agree/disagree/care?
>
> In my case (and it is possible that I represent many more than just
> myself), I do care. I have been saving all of the emails in this thread
> with the intention of taking some time to digest the thoughts being
> expressed. But we know where the road paved with good intentions goes ;=
-)
> -- and I so far have not taken that time. So I cannot argue any of the
> points with conviction.
>
> I will remark that, if in my quick scanning of your email on the topic =
I
> understood at all what you were proposing, I believe the idea of a cook=
ie
> with some very random number as the key should work. I worked on a syst=
em a
> while back which was set up (by someone else) with a similar -- if not =
the
> same -- scheme. One of the results was that if one opened another brows=
er
> and logged into the site one was automatically logged out (i.e. the
> "session" was lost) of the site on the original browser. They were,
> however, not using PHP sessions, but a completely home-grown substitute=
 for
> PHP sessions. Probably not nearly as efficient, but it did have the
> advantage that they understood (I think) there own system and (perhaps)=
 no
> one else did...

Re: [Phplib-users] OT: Cookie usage (was: Sessions where are we going??)

[Donncha O C. <don...@tr...>]

I just tested it. When Active Desktop was enabled and I logged in via one=
 of=20
the browsers then the other browser was logged in when I refreshed it.

Donncha.


On Tuesday 02 July 2002 17:36, Layne Weathers wrote:
> A few months ago we hashed this out on the list and someone whose name =
I
> cannot remember enlightened me about IE's behaviour. (I don't know how =
the
> Active Desktop plays into this.)

Re: [Phplib-users] OT: Cookie usage (was: Sessions where are we going??)

[Donncha O C. <don...@tr...>]

Ah, thanks Layne, I tried that and exactly as you described happened. *si=
gh*

Still, on our own site where I work, we only use cookies to propagate ses=
sions=20
and we rarely get complaints from people who can't login. Obviously my co=
okie=20
idea is only useful where fallback=3D'get' isn't used. All is not lost=20
methinks!

Donncha.

On Tuesday 02 July 2002 17:36, Layne Weathers wrote:
> > > this supposes that any browser window shares the same cookie.
> > > I am using Netscape, and it does, but I heard IE might do not.
>
> A few months ago we hashed this out on the list and someone whose name =
I
> cannot remember enlightened me about IE's behaviour. (I don't know how =
the
> Active Desktop plays into this.)
>
> IE can share cookies or not depending on the user. On a Windows machine=
 it
> is possible to force IE into a separate process and therefore not share

Re: Rp.: Re: [Phplib-users] Sessions where are we going??

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

Donncha O Caoimh wrote:

> I think it's probably an idea worth looking at, does anyone else
> agree/disagree/care?

In my case (and it is possible that I represent many more than just myself), I
do care. I have been saving all of the emails in this thread with the intention
of taking some time to digest the thoughts being expressed. But we know where
the road paved with good intentions goes ;-) -- and I so far have not taken that
time. So I cannot argue any of the points with conviction.

I will remark that, if in my quick scanning of your email on the topic I
understood at all what you were proposing, I believe the idea of a cookie with
some very random number as the key should work. I worked on a system a while
back which was set up (by someone else) with a similar -- if not the same --
scheme. One of the results was that if one opened another browser and logged
into the site one was automatically logged out (i.e. the "session" was lost) of
the site on the original browser. They were, however, not using PHP sessions,
but a completely home-grown substitute for PHP sessions. Probably not nearly as
efficient, but it did have the advantage that they understood (I think) there
own system and (perhaps) no one else did...

>
>
> Donncha.
>
> On Monday 01 July 2002 17:48, Giancarlo wrote:
> >  Donncha O Caoimh <don...@tr...> a écrit le  1/7/02
> 14:23:
> > >Just a thought for an extra
> > >layer of protection for the
> > >user:
> > >The first time the user visits
> > >the site we set a cookie on
> > >their browser with
> > >some very random number
> > >as the key. Store the value
> > >of the key in the
> > >session.
> > >Each time after that modify
> > >the key, set the cookie, and
> > >store it in the
> > >session.
> >
> > That would be heavy on the server. Imagine a multi-frame where each tries
> > to lock&write in very rapid sequence... Maybe  ok for terminal like
> > screens, tellers, mono thread slow stuff.
>
> -------------------------------------------------------
> 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
_______________________________________________________________________

[Phplib-users] OT: Cookie usage (was: Sessions where are we going??)

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

> > this supposes that any browser window shares the same cookie.
> > I am using Netscape, and it does, but I heard IE might do not.
>
> IE is even more "pervasive" than Netscape. From experience, IE
> does share cookies. If you have Active Desktop running you have
> to actually logout/reboot to clear out session cookies, so I
> don't think you need to worry about different windows not
> recognising cookies or having old cookie values.

A few months ago we hashed this out on the list and someone whose name I
cannot remember enlightened me about IE's behaviour. (I don't know how the
Active Desktop plays into this.)

IE can share cookies or not depending on the user. On a Windows machine it
is possible to force IE into a separate process and therefore not share
cookies. By launching a new copy of IE - by using the start menu, quick
launch bar, etc - you spawn a new process. Windows, of course, is too stupid
to alert you to this fact and there is no way to know after the fact which
browser windows belong to which processes. If, on the other hand, you use
Ctrl-N to open a new window or if JavaScript opens a new window that window
belongs to the same process. IE on a Macintosh, and every other browser on
every other platform I have ever encountered, always shares cookies.

Because everything happens behind the scenes, I could not reconcile
conflicting reports by users until I was informed how it all works.

Layne Weathers
Ifworld Inc.

[Phplib-users] Sessions where are we going??

[Donncha O C. <don...@tr...>]

I'm afraid I'm not familiar enough with PHP4 sessions to even give a=20
reasonable answer to your first query (how to create new IDs?)

Banging my own drum again.. my cookie idea would be less intrusive than=20
opening a new session and should provide as much protection as having a=20
second session open. That's my thoughts on it anyway, I just want someone=
 to=20
slam the idea down and explain why it's a bad idea so I can start figurin=
g=20
out another fix.. anyone with cvs access read this list anymore?

Donncha.


On Tuesday 02 July 2002 15:23, Giancarlo wrote:
>  Donncha O Caoimh <don...@tr...> a =E9crit le  2/7/=
02=20
9:59:
> >I explained my idea to John
> >here at work and he said
> >much the same thing. In
> >that case we put a timer in
> >there and update the key
> >every X
> >seconds/minutes/hours or
> >something.
>
> It is already damn difficult to have people accept the idea of using a =
new
> session after auth, only once... And BTW, did you discover a way to hav=
e
> PHP4 issue a new id when one already exists? This is the basis for both=
 the
> new changes I'd port to session4: block_alien_sid creation and clone se=
ss
> on authenticated (and I'd add a config to have a cookie_or_noway mode
> 'only' after authentication)
>
> As maybe you know, I don't have 'write access' to cvs anymore, I am
> declaratedly lobbying.
>
> Gian

Rp.: Re: Rp.: Re: [Phplib-users] Sessions where are we going??

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

 Donncha O Caoimh <don...@tr...> a écrit le  2/7/02 9:59:

>I explained my idea to John 
>here at work and he said 
>much the same thing. In 
>that case we put a timer in 
>there and update the key 
>every X 
>seconds/minutes/hours or 
>something.

It is already damn difficult to have people accept the idea of using a new session after auth, only once...
And BTW, did you discover a way to have PHP4 issue a new id when one already exists? This is the basis for both the new changes I'd port to session4: block_alien_sid creation and clone sess on authenticated (and I'd add a config to have a cookie_or_noway mode 'only' after authentication)

As maybe you know, I don't have 'write access' to cvs anymore, I am declaratedly lobbying.

Gian

[Phplib-users] Sessions where are we going??

[Donncha O C. <don...@tr...>]

On Tuesday 02 July 2002 14:52, Giancarlo wrote:
>  Donncha O Caoimh <don...@tr...> a =E9crit le  2/7/=
02=20
9:59:
> >I explained my idea to John
> >here at work and he said

> this supposes that any browser window shares the same cookie.
> I am using Netscape, and it does, but I heard IE might do not.

IE is even more "pervasive" than Netscape. From experience, IE does share=
=20
cookies. If you have Active Desktop running you have to actually=20
logout/reboot to clear out session cookies, so I don't think you need to=20
worry about different windows not recognising cookies or having old cooki=
e=20
values.

>
> >I just did a little experiment.
> >I reloaded a page that uses
>
> people dream predictably stable solution that sulevate them from the du=
ty
> of having to shed any light. That's why they love PHP4 sessions and pre=
fer
> to ignore anything seriously wrong with it.

Right, you want to fix the problems, so do I, and others do too, but if n=
obody=20
else objects, I think the "secret key" cookie solution might be a way to =
fix=20
the propogation problem. I suppose it's best to leave it a few days and g=
et=20
comments from others of course. I'll have a bash at it on our LAN here an=
d=20
mail some code to the list when I have it running.

Donncha.

Rp.: Re: Rp.: Re: [Phplib-users] Sessions where are we going??

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

 Donncha O Caoimh <don...@tr...> a écrit le  2/7/02 9:59:

>I explained my idea to John 
>here at work and he said 
>much the same thing. In 
>that case we put a timer in 
>there and update the key 
>every X 
>seconds/minutes/hours or 
>something.
>

this supposes that any browser window shares the same cookie.
I am using Netscape, and it does, but I heard IE might do not.

>I just did a little experiment. 
>I reloaded a page that uses 
>php4 sessions 
>through phplib and did an ls -l 
>/tmp to see if the session 
>file was updated. 
>The file was, so it doesn't 
>matter how often you 
>update the key, the session 
>file is written out (either 
>that or the file is touched by 
>php4.. can anyone 
>shed any light on that?) 

people dream predictably stable solution that sulevate them from the duty of having to shed any light.
That's why they love PHP4 sessions and prefer to ignore anything seriously wrong with it.

>Next thing is to put those 
>session files on a ram drive :)
>
>I think it's probably an idea 
>worth looking at, does 
>anyone else 
>agree/disagree/care?
>
>Donncha.
>
>
>On Monday 01 July 2002 
>17:48, Giancarlo wrote:
>>  Donncha O Caoimh 
><donncha.ocaoimh@tradesig
>nals.com> a écrit le  1/7/02 
>14:23:
>> >Just a thought for an 
>extra
>> >layer of protection for 
>the
>> >user:
>> >The first time the user 
>visits
>> >the site we set a cookie 
>on
>> >their browser with
>> >some very random 
>number
>> >as the key. Store the 
>value
>> >of the key in the
>> >session.
>> >Each time after that 
>modify
>> >the key, set the cookie, 
>and
>> >store it in the
>> >session.
>>
>> That would be heavy on 
>the server. Imagine a 
>multi-frame where each 
>tries
>> to lock&write in very rapid 
>sequence... Maybe  ok for 
>terminal like
>> screens, tellers, mono 
>thread slow stuff.

Re: Rp.: Re: [Phplib-users] Sessions where are we going??

[Donncha O C. <don...@tr...>]

I explained my idea to John here at work and he said much the same thing.=
 In=20
that case we put a timer in there and update the key every X=20
seconds/minutes/hours or something.

I just did a little experiment. I reloaded a page that uses php4 sessions=
=20
through phplib and did an ls -l /tmp to see if the session file was updat=
ed.=20
The file was, so it doesn't matter how often you update the key, the sess=
ion=20
file is written out (either that or the file is touched by php4.. can any=
one=20
shed any light on that?)=20
Next thing is to put those session files on a ram drive :)

I think it's probably an idea worth looking at, does anyone else=20
agree/disagree/care?

Donncha.


On Monday 01 July 2002 17:48, Giancarlo wrote:
>  Donncha O Caoimh <don...@tr...> a =E9crit le  1/7/=
02=20
14:23:
> >Just a thought for an extra
> >layer of protection for the
> >user:
> >The first time the user visits
> >the site we set a cookie on
> >their browser with
> >some very random number
> >as the key. Store the value
> >of the key in the
> >session.
> >Each time after that modify
> >the key, set the cookie, and
> >store it in the
> >session.
>
> That would be heavy on the server. Imagine a multi-frame where each tri=
es
> to lock&write in very rapid sequence... Maybe  ok for terminal like
> screens, tellers, mono thread slow stuff.

Fwd: Re: [Phplib-users] Using a template as the content of another template.

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

Well, I sent this last night but, CC'd it to Joe instead of to the 
list.  Too many mailing lists with different defaults for reply-to ...

Andrew

>Date: Sun, 30 Jun 2002 14:09:15 -0700
>To: Joe Cotellese <jco...@co...>
>From: Andrew Crawford <An...@Ev...>
>Subject: Re: [Phplib-users] Using a template as the content of another 
>template.
>Cc: Joe Cotellese <jco...@co...>
>
>Joe,
>
>Yes.  I don't know how standard this is but, I have been working with this 
>recently in an attempt to get complete separation of form, content, and 
>function.  It helps if you remember that all of the markers (replace items 
>in {brackets}) and places where blocks have been extracted act like 
>variables.  I don't think it matters whether you extract blocks or load files.
>
>So, if the main page template (the one with the {content} variable/marker) 
>is page_template.ihtml, and the form or other stuff you want to fill 
>{content} with is content_template.ihtml, you would probably want to do 
>something like this:
>
>    // Start the page template
>    $t = new Template;
>
>    // set the file to the content template
>    $t->set_file('some_content', 'content_template.ihtml');
>
>    // fill in the variables for the content template here
>
>    // parse the completed content area into a variable called content
>    $t->parse('content', 'some_content');
>
>    // set the file to the overall page template
>    $t->set_file('thispage', 'page_template.ihtml');
>
>    // content is already filled in, set any other variables
>    // for the page template here
>
>    // parse the finished page into out
>    $t->parse('out', 'thispage');
>
>    // output out
>    $t->p('out');
>
>If this is confusing, you might consider looking at:
>
>    http://www.devshed.com/Server_Side/PHP/PHPLib/page1.html
>
>... and:
>
>    http://www.phpbuilder.com/columns/david20000512.php3
>
>Andrew Crawford
>An...@Ev...
>
>At 10:32 AM 6/30/2002 -0400, you wrote:
>>Hello,
>>
>>I just started using PHPLib about a week ago. I really like the template 
>>feature, it definitely works as advertised. I do however have one 
>>question that was not immediately evident from the documentation or 
>>mailing list archives.
>>
>>Does the PHPLib template system allow one template to be included into 
>>another template? For example, I have defined an overall site template 
>>that creates the general layout of my page. The only variable defined is 
>>{Content}. The idea then is to have Content filled out by information 
>>from a database or some separate file. This works great, but now I want 
>>to add a form to the site. Can I replace {Content} with the contents of 
>>another template that defined the page form or would it be better to 
>>generate the form programmatically from PHP?
>>
>>Thanks in advance,
>>Joe Cotellese

Rp.: Re: [Phplib-users] Sessions where are we going??

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

 
>> Ah.. I see the context of 
>that quote now. I don't think 
>Tarique was arguing 

yeah! I read that too fast.



>BUT 
>definitely cannot
>take the claim of writing the 
>piece in question 

sorry, that was my desperate search for an ally that gave me visions  ;-o

Gian