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

Re[2]: [Phplib-users] Maxim Derkachev's session class and register_globals = OFF

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

Hello Marko,

Monday, June 03, 2002, 6:39:39 PM, you wrote:
MK> Do you still use your own contribution to phplib? Will you do these
MK> changes menioned above yourself in post them some time in the future, or
MK> did you change to other fields?

Yes, I use the class in production. The changes above could be easily
applied, but they'll break functionality under PHP pre-4.1 ($_SESSION
and direct assignment to register session vars was introduced in 4.1).
I suppose, Session4 should be subclassed to change its behavior
reflecting PHP version information, overriding register() and friends.

MK> I ask because I don't want to invent the wheel a second time. In case
MK> you're still supporting the functionality, I better wait until you have
MK> time for such a modification. But in case you stopped activities... Well,
MK> then I'm afraid I'd have to dive into your code in detail. ;)

Unfortunately, I have not much time now to apply and properly test the
changes, so I don't promise the changes to be fast. But you can try,
and if you succeed, we'll patch the class in CVS.

MK> Another point: Did you ever compare the performance of web pages coded in
MK> standard php4 sessions with your session4_custom?
I suppose, the custom storage would be a bit slower (it depends on the
DB speed at most).



-- 
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] achive link

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

If I'm trying the same link you are, it works for me OK.  Can you give us
the URL you are trying?  Thanks.

..chris

----- Original Message -----
From: <pet...@ph...>
To: <php...@li...>
Sent: Monday, June 03, 2002 9:45 AM
Subject: [Phplib-users] achive link


I am wondering why I cannot go through the Phplib-users Archive link on the
Phplib-users info page.
Anybody has idea?

cheers,

Hu, Yayin (Peter)
============================================================
Web Developer
der Philips Semiconductors GmbH
Stresemannallee 101
D-22529 Hamburg, Germany
Tel: +49-40-5613-1659                Fax: +49-40-5613-1766
e-mail: pet...@ph...

[Phplib-users] php 4.2.1

[Marko K. <Mar...@mc...>]

Hi,

I just installed php from 4.0.6 to 4.2.1, but unfortunately my project
isn't working anymore as before.

There is one example appended. A function ExtractExpLinks breaks. PHP just
stops interpreting the inc-file where this snipout was located in.

Another problem was that one of my php scripts isn't executed at all. I
don't know what's going on. Did anybody hear about caching problems or
something like that?

Marko

---snip---

        function ExtractExpLinks( $s= "" )
        {
                global $ExpNames,$ExpNr;
                $ret=TRUE;
                $i=0;

                unset($ExpNames[],$ExpNr[]);

                echo '<P CLASS=dbg>';

                while($ret)
                {
                        $ret=ereg("E:{([^}]+)}{([^}]+)}",$s,$arg);
                        if ($ret)
                        {
                                $ExpNr[$i]=$arg[1];
                                $ExpNames[$i++]=$arg[2];
                                $s=str_replace($arg[0],'',$s);
                        }
                }

                return $i;
        }

[Phplib-users] template manual

[Serghej P. <sp...@ti...>]

Hello,
i'm looking for some how-to or examples about template implementation.
Can anybody help me please.
Thanks all

Serghej

[Phplib-users] achive link

[<pet...@ph...>]

I am wondering why I cannot go through the Phplib-users Archive link on the Phplib-users info page.
Anybody has idea?

cheers,

Hu, Yayin (Peter)
============================================================
Web Developer
der Philips Semiconductors GmbH
Stresemannallee 101
D-22529 Hamburg, Germany
Tel: +49-40-5613-1659                Fax: +49-40-5613-1766
e-mail: pet...@ph...

Re: [Phplib-users] Maxim Derkachev's session class and register_globals = OFF

[Marko K. <Mar...@mc...>]

Hello Maxim,

> register(), unregister() and is_registered() should be changed to
> interact directly with $_SESSION instead of using session_register(),
> etc., since those php native session functions don't work with
> register_globals = off.
I see. Thanks for the hint!

Do you still use your own contribution to phplib? Will you do these
changes menioned above yourself in post them some time in the future, or
did you change to other fields?

I ask because I don't want to invent the wheel a second time. In case
you're still supporting the functionality, I better wait until you have
time for such a modification. But in case you stopped activities... Well,
then I'm afraid I'd have to dive into your code in detail. ;)

Another point: Did you ever compare the performance of web pages coded in
standard php4 sessions with your session4_custom?

Well, thanks for your response, Maxim.

Vse horoshego, poka,
Marko

Re: [Phplib-users] Maxim Derkachev's session class and register_globals = OFF

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

Hello Marko,

Monday, June 03, 2002, 5:26:01 PM, you wrote:
MK> does anybody know whether Maxim Derkachev's modification to the session
MK> handling can be modified so that it works also with register_globals =
MK> OFF?

register(), unregister() and is_registered() should be changed to
interact directly with $_SESSION instead of using session_register(),
etc., since those php native session functions don't work with
register_globals = off.



-- 
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] Maxim Derkachev's session class and register_globals = OFF

[Marko K. <Mar...@mc...>]

Hi,

does anybody know whether Maxim Derkachev's modification to the session
handling can be modified so that it works also with register_globals =
OFF?

I'm relying on his modifications already since he uploaded his changes to
the old session managment more than a year ago, maybe even one and a half.
Since I never got troubles with it and it allows me to hold data within
mysql databases and not somewhere in /tmp/* files created by PHP, I'd like
to prefer going on using this modifications.

Any help?

Marko

Re: [Phplib-users] clean the url from session

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

$HTTP_SERVER_VARS["QUERY_STRING"] = ereg_replace(
# "(^|&)".quotemeta(urlencode($this->name))."=".$id."(&|$)",
  "(^|&)".quotemeta(urlencode($this->name))."=(.)*(&|$)", 
## subst *any* preexistent sess
            "\\1", $HTTP_SERVER_VARS["QUERY_STRING"]);

The previous seems to work. I can hardly find examples on grep.

Giancarlo

Sascha Weise wrote:
> 
> At 04:57 01.06.2002 +0200, you wrote:
> >I am not keen with grep. I need a slightly different version of the
> >existing: if e.g. your session is 'Example_Session=', but I don't know
> >its value, I want to clean it whatever it is until the next name=value
> >pair in the URL.
> 
> Perhaps this may help you:
> 
> //$filters must be an Array
> function filter_parameters($url, $filters){
>    foreach ($filters as $filter) {
>      $url =  preg_replace('#\?' .
>                             $filter .
>                            "=.{32}$|&" .
>                            $filter .
>                            "=.{32}$|" .
>                            $filter .
>                            '=.{32}&#msiU',
>                            '',
>                            $url
>                           );
>    }
>    return $url;
> }
> 
> In the result all name-value-pairs with the names specified in the array
> $filters are removed.
> 
> Copyright-Note: I've taken this alghorithm from phpOpenTracker by Sebastian
> Bergmann. Thanks by the way!
> 
> Sascha.
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] block fake user-provoded session

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

I've tried it, but things should be changed since that, because now it
works only in cookie mode.

I base myself on 4 tests, 2 with cookie enabled and two without. I use
Netscape and while enabling/disabling cookies, I keep 'warn me when a
cookie is issued', so I can see them.
Between each test, I close the browser and have a script that erases all
cookies.

For the 4 tests I use the latest php-lib-stable from the cvs, opening
the 'simple page' provided in the distribution. In both modes (cookies
enabled and disabled) I try the bare URL (index.php3) and one with a
fake session appended. Every new test with the fake session is done
modifying its value, eg adding a letter or a number, so that the session
is not eventually found, as it should be if provided by the user.
In The index.php3 I echo the session sid as a check.

the test and the expected results are
1) clean cookies. Start browser. Open index.php3, cookies enabled. This
should work pretty straight anyway, URL with session the very first
time, counter increases. I should see a single warn for a cookie left.

2) clean cookies. restart browser, index.php3?Example_Session=byebye: 
-I should see a cookie left on the browser (get has not to be forced by
user) 
-its value must NOT be 'byebye', (sid has not to be forced by user)
-the page is redirected to itself with the correct session in the UrL
too (the 302 cookie test needs that)
-the counter increases

3)Restart browser, disable cookies. Open index.php3
-I should be redirected to index.php3 with a new  session written in the
URL. Further reload increase counter

4)Cookies disabled. Open index.php3?Example_Session=byebye22
-I should be redirected to index.php3 with a correct session in the URL
(sid has not to be forced by user). Further reloads increase counter.

Now that test on the existence of a sid does not work in get mode for
various reason. First because when the id is found in the url, even if
it does not exists, you are never redirected to the newly generated url.
By the code now, that situation occurs only if there no Session in the
url.

Before the 302 redirect, there is no freeze, so you'll never find a
newly created session that has been redirected to itself with it in the
URL. 
The trick is to $this->freeze before the 302.
And not to be mislead by the presence of a session in the URL, leave a
cookie in any case, get too. And a few other changes that I applied.

Anyone interested can see the patch at the phplib project on
sourceforge.
http://sourceforge.net/tracker/index.php?func=detail&aid=563700&group_id=31885&atid=403613
The patched session.inc has an added session variable
var block_bogus_sid = true;
This commands all the behavior. 
At the moment it passes all 4 tests on true (blocking ON).
On false (no blocking applied) test no 2 gets the fake cookie release
twice. I'll check that.
There's some overhead, a read at every page to see if session exists.
My previous patch didn't have this, because it was based on the idea of
'signin' every 'original' session with a fingerprint, so that post-and
create session would not have it. But I prefer this, is more clean.

Also I've seen that the situate between the release_token and get_id
functions is getting quite complicate.  get_id was first supposed to be
invoked after release_token, but now release token invokes get_id too. 

Peter Kursawe wrote:
> 
> Hallo Gian,
> 
> > Can we control that a new session id has been effectively issued by us,
> > and only create new session id that we have generated?
> 
> I included in my session.inc ( as of $Id: session.inc,v 1.7 2001/07/09 15:33:29) the following code
> in function get_id after the first if ( "" == $id ) { ... }:
> 
> ---- snip ----
> 
>     if($id != "") {   # somehow an id was provided by the user
>        if($this->that->ac_get_value($id, $this->name) == "") {
>           # no - the id doesn't exist in the database: Ignore it!
>           $id = "";
>        }
>     }
> 
> ---- snip ----
> 
> in the next if ( "" == $id ) the programm then generates a new id.
> 
> Disclaimer: I am not sure if this behaviour is safe and I do not know if subsequent versions of phplib
> have taken care of this problem.
> 
> Peter Kursawe
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] clean the url from session

[Sascha W. <sas...@gm...>]

At 04:57 01.06.2002 +0200, you wrote:
>I am not keen with grep. I need a slightly different version of the
>existing: if e.g. your session is 'Example_Session=', but I don't know
>its value, I want to clean it whatever it is until the next name=value
>pair in the URL.

Perhaps this may help you:

//$filters must be an Array
function filter_parameters($url, $filters){
   foreach ($filters as $filter) {
     $url =  preg_replace('#\?' .
                            $filter .
                           "=.{32}$|&" .
                           $filter .
                           "=.{32}$|" .
                           $filter .
                           '=.{32}&#msiU',
                           '',
                           $url
                          );
   }
   return $url;
}

In the result all name-value-pairs with the names specified in the array 
$filters are removed.

Copyright-Note: I've taken this alghorithm from phpOpenTracker by Sebastian 
Bergmann. Thanks by the way!


Sascha.

Re: [Phplib-users] new session creation policy is trust user input ?

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

Hallo Gian,

> Can we control that a new session id has been effectively issued by us,
> and only create new session id that we have generated?

I included in my session.inc ( as of $Id: session.inc,v 1.7 2001/07/09 15:33:29) the following code 
in function get_id after the first if ( "" == $id ) { ... }:

---- snip ----

    if($id != "") {   # somehow an id was provided by the user
       if($this->that->ac_get_value($id, $this->name) == "") {
          # no - the id doesn't exist in the database: Ignore it!
          $id = "";
       }
    }

---- snip ----

in the next if ( "" == $id ) the programm then generates a new id.

Disclaimer: I am not sure if this behaviour is safe and I do not know if subsequent versions of phplib 
have taken care of this problem.

Peter Kursawe

[Phplib-users] clean the url from session

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

I am not keen with grep. I need a slightly different version of the
existing: if e.g. your session is 'Example_Session=', but I don't know
its value, I want to clean it whatever it is until the next name=value
pair in the URL. 

Gian

[Phplib-users] new session creation policy is trust user input ?

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

What are the benefits of trusting any id provided by the user, when
creating a new session? Why should we allow users to create their own
session id, and maybe pass them around? Or being driven to some session
created/faked/hijackable by someone else?

Can we control that a new session id has been effectively issued by us,
and only create new session id that we have generated?

Gian

[Phplib-users] Block auto-session

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

Hi,
I've written a patch that will block anyone that tries to post a bogus
session.

I came to this choice through the following path:

I hated the 'form' state in auth, that precluded the way to show a form
anywhere and had the uncomfortable cacel_login button
But I recognized that having this attribute of auth[uid] set to 'form'
would guarantee that anyone had already got  a session at least. You
could not just post the login form. If the auth state (saved in session)
was not 'form' that data would be ignored.
But Then I thought that if you had a valid session, that meant the same:
block direct posting of registration or login, by a script let's say.

A valid session... And here I found the disgrace that it is extremely
easy to obtain the session you like, even if cookies are on: just put it
in the url (?Example_Session=bogus), and you can find it back, pass it
over to someone else, and in the end steal a lot easier.
Actually this is also the way PHP4 session work: if you have
PHPSESSID=anything in the URL, it forces 'get' propagation and that
session name!!!
So I made this patch. It blocks the bogus session i URL, it prevents
from forcing 'get' mode even if you have cookies enabled.
I don't know hot to do the parallel for the native PHP4 session...

I'd be happy if anyone tried it and give me a feedback.
It can be varnished here and there.with an 'Invalid Session' page.
This is a prototype, I tried it with Netscape under Linux.

The patch
https://sourceforge.net/tracker/index.php?func=detail&aid=562924&group_id=31885&atid=403613

Giancarlo Pinerolo

Re: [Phplib-users] SQL query on more than one page

[Marco P. <pr...@te...>]

On Fri, May 31, 2002 at 03:38:02PM +0200, anze wrote:
> Hi!
> 
> > SELECT .... LIMIT FIRST_ROW_NUMBER, NUMBER_OF_ROWS
> As far as I know this only works on MySQL...

On PostgreSQL it works, but with parameters swapped w.r.t.
the above example.

Marco Pratesi

Re: [Phplib-users] user-variables and SQL select ?

[anze <an...@vo...>]

Hi!

> 	$db->query("SELECT * FROM some_table WHERE setting = '$setting'");
>
> The user class handles registered variables just like the session class
> does - the only difference is that the user variables are maintained across
> multiple authenticated sessions.

I don't think that was the question - the way I understand it some admin has 
to find out which users have some value in their user registered variables. I 
might be wrong, but here is my 5 cents:

Since the user registered variables are stored in database as PHP code, there 
is no easy way to get them from DB. You can decode this PHP code, but you are 
better off if you just save the values to some other DB table instead of 
registering them (you can do both though, just take care that they are in 
sync). 

Have fun!

Anze

Re: [Phplib-users] SQL query on more than one page

[anze <an...@vo...>]

Hi!

> SELECT .... LIMIT FIRST_ROW_NUMBER, NUMBER_OF_ROWS
As far as I know this only works on MySQL...

Anze

RE: [Phplib-users] user-variables and SQL select ?

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

> Hello, I use user-variables to store the users setting. Now I need to
> select that users that have something enabled. If I'd used
> pure sql to
> store the settings, I could simply run a "select * .. where
> setting='y'". But how can I do it with user-variables, which are not
> readable to the sql server?
>
> PS: user value is something like this [stored in session table]:
> "RHJIb3Jha19Vc2VyOiR0aGlzLT5pbiA9ICcwJzsgJHRoaXMtPn..."


Since you are registering variables with the user class, they are recreated
on each subsequent page. So if you did this:

	$setting = "something";
	$user->register("setting");

then on subsequent pages you simply do this:

	$db->query("SELECT * FROM some_table WHERE setting = '$setting'");

The user class handles registered variables just like the session class
does - the only difference is that the user variables are maintained across
multiple authenticated sessions.


Layne Weathers
Ifworld Inc.

[Phplib-users] [phplib] - turning off registration

[Rex B. <re...@te...>]

Hi everyone,

	I haven't been on the list in a long time.  I have basically two questions.

How can I turn off the registration completely.  If I remove the
auth_doregister from the local.inc, will that open other holes?

Second question, is there away to set time constraints on logins.  I want
certain employees to not be able to log in after work hours?

Thanks

Re: [Phplib-users] session stealing and fallback_mode=get

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

Hello Giancarlo,

Thursday, May 30, 2002, 2:28:41 PM, you wrote:
GP> I tried the builtin session functions of Php 4, and it's the same
GP> behaviour.
GP> You can force a particular session via get even if cookies are enabled.

Yes, but it's only a compatibility workaround. Session4 has functional
url() and friends. But with PHP4 and trans-sid it is done
automatically by PHP itself, so this propagation is made when cookies
are disabled.

GP> Is the php.ini enable_trans_id that disables this alternative
GP> propagation?

if $trans_id_enabled is set to true, url(), purl(), etc. don't add
anything to url regardless of the real  enable_trans_id setting.


-- 
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] session stealing and fallback_mode=get

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

Uhh. 
I tried the builtin session functions of Php 4, and it's the same
behaviour.
You can force a particular session via get even if cookies are enabled.

Is the php.ini enable_trans_id that disables this alternative
propagation?

The fact that you can place something on a server, in a known position
(eg /tmp/sess_ciao), is really nasty thing.

Giancarlo

[Phplib-users] Re: [Phplib-core] session stealing and fallback_mode=get

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

Giancarlo Pinerolo wrote:

> The best solution is to leave a cooke *anyway* on the 302 step.
> If they are disabled they won't hurt.

This can solve also some IE problem, I recall. The <meta
http-equiv=Refresh solution can be avoided somehow.

> 
> Giancarlo
>

[Phplib-users] Re: [Phplib-core] session stealing and fallback_mode=get

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

Richard Archer wrote:

> Aah, but cookies are not always available, and it is IMHO extremely
> unwise to lock a class of user out of a site just because they have
> cookies disabled. And especially unwise to lock out the most tech-savvy
> users.
> 

When they are enabled, they must be chosen as the mode.

> Perhaps PHPLIB should allocate a new session ID and invalidate the old
> one under certain circumstances:
> 
> * session ID was passed by get
> 
> * referer is not within our domain (yes, I know referer headers
>   are not to be trusted or relied upon)
> 
> * an unknown session ID is received by any method
> 
> If this was done, for sites in get mode or users in fallback mode, the
> session ID would change for each page. This would render the back
> button and bookmarks useless.
> 
> Also, if mode=cookie, the site would try to set a new cookie for each
> page view where the session ID was received by get.

Really I haven't seen that. I think I've tried hard. 
If you offer a session in the query string, it's get all over, even if
cookies are enabled.
The best solution is to leave a cooke *anyway* on the 302 step. 
If they are disabled they won't hurt.

Giancarlo



> 
>  ...Richard.
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phplib-core mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-core

[Phplib-users] Re: [Phplib-core] session stealing and fallback_mode=get

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

At 6:09 PM +0200 29/5/02, Giancarlo Pinerolo wrote:

>I think that if 'cookie' is set and cookies are on, it should definitely
>use them. While it seems to be driven into the fallback mode when the
>session is present in the URL.

Aah, but cookies are not always available, and it is IMHO extremely
unwise to lock a class of user out of a site just because they have
cookies disabled. And especially unwise to lock out the most tech-savvy
users.

Perhaps PHPLIB should allocate a new session ID and invalidate the old
one under certain circumstances:

* session ID was passed by get

* referer is not within our domain (yes, I know referer headers
  are not to be trusted or relied upon)

* an unknown session ID is received by any method


If this was done, for sites in get mode or users in fallback mode, the
session ID would change for each page. This would render the back
button and bookmarks useless.

Also, if mode=cookie, the site would try to set a new cookie for each
page view where the session ID was received by get.

 ...Richard.