phplib-users Mailing List for PHPLIB (Page 27)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Maxim Derkachev wrote:

 > user-provided session id. I guess, a boolean marker in the session

I called it $allow_alien_sids  ;-) in the php3 session.inc,
you call it $forgery_check...

Gian

Giancarlo wrote:
G> So the idea to mark the session somehow, to prevent opening starting
G> user-chosen, unexistent id, is good.
G> The ide of the IP i'd let implement to those who want.

So, I suppose the question on IP-bound sessions is closed. We won't
bind a session to IP, because it adds a layer of complexity and does
not do what it was intended for in many cases.
However, we of course can prevent starting a new session with the
user-provided session id. I guess, a boolean marker in the session
would be enough (it reminds me of secure_auto_init and $sess->in
in Session3 ...).

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

On Wed, Dec 04, 2002 at 07:33:44PM +0100, Giancarlo wrote:
> Giancarlo wrote:
> >Excuse me, but if I propose you to click on a link as
> >https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1
>  ^^^^^^^
> Notice that is using SSl.
> 
> So the idea to mark the session somehow, to prevent opening starting 
> user-chosen, unexistent id, is good.
> The ide of the IP i'd let implement to those who want.

Somebody who does not use SSL does not want to be secure. You
could code around that, but you would end up reimplementing SSL
at the user level, which is silly.

Somebody who does not use session cookies, but forces us to use
GET parameters does not want to be secure, either. Again, we can
code around that, but it is useless and bloats our code.

If you want to implement a secure site, offer SSL and cookie
mode. If your users do come in not using SSL, offer them a link
to your SSL site. If your users do come in not using cookies,
offer them a link to a page that explains why this is a bad
thing to do and how they can change that. Also install a proper
P3P policy.

If they choose not to use the help you offer, it is their risk,
they take it against our recommendation and their better
knowledge, and we cannot help them.

We really should not bloat our code for them.

Kristian

> Excuse me, but if I propose you to click on a link as
> https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1
 ^^^^^^^^ yes of course this is still possible... :(

> you click on it, you login, you place it in your bookmarks, can't I
> steal it afterwards, forever and ever, as long as you use that bookmark?
well, in case trans_sid is set to on and you're not restricting your users
to work with cookies, yes.

Sorry, I followed joe's advice to disable session-id transfer via url, so
I wasn't aware of this, looks like.

Marko

Well at the moment, we have it set to not fall back to get mode.  So, you
either accept the cookie or you can't use the shopping cart (or login or do
anything other than look at products).  We figure there aren't going to be
many people turning off cookies, and those who do it are knowlegeable enough
to understand why we're using cookies.

The problem (if it is really a problem, which I am not entirely sure of, but
my boss is concerned about) is with search engines.  Since they don't accept
cookies, they would get session id's everywhere.  Now I can't seem to find a
definitive answer here, but some (all?) search engines supposely will ignore
any page that has session id's (specificaly, any url with a '?' in it).
Now, I have my site working without the '?' and '&', using '/' everywhere
instead.  My boss thinks (I disagree) that the search engines will still
barf on our urls because they will see the big long random looking session
id and even though it looks like a directory will still ignore our pages.

Another possible concern is that phplib redirects when you login.  I noticed
that when trying to use the validator.w3.org service it doesn't work because
of the redirection, it works if I point it at a url that includes a session
id in it.  I dont know if that means a search engine might also refuse to
index the site.  Also if the search engine did work, the indexed urls would
have session_ids and anybody that went through that search engine to get to
us would have the same id... I dont know if that's a problem or not?

Perhaps there really isnt anything to worry about...  :)

----- Original Message -----
From: "Matt Williams" <li...@ye...>
To: "Aric Caley" <gre...@pe...>
Sent: Tuesday, December 03, 2002 1:28 AM
Subject: Re: [Phplib-users] No session_id or cookie if not authenticated..
how?

On Wednesday 04 December 2002 00:11, Aric Caley wrote:

> I guess what I have to do is check my parameters first and then call
> page_open() only when needed, but then like you say the session gets lost
> when a user goes to an unprotected area.  So I'd have to also check if the
> user already has a session and call page_open() if so

That's true but only if the user is using a non cookie session.

IMHO I don't see what the big issue is with accepting cookies.
Yes fair enough in some instances like ad sites and the like, but if I'm on
a
site where I know there is a members area or I'm gonna buy something, I
expect to have a cookie or two dropped on my machine.
And if they wanna track my progress around their site fair enough maybe
they'll offer me a deal on something I do want but never thought they had..

Why is it a problem to start the session when the user first visits?

matt

  Connections are transiant, so there is no way of knowing when the browser
closed.  This is the reason for timeout on auth and session.  They become
invalid after X time.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Matt
> Williams
> Sent: Wednesday, December 04, 2002 2:31 PM
> To: phplib-users list
> Subject: Re: [Phplib-users] store the IP in the session
>
>
> On Wednesday 04 December 2002 18:16, Giancarlo wrote:
>
> > > Why not to finish all these IP discussions then? Let's simply
> trigger the
> > > user to use SSL for safer sessions, which is fairly easy to
> do if you've
> >
> > Excuse me, but if I propose you to click on a link as
> > https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1
> >
> > you click on it, you login, you place it in your bookmarks, can't I
> > steal it afterwards, forever and ever, as long as you use that bookmark?
> >
> > The typical illiterate snooper exploit is just  this.
>
> But that would be user error. If someone was stupid enought to do
> that maybe
> they deserve whatever happens to them
>
> Excuse my ignorance on this but wouldn't a way round it to use
> per session
> er.. sessions. So as soon as the browser closed the session
> ended. Assuming
> of course that all reference to the session was removed from
> wherever it was
> stored on the server.
>
> matt
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

>
> Rob Hutton wrote:
> > This could be easily addressed by maintaining a list of unique,
> > non-incremental ids that are valid for a certain period of
> time, exactly the
> > way IP does it.
>
> You mean a single overall list, server wide, not a per session one?

No, it would be a list per session.  The problem is that if you have frames,
then you will get a different id per frame, and at any time, one of those
frames may resubmit, with whatever the value is at the time, so you have to
maintain a list of acceptable ids so that you don't break frames.  There may
be multiple submissions from different frames with the same unique ID, or
you could have multiple submissions from different frames with different
IDs.  But you don't want them to be available forever, so there has to be an
expirations on them.

>
> > The scheme wouldn't even have to be blocking, and could
> > allow multiple frames to use the same ID as long as it was within the
> > lifetime of the list.
> >
>
> The blocking/non blocking I was thinking about... By non-blocking you
> mean 'shared', or 'that can be used again'?  In reality if you use the
> same validator on multiple links, you block them, because only one can
> be clicked. I don't think you can flag some as 'usable more the once',
> otherwise the security evaporates. Unless when you reuse one of these,
> you mark as 'used' all the still unused ones, and regenerate them again
> in that page. A lot of work.

Blocking means that only one process can have a particular session open at a
time.  So, there is a switch on the session record which is something like
locked, if locked, then you wait X time.  When X has passed, you try again.
You go through that Y times.  Then you fail.

>
>
> > The problem is that this does nothing to tie the session to a certain
> > machine.
>
> But that would be great way forward anyway. Imagine, no more
> cookie burden.

You still have the problem with cookies as you may have a machine where the
same person has multiple sessions open.  There is always going to have to be
a way to tie the session ID to a particular browser session, even if has
been authenticated and cannot be hijacked.

>
>  > The only way to do this is with public key authentication.
>
>
>
>

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

 >> The problem is that this does nothing to tie the session to a certain
 >> machine.

I have a magic word for this. It is 'responsability'.
When you mention this word... PKI really points out the fact that  the
sysadmin really has a responsability, you know? For now is holiday... ;-)

Gian

>>Excuse me, but if I propose you to click on a link as
>>https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1
>>
>>you click on it, you login, you place it in your bookmarks, can't I
>>steal it afterwards, forever and ever, as long as you use that bookmark?
>>
>>The typical illiterate snooper exploit is just  this.
> 
> 
> But that would be user error. If someone was stupid enought to do that maybe 
> they deserve whatever happens to them

Do you check all the links before clicking them?
If all app servers had that, can you imagine the billions of troyan 
bookmarks? The fact that even expired can reborn same same, is of much 
worry, and the check_for_existance by Maxim fixes that so ++

Gian

On Wednesday 04 December 2002 18:16, Giancarlo wrote:

> > Why not to finish all these IP discussions then? Let's simply trigger=
 the
> > user to use SSL for safer sessions, which is fairly easy to do if you=
've
>
> Excuse me, but if I propose you to click on a link as
> https://phplib.sourceforge.net/showoff.php3?PHPSESSID=3D1
>
> you click on it, you login, you place it in your bookmarks, can't I
> steal it afterwards, forever and ever, as long as you use that bookmark=
?
>
> The typical illiterate snooper exploit is just  this.

But that would be user error. If someone was stupid enought to do that ma=
ybe=20
they deserve whatever happens to them

Excuse my ignorance on this but wouldn't a way round it to use per sessio=
n=20
er.. sessions. So as soon as the browser closed the session ended. Assumi=
ng=20
of course that all reference to the session was removed from wherever it =
was=20
stored on the server.

matt

> Hi Kristian, good to see that you are still watching your baby phplib! :)
>
> > increment $sess->seq in page_open() as soon as you instantiated
> wahhh, and this would also cause problems in frame-based sites which have
> pages which do not call page_close() at the end. We once had discussion
> about this. That would require to shift the generation of the new hash in
> page_close instead, being less secure again...

This could be easily addressed by maintaining a list of unique,
non-incremental ids that are valid for a certain period of time, exactly the
way IP does it.  The scheme wouldn't even have to be blocking, and could
allow multiple frames to use the same ID as long as it was within the
lifetime of the list.

The problem is that this does nothing to tie the session to a certain
machine.  The only way to do this is with public key authentication.  Like
SecureID does, and hopefully DNSSec will do also in the future.  Or, if it
is a higher security environment now, so like Kristian says and get a key
from a PKI authority.  I am talking about easy to use and cheap stuff that
does not require the user to do anything.

>
> I'd also support SSL instead, that would make much easier phplib-wise. All
> these concerns about securing the session would be handed over to the SSL
> part. But on the other hand one knows that into SSL one could break in as
> well... There was another thread about this some weeks ago. But probably
> one could never make phplib sessioning as secure as SSL is right from the
> start... I guess.

Without some sort of universal PKI scheme, you are correct.  There is just
no reliable way to tie to a specific person/machine.

>
> Why not to finish all these IP discussions then? Let's simply trigger the
> user to use SSL for safer sessions, which is fairly easy to do if you've
> got your own secure apache running.
>
> These auth things seem to be quite settled already. Shouldn't we focus
> more now on a new phplib4 cvs release which could be based on the snapshot
> on sf and deploy that in a user-friendly manner?
>
> Marko
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

Giancarlo wrote:

> Excuse me, but if I propose you to click on a link as
> https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1
  ^^^^^^^

Notice that is using SSl.

So the idea to mark the session somehow, to prevent opening starting 
user-chosen, unexistent id, is good.
The ide of the IP i'd let implement to those who want.

Now, even if we accept only id created by us, one can have php(4/lib) 
create it, and offer that in the URL. It will work only once though, 
which is better yet.

BUT, if when we crete the session, we remember the 'mode' at that moment 
(get/cookie), then this will be possible only when both A and B have 
cookies disabled. Which restricts further and further, because the 
traansmission, in that standard illiterate exploit, must pass through 
GET in any case.

I know the solution is sheating the hull. I question how much this is a 
valid reason  for not  plugging the holes anyway.

G

> Why not to finish all these IP discussions then? Let's simply trigger the
> user to use SSL for safer sessions, which is fairly easy to do if you've

Excuse me, but if I propose you to click on a link as
https://phplib.sourceforge.net/showoff.php3?PHPSESSID=1

you click on it, you login, you place it in your bookmarks, can't I 
steal it afterwards, forever and ever, as long as you use that bookmark?

The typical illiterate snooper exploit is just  this.

Gian

Hi Kristian, good to see that you are still watching your baby phplib! :)

> increment $sess->seq in page_open() as soon as you instantiated
wahhh, and this would also cause problems in frame-based sites which have
pages which do not call page_close() at the end. We once had discussion
about this. That would require to shift the generation of the new hash in
page_close instead, being less secure again...

I'd also support SSL instead, that would make much easier phplib-wise. All
these concerns about securing the session would be handed over to the SSL
part. But on the other hand one knows that into SSL one could break in as
well... There was another thread about this some weeks ago. But probably
one could never make phplib sessioning as secure as SSL is right from the
start... I guess.

Why not to finish all these IP discussions then? Let's simply trigger the
user to use SSL for safer sessions, which is fairly easy to do if you've
got your own secure apache running.

These auth things seem to be quite settled already. Shouldn't we focus
more now on a new phplib4 cvs release which could be based on the snapshot
on sf and deploy that in a user-friendly manner?

Marko

On Wed, Dec 04, 2002 at 04:09:15PM +0100, Giancarlo wrote:
> No cookie, only GET, and no possibility to guess or steal the second 
> half. A lot of CPU on 'refilling' the array once exhausted, though.

You do not need different hashes on different URLs, or at least
I cannot see why you should. Instead the session can have an
internal sequence number, which is appended to the SID in a
hashed form. So you do 

	$validator = md5($sess->id . $sess->seq . $sess->magic);

and append "{$sess->id}-$validator" to each sid in a URL. Also, you
increment $sess->seq in page_open() as soon as you instantiated
$sess.

Using the saved $sess->seq from the session, you can validate
the session id by precalculating the validator and compare it to
the validator you received.

This will protect the session against replay attacks, and will
also prevent insertion of requests from an attacker into a
sequence of requests from a legitimate user, because the
attacker cannot predict the validator without knowledge of the
proper $sess->seq AND knowledge of the $sess->magic.

It will also make sessions very fragile, no more back buttons at
all. I do not recommend this for any production environments.

Use SSL instead. Saves you the pain of the implementation,
protects against more attacks and is easier to deploy.

Kristian

Rob Hutton wrote:
> Actually it is not implemented in most circumstances and does not address
> NAT at all, which is a major issue.

True. It just can cover a bit more cases that the REMOTE_ADDR

Anyway, seen that Kristian is around, I wanted to elaboarte that 
One_time_password idea.

This is a URL only system.
The url is something like
?PHPSESSID=11111-aaaaa

where '11111' is our traditional md5 32 byte cookie, that stays 
constant, while 'aaaaa' is another 32 byte part, that always changes.

How is the 'aaaa' part taken?

On session startup, a fair number of 32 byte random hashes is generated, 
and saved in the session.
The url-rewriting function ($sess->url() ?) appends to each hyperlink 
one different hash, taken from the session array whith these 
pregenerated ones, and flags it as 'shown'.
Upon requesting one of these links, the session fuunction checks that 
the 'aaaa' part is among the ones flagged as shown. If it is, it flags 
it as 'used', otherwise no way.

No cookie, only GET, and no possibility to guess or steal the second 
half. A lot of CPU on 'refilling' the array once exhausted, though.

How does it sound?

Gian

Actually it is not implemented in most circumstances and does not address
NAT at all, which is a major issue.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Wednesday, December 04, 2002 3:01 AM
> To: phplib-users
> Subject: [Phplib-users] store the IP in the session
>
>
> I've read on php-dev that Oghaki had added, by himself, a test on a
> particular Header line (X-something) in the http request,that, in case
> the client is behind a proxy, would hold the IP of the original
> requester. That is not 100% sure to be there, but it can still cover a
> good part of those requests and is better that nothing.
>
>
> Gian
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

On Mon, Dec 02, 2002 at 08:12:50PM +0300, Maxim Derkachev wrote:
> Well, I'm just this kind of sysadmin, and I'm fed up of
> persuading users to turn their cookies on, because many of
> them don't read that cookies must work on our site, others
> don't know what the cookies are and don't know how to turn it
> on back. And sometimes browsers f@#k up and don't handle
> cookies properly (e.g. Opera6.01 and IE6 in some
> installations).

MSIE 6 works fine, if you define and install a P3P policy.
Define one that states that you will use only transient
(session) cookies, and that you will use these cookies only for
shopping cart purposes, and all default MSIE 6 installations
will allow your cookies (also, all but the most stupidly
restricted MSIE 6 installations will allow them).

Kristian

-- 
http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG

On Mon, Dec 02, 2002 at 10:04:15AM -0500, Rob Hutton wrote:
> > 1. The check for session existence is trivial. In my addition to the
> > Session4 the session exists if the originator's IP is registered with
> > the session. If we have a SID in the request and don't have *any* IP in
> > the session, the session does not exist, so the SID should be
> > omitted and the new session with the new random SID should be emitted.
> 
> I'm not following.  If the session doesn't have an IP then it's not valid?
> What if the IP doesn't match? Is it invalid also?  This simply will not
> work.

Using this post to plug into this discussion.

Amending your reasoning:

Sessions must not work with IP numbers at all. Anything within a
session that uses IP numbers for other purposes than loggin is
broken and will never work correctly in general. There are very
limited usage scenarios where this may be different, but they
have to be justified in each and every case for correctness.

This topic has been coming up repeatedly on the old PHPLIB
mailing list and discussed to death. The summary:

1. Multiple users with different sessions may come from the
   same IP number.

This is always the case when these users work on a multi user
machine. It is also the case when multiple users are using the
same proxy server.

2. A single user may have an ongoing session, but subsequent
   requests from this session come from different IP numbers.

This is always the case when the proxy the user is on is in fact
a load balancing cluster. It is also the case when the user is
on a dialup, disconnects and reconnects due to an idle timeout.

Both cases are observed simultaneously for all users on German
T-Online (~6*1E6 users using a proxy cluster with some dozen IP
numbers) and all AOL users. These users are always using a
proxy, and that proxy is load balanced, establishing a true n:m
cloud between sessions and IP numbers.

This makes anything that uses IP numbers useless, even without
taking spoofing or other attack modes into account.

> > 3. We should do something so that session hijacks could be made
> > [almost] impossible.

Yes, there is one single way to do this. 
Use SSL.
Everything else is just pixie dust.

> I vote that the documentation cover the security aspect, and
> leave it at that until there is a widely deployed public key
> system that can be leveraged instead of trying to invent
> something that provides an artificial sense of security and
> will cause problems.

Correct strategy.

Also, using SSL will fix many of these problems today, using SSL
with client side certificates does fix all of these problems
today. The PKI is in place, you just have to distribute the
certificates.

Kristian

-- 
http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG

I've read on php-dev that Oghaki had added, by himself, a test on a 
particular Header line (X-something) in the http request,that, in case 
the client is behind a proxy, would hold the IP of the original 
requester. That is not 100% sure to be there, but it can still cover a 
good part of those requests and is better that nothing.

Gian

And to do that, I'd have to check the URL for a session_id (should be the
name of the class, right?) and check for the cookie.

also, I guess everywhere that I am using $sess->url() and $perm->have_perm()
I have to check if those objects exist?  Or maybe I make some "dummy
objects" that look like the real ones but dont do anything?

----- Original Message -----
From: "Richard Archer" <rh...@ju...>
To: <php...@li...>
Sent: Tuesday, December 03, 2002 4:39 PM
Subject: Re: [Phplib-users] No session_id or cookie if not authenticated..
how?

> At 16:11 -0800 3/12/02, Aric Caley wrote:
>
> >So I'd have to also check if the
> >user already has a session and call page_open() if so.
>
> Yup. That would do the job nicely :)
>
>  ...R.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

At 16:11 -0800 3/12/02, Aric Caley wrote:

>So I'd have to also check if the
>user already has a session and call page_open() if so.

Yup. That would do the job nicely :)

 ...R.

And its a shopping cart I work on.

All pages are accessed through one php script, index.php.  What page is
actualy shown to the user depends on what is passed to the script (IE,
"index.php?page=cellphones/nokia").

What I want to do is just like having the default auth to 'nobody', but I
dont want any cookies sent or session_id's in urls until the user  logs in,
or actualy also until a user does something like add an item to the cart.

I guess what I have to do is check my parameters first and then call
page_open() only when needed, but then like you say the session gets lost
when a user goes to an unprotected area.  So I'd have to also check if the
user already has a session and call page_open() if so.

This is oh-so-confusing.

----- Original Message -----
From: "Richard Archer" <rh...@ju...>
To: <php...@li...>
Sent: Tuesday, December 03, 2002 3:47 PM
Subject: Re: [Phplib-users] No session_id or cookie if not authenticated..
how?

> At 17:47 -0500 3/12/02, li...@ye... wrote:
>
> >Easiest way would be to only use page_open on pages you want to protect.
> >
> >The session would only be created first time someone hit one of these
pages and
> >auth timeouts could occur more often but it could work depending on your
> >application.
>
> And if a non-cookie user leaves the protected part of the site (e.g.
> they click on the Home button) they will lose their session. That
> would be a disaster in a shopping cart environment, but may not
> matter in other instances.
>
>  ...R.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

At 17:47 -0500 3/12/02, li...@ye... wrote:

>Easiest way would be to only use page_open on pages you want to protect.
>
>The session would only be created first time someone hit one of these pages and
>auth timeouts could occur more often but it could work depending on your
>application.

And if a non-cookie user leaves the protected part of the site (e.g.
they click on the Home button) they will lose their session. That
would be a disaster in a shopping cart environment, but may not
matter in other instances.

 ...R.

Quoting Aric Caley <gre...@pe...>:

> OK this may be simple but its eluding me:
> 
> I have a single entry page for my application.
> 
> I want parts of it protected, depending on what parameters are passed to
> it.
> 
> The unprotected parts I want accessible and not have a cookie set or a
> session id put into all the urls.  IE, having the default auth to 'nobody'
> isnt what I want.
> 
> How can I get it to *only* make a cookie/add session id's when somebody has
> actualy really logged in?
> 

Easiest way would be to only use page_open on pages you want to protect.

The session would only be created first time someone hit one of these pages and
auth timeouts could occur more often but it could work depending on your
application.

matt

-

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (106)	Sep (99)	Oct (44)	Nov (97)	Dec (60)
2002	Jan (56)	Feb (81)	Mar (134)	Apr (69)	May (106)	Jun (122)	Jul (98)	Aug (52)	Sep (184)	Oct (219)	Nov (102)	Dec (106)
2003	Jan (88)	Feb (37)	Mar (46)	Apr (51)	May (30)	Jun (17)	Jul (45)	Aug (19)	Sep (5)	Oct (4)	Nov (12)	Dec (7)
2004	Jan (11)	Feb (7)	Mar	Apr (15)	May (17)	Jun (13)	Jul (5)	Aug	Sep (8)	Oct (6)	Nov (21)	Dec (13)
2005	Jan (4)	Feb (3)	Mar (7)	Apr (7)	May	Jun (11)	Jul (7)	Aug	Sep	Oct	Nov (7)	Dec
2006	Jan (3)	Feb	Mar (1)	Apr	May	Jun (2)	Jul (1)	Aug	Sep	Oct (9)	Nov	Dec (5)
2007	Jan (15)	Feb (2)	Mar	Apr	May	Jun	Jul (9)	Aug	Sep (2)	Oct	Nov	Dec
2008	Jan	Feb	Mar	Apr (12)	May	Jun (3)	Jul (1)	Aug (19)	Sep (2)	Oct	Nov	Dec (6)
2009	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (6)

phplib-users Mailing List for PHPLIB (Page 27)

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