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

[Phplib-users] Why is phplib initiating session ID for 'nobody' when I do a page_open call

[Robert V. O. <van...@un...>]

Hello,

My manager has decided to use phplib (in place of htaccess) to authenticate
users logging into our 'Members Only' secure web site. We have added 3 types
of permissions to the variable array in the 'Default_Auth' class. They are:
'store', 'new_store' and 'non_store'. We have developed a series of logic
loops for the user permissions to jump through, but we find that our issue
occurs even when we do just a basic check for 'store' perm.

For example:
<?
	page_open(array("sess" => "UDSession", "auth" => "UDDefault_Auth", "perm"
=> "UDPerm"));
	$perm->check("store");
?>

When I link to my 'Memberstore' test page, there should not be as active
session, so phplib should display the loginform. However, a session is being
initiated for the user 'nobody', the check for 'store' perm fails, I get a
session ID in the URL (ie:
http://www.uniteddrugs.com/Memberstore.html?UDSession=db0b34882ba2ebd01b8464
9992c11439), and the 'perminvalid' page displays with the following content:
---------------------------------------------------
Permission denied
Your session 0dc0fa1185109a59ec8bb72d4a9585ab has been authenticated with a
user id of nobody and a user name of (unknown).
To access this page, the following permissions are required: store.
---------------------------------------------------

I have the 'logout.php' page available and if I open it, the session is
dropped and I can go and link to my test page, get a loginform and login
normally.

My question is: Why is phplib initiating session ID for 'nobody' when I do a
page_open call?

[Phplib-users] Re: Phplib-users digest, Vol 1 #238 - 4 msgs

[Gerard H. <hi...@ma...>]

> 
> Message: 1
> Date: Wed, 10 Jul 2002 12:38:19 +0800
> From: q <qua...@sn...>
> To: php...@so...
> Subject: [Phplib-users] templates with templates
> 
> 
> I have a file viewTemplate.php
> that uses template1.templ.
> 
> Can I tell template1.templ to use another template (say, template1-a.templ)?
> 
> Is this possible with phplib? templates with templates? (cascading)
> 
> Thank you very much
> 

Yes you can. If you read through the code long enough, you will find
that the template files are read into and stored within the template
object. The following are some snippets from some code I wrote to do
what you are looking for. 

# initialize the template object
$template = new Template ($Config->TemplateDir, $Config->UnknownTags);
$template->halt_on_error = 'report';
$template->set_file (array ('homepage'     => 'homepage.html', 
		            'listing'      => 'listing.html',
		            'detail'       => 'detail.html',
		            'register'     => 'register.html',
		            'recoverpw'    => 'recoverpassword.html',
		            'changepw'     => 'changepassword.html',
		            'memberdata'   => 'memberdata.html',
		            'editevent'    => 'editevent.html',
		            'editsched'    => 'editsched.html',
                            'edittable'    => 'edittable.html',
		            'editdatelist' => 'editdatelist.html',
		            'editinfobox'  => 'editinfobox.html',
		            'eventsingle'  => 'eventsingle.html',
			    'header'       => 'header.incl',
		            'info'         => 'info.incl'));

# preload some common times to put on a page
$template->set_var ('SYSTEMINFOBOX', $infobox->render_html ('system'));
$template->set_var (array ('TODAY'       => date ('n/j'),
			   'TODAYDOW'    => date ('l'),
			   'SELF'        => $SELF));
$template->parse ('HEADER', 'header');
$template->parse ('INFO', 'info');

This will allow the orignal template file to contain {HEADER} and
{INFO} as tags to include the header.incl and info.incl. Almost all
the other template files have these tags within them.

Hope this helps. 

--
Gerard Hickey			hi...@ke...
Kernel Rom Security Services	http://www.kernelrom.com/

Finger hi...@ke... for PGP keys and info.

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

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

 Maxim Derkachev <max...@bo...> a écrit le  10/7/02 11:32:

>Cookie-only plug does
>not resolve all the troubles.

In fact it is an excess defense, because  maintaining the promise of 'use cookies if enabled ' (and ignore anything in url ) would suffice.  Would render justice to those that have better  propagation available, and leave the lower 'get' mode to only those that do not support cookie.
That would be better justice, a promise maintained, and still not impose 'cookie-only' mode.

Gian

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

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

 Maxim Derkachev <max...@bo...> a écrit le  10/7/02 11:32:


>looked into CVS and found a 
>record:
>session.c
>1.214 by hholzgra
>suppress sending of cookies 
>if session id already came
>from a non-cookie source
>Commited about a year ago.
>
>It had not used to be like this 
>before. Bad guys ....

No, I think that's different, and is about about a later moment than the supposed 'first request'.
Phplib has always acted like that, and php4 session have inherited the same behaviour. A sid in url  can impose both the 'get' mode (to any cookie-enabled browser) and the user-provided session_id. Always  if the browser hadn't  a cookie yet from that site.

I mean, do you realize how hard to have anyone realize that?
>
>G> if  the site does not use 
>cookie-only, hope there's 
>some expire  set.
>expire should (if not must) 
>always be set. In cookie-only 
>or not,
>irrelevant.
>
>>>G> -what about issue a 
>new
>>>session and move to it 
>after 
>>>authenticating?
>>>But what for? You'll get 
>the 
>>>new socks with the same 
>old 
>>>holes :) 
>
>G> not exactly. These new 
>sock's holes are displaced 
>elsewhere, and by wearing
>G> these socks over the 
>previous, you end up without 
>holes ;-)
>
>Good shot :)
>
>G> when the session starts, 
>you know its mode.  
>G> Do not allow mode 
>change. Stick to the initial 
>mode.
>G> A client should not 
>disable/enable  cookies along 
>the way.
>G> A mode change is 
>equivalent to a  client 
>change, thus new session. 
>G> So the 
>downgrade-tranfer is 
>blocked, and actual 
>promiscuity can happen only
>G> among cookie-disabled 
>clients.
>
>Well, maybe. In any case, I 
>do believe that any 
>session-related stuff
>in PHP should depend on 
>builtin PHP session module. 

I am afraid it will never be as an ad-hoc tool. I consider it as those gifts in the washing powder.
Could we have speed by using plain files too?

>The reason is
>obvious - speed. All the issues 
>should be addressed to the 
>PHP CVS
>guys, so the module could be 
>fixed and extended. 

I am already 'burnt' as an ambassador chez Schasha, but we need someone with some clear ideas. KK would be perfect. 
Phplib has already been a 'lab' for PHP4 session before


>Cookie-only plug does
>not resolve all the troubles.
>

nothing will do.

Gian

RE: [Phplib-users] templates with templates

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

> I have a file viewTemplate.php
> that uses template1.templ.
> 
> Can I tell template1.templ to use another template (say, 
> template1-a.templ)?
> 
> Is this possible with phplib? templates with templates? (cascading)


http://www.sanisoft.com/phplib/manual/TemplateExamples.php

Layne Weathers
Ifworld Inc. 

Re[2]: [Phplib-users] Doc suggestions

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

Hello Giancarlo,

Tuesday, July 09, 2002, 8:42:52 PM, you wrote:
>>Security downgraded only
>>for those who don't accept 
>>cookies and take the risk of
>>session being hijacked if urls

G> but that is not true! 
G> Any cookie-enabled client (that hasn't received a cookie already) is forced to 'get'
G> mode by the simple presence of a SID in the URL.

Haven't got it until now. Just looked into CVS and found a record:
session.c
1.214 by hholzgra
suppress sending of cookies if session id already came
from a non-cookie source
Commited about a year ago.

It had not used to be like this before. Bad guys ....

G> if  the site does not use cookie-only, hope there's some expire  set.
expire should (if not must) always be set. In cookie-only or not,
irrelevant.

>>G> -what about issue a new
>>session and move to it after 
>>authenticating?
>>But what for? You'll get the 
>>new socks with the same old 
>>holes :) 

G> not exactly. These new sock's holes are displaced elsewhere, and by wearing
G> these socks over the previous, you end up without holes ;-)

Good shot :)

G> when the session starts, you know its mode.  
G> Do not allow mode change. Stick to the initial mode.
G> A client should not disable/enable  cookies along the way.
G> A mode change is equivalent to a  client change, thus new session. 
G> So the downgrade-tranfer is blocked, and actual promiscuity can happen only
G> among cookie-disabled clients.

Well, maybe. In any case, I do believe that any session-related stuff
in PHP should depend on builtin PHP session module. The reason is
obvious - speed. All the issues should be addressed to the PHP CVS
guys, so the module could be fixed and extended. Cookie-only plug does
not resolve all the troubles.



-- 
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] templates with templates

[q <qua...@sn...>]

I have a file viewTemplate.php
that uses template1.templ.

Can I tell template1.templ to use another template (say, template1-a.templ)?

Is this possible with phplib? templates with templates? (cascading)

Thank you very much

Re: [Phplib-users] Doc suggestions

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

 Maxim Derkachev <max...@bo...> a écrit le  9/7/02 18:51:

>Security downgraded only 
>for those who don't accept 
>cookies and take the risk of
>session being hijacked if urls

but that is not true! 
Any cookie-enabled client (that hasn't received a cookie already) is forced to 'get' mode by the simple presence of a SID in the URL.

there is a promise  in the term 'fallback' that is not maintained: that any better hook will be tried  to hold on to, before falling.

Because a client cannot be known as 'cookie enabled' on his first request (and if the client hasen't  previously received a cookie), a sid in the url is actually sufficient to treat that 'cookie enabled' client as 'cookie disabled' . 
And thus the downgrade
 
>they get are stolen from the 
>remote proxy
>logs or published in the 
>Internet.
>Nevertheless, sessions of 
>the cookie-enabled clients 
>can also be easily hijacked
>by a local person who knows 
>how to use a sniffer and has 
>an ability to use it.
>Both problems can be easily 
>resolved by one thing - SSL.

Once you know the url with the SID, SSL counts nothing.

>I don't forget some obvious 
>things that strengthen 
>security much more
>than cookie-only session, 
>like reasonably short session 
>and auth expiration.

Read it like that: 
if  the site does not use cookie-only, hope there's some expire  set.


>G> -what other session 
>mngmnt allows arbitrary id 
>creation and what can be a 
>honest use of it?
>Well, if it is a bug, It can be 
>easily fixed in PHP. Though, I 
>don't
>see any dishonest use of it 
>either. How the fact a 
>session with id
>'foo' is created can be a 
>security hole?

See KK's reply

>
>G> -what about issue a new 
>session and move to it after 
>authenticating?
>But what for? You'll get the 
>new socks with the same old 
>holes :) 

not exactly. These new sock's holes are displaced elsewhere, and by wearing these socks over the previous, you end up without holes ;-)

>adds some security through 
>obscurity, nothing more - 
>the session's
>insecurity is built-in and 
>inherited.
>
>G> -what about keeping 
>track of sess creation date & 
>initial mode,  and  consider a
>G> change of mode at the 
>same level as a new client 
>(mode coherence?).
>Could you be more precise? I 
>haven't caught the idea ...
>

when the session starts, you know its mode.  
Do not allow mode change. Stick to the initial mode.
A client should not disable/enable  cookies along the way.
A mode change is equivalent to a  client change, thus new session. 
So the downgrade-tranfer is blocked, and actual promiscuity can happen only among cookie-disabled clients.

Gian

Re: [Phplib-users] Doc suggestions

[Kristian K. <kk...@ne...>]

Am Dienstag, 9. Juli 2002 16:51 schrieb Maxim Derkachev:
> Security downgraded only for those who don't accept cookies
> and take the risk of session being hijacked if urls they get
> are stolen from the remote proxy logs or published in the
> Internet.

URL IDs leak like hell. They are being logged by proxies (true=20
for hostname and path component IDs, not true for Squid and GET=20
parameters). They leak via references header (true for all three=20
systems). They are being bookmarked (true for all). They are=20
mailed (true for all) or worse, printed in magazines.

Cookies don't do any of this. Cookies are highly preferred as a=20
mode of ID propagation.

For true security, SSL is a necessity independent of ID=20
propagation mode. Still, cookies are even preferred in this=20
situation due to references, bookmarks and mail.

> of it either. How the fact a session with id 'foo' is created
> can be a security hole?

It enables "known session id" attacks on unsuspecting end users.=20
In this attack model, Charlie sends mail with prepared URLs to=20
Bob, inviting them to Alices Online Restaurant. Since Charlies=20
invitations already contain IDs, Charlie does know Bobs session=20
ID and can hijack Bobs session easily.

A session library should check if a session record for a given ID=20
is present, and if it isn't should generate a new, random ID=20
with an empty session record, then restart the session. This=20
will protect against the above attacker model.

Kristian

Re: [Phplib-users] Doc suggestions

[Kristian K. <kk...@ne...>]

Am Dienstag, 9. Juli 2002 15:54 schrieb Giancarlo:
> -don't you beleive that, among these various propagations,
> cookies offer more guarantees=20

There are two known general modes of ID propagation. These are=20
cookies and making the ID part of the URL. The latter is always=20
deprecated, as the ID becomes part of the URL, that is, becomes

a) visible
b) logged in many proxies
c) part of bookmarks
d) is probably being mailed when a URL is mailed by a user.
e) is lost when the users browsed to a different target and later=20
returns.
f) is leaked out of the application via referer

The URL can carry an ID in three known places. These are GET=20
parameters (http://server/path/program?ID=3D...), path components=20
(http://server/ID/path/program), and hostnames=20
(http://xID.serverdomain/path/program). All of these have=20
distinct advantages and disadvantages, and all of them are=20
subject to the risks a-f shown above. Koehntopp PHPLIB only used=20
GET parameters, as they did not require special server setup=20
procedures, no special DNS setup and are not patented. It is=20
only a fallback mechanism anyway, and not worth bothering more=20
than absolutely necessary.

So an application should always try to use cookies and only fall=20
back to URL propagation if necessary.

>-is it right  to downgrade
> everybody's security to the minimum common of those  who have
> cookies disabled, whith an effect exactly opposite of their
> reason to do so. Shouldn't it be more right then to confine
> that to only those who cannot afford a better way?=20

See discussion above. Cookies are the recommended way to=20
propagate an ID, and should be used wherever possible. Note that=20
you probably have to provide a valid P3P policy in order for=20
current MSIE to accept a session cookie.

>-what other
> session mngmnt allows arbitrary id creation and what can be a
> honest use of it?=20

None. Arbitrary ID creation was an accidental artefact of the=20
Koehntopp PHPLIB implementation. In fact the original code=20
should have checked for the existence of a session with that ID,=20
and created a new ID if there was no session record present with=20
the original ID. I remember thinking about that case, and then=20
dropping it for performance reasons (that was using MySQL based=20
sessions on a 143 MHz Ultra-Sparc 1).

>-what about issue a new session and move to
> it after authenticating?=20

Why should that be useful? Sessions and authentications are=20
different and independent things and should have only little=20
interaction.

>-what about keeping track of sess
> creation date & initial mode,  and  consider a change of mode
> at the same level as a new client (mode coherence?).=20

Sorry, I am missing the previous discussion here. What exactly=20
are the problem and idea behind this?

>- what is
> the use of the auth['uid']=3D'form' status, if not better
> security?

Koehntopp PHPLIB was programmed with interstitial (blocking)=20
authentication in mind. The state machine is really only useful=20
for that, and little else. Default Auth and auth_preauth() were=20
added as an afterthought in Koehntopp PHPLIB, and are really=20
cluttering up the Auth process.=20

The whole thing should be redesigned, and using a sidebar login=20
and default authentication as the main model, as this is much=20
more common and useful than the original interstitial auth.


Note that I am not longer involved in PHPLIB development at all,=20
am no longer using PHP very much, and am reading this list only=20
sporadically. So this are just the ramblings of some old guy who=20
left you with some original code...

Kristian

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

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

Hello Giancarlo,

G> Ok, but this was the most'mundane' and less significant among a series of other questions:

G> -don't you beleive that, among these various propagations, cookies offer more guarantees
Yes, they do.

G> -is it right  to downgrade everybody's security to the minimum common of those  who have cookies disabled, whith an effect exactly opposite of their reason to do so. Shouldn't it be more right
G> then to confine that to only those who cannot afford a better way?

Security downgraded only for those who don't accept cookies and take the risk of
session being hijacked if urls they get are stolen from the remote proxy
logs or published in the Internet.
Nevertheless, sessions of the cookie-enabled clients can also be easily hijacked
by a local person who knows how to use a sniffer and has an ability to use it.
Both problems can be easily resolved by one thing - SSL.
I don't forget some obvious things that strengthen security much more
than cookie-only session, like reasonably short session and auth expiration.

G> -what other session mngmnt allows arbitrary id creation and what can be a honest use of it?
Well, if it is a bug, It can be easily fixed in PHP. Though, I don't
see any dishonest use of it either. How the fact a session with id
'foo' is created can be a security hole?

G> -what about issue a new session and move to it after authenticating?
But what for? You'll get the new socks with the same old holes :) It
adds some security through obscurity, nothing more - the session's
insecurity is built-in and inherited.

G> -what about keeping track of sess creation date & initial mode,  and  consider a
G> change of mode at the same level as a new client (mode coherence?).
Could you be more precise? I haven't caught the idea ...

G> - what is the use of the auth['uid']='form' status, if not better security?
I guess, It's just an intermediate state. Not quite sure ...



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

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

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

 Maxim Derkachev <max...@bo...> a écrit le  9/7/02 11:28:

>Hello, Giancarlo,
>
>> I would like to know which 
>other major scripting 
>language allows any
>> session propagation other 
>than cookie. 
>
>Any language. It is not 
>question of language. I

Ok, but this was the most'mundane' and less significant among a series of other questions:

-don't you beleive that, among these various propagations, cookies offer more guarantees
-is it right  to downgrade everybody's security to the minimum common of those  who have cookies disabled, whith an effect exactly opposite of their reason to do so. Shouldn't it be more right then to confine that to only those who cannot afford a better way?
-what other session mngmnt allows arbitrary id creation and what can be a honest use of it?
-what about issue a new session and move to it after authenticating? 
-what about keeping track of sess creation date & initial mode,  and  consider a change of mode at the same level as a new client (mode coherence?). 
- what is the use of the auth['uid']='form' status, if not better security?

Gian
 

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

[Guillaume D. <gde...@pr...>]

> Ok, but what to do with hiddens in GET forms? SID is appended to the
> URL anyway, from the action attribute or from a hidden field.
> Amazon even do not use GET parameters - it injects the SID into
> url in the way http://www.amazon.com/...path.../...SID../...etc... end
> extracts SID from path.
> There are a lot of ways to save SID in URL - one could use DNS tricks
> (e.g. http://sessionID.www.server.com), PATH_INFO (like Amazon does),
GET
> parameters. All the tricks imply URL rewriting.
> Of course, there's not a big deal to implement a POST fallback
> method (I did) - you should rewrite all links to POST forms at the
> server, or use client-side onClick event to generate POST forms from
> links on the fly and really POST them instead of just following the
> links. But I suppose It would be users' nightmare - the Back/Forward
> buttons would become useless. Of course, SID should be included

I'm totally agree with you. I just wanted to precise this particular
point

> GD> It's more clearly to write : <form action="toto.php"
> method="post">><input type="hidden" name="SID"
> GD> value="fdsfsdfdsfdfsfdsfsdf"> than to write <form
> GD> action="toto.php?SID=dsfdsfsdfdsfdssf" method="post"> ... doing
this
> GD> works... but it's not a good way to program IMHO... mixing GET and
POST
> GD> variables in the same request... hurk... ;-)
>
> No one does.

Unfortunately there are "morons" to do that... I've seen this kind of
ugly code many times in web application (especially in caddy routine...)

> Embedding hidden field with SID into any form (POST or
> GET) is sufficient. Only local relative links (<a href=/some/page) and
> redirects are usually being rewrote.

I'm agree also....

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

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

Hello Guillaume,

Tuesday, July 09, 2002, 1:24:37 PM, you wrote:
GD> Well... in a formular, you use an hidden input to propagate the SID...
GD> it's not strictly the same thing of an URL rewriting (if you use the
GD> method POST, I mean...). URL use the HTTP GET method...

Ok, but what to do with hiddens in GET forms? SID is appended to the
URL anyway, from the action attribute or from a hidden field.
Amazon even do not use GET parameters - it injects the SID into
url in the way http://www.amazon.com/...path.../...SID../...etc... end
extracts SID from path.
There are a lot of ways to save SID in URL - one could use DNS tricks
(e.g. http://sessionID.www.server.com), PATH_INFO (like Amazon does), GET
parameters. All the tricks imply URL rewriting.
Of course, there's not a big deal to implement a POST fallback
method (I did) - you should rewrite all links to POST forms at the
server, or use client-side onClick event to generate POST forms from
links on the fly and really POST them instead of just following the
links. But I suppose It would be users' nightmare - the Back/Forward
buttons would become useless. Of course, SID should be included

GD> It's more clearly to write : <form action="toto.php"
method="post">><input type="hidden" name="SID"
GD> value="fdsfsdfdsfdfsfdsfsdf"> than to write <form
GD> action="toto.php?SID=dsfdsfsdfdsfdssf" method="post"> ... doing this
GD> works... but it's not a good way to program IMHO... mixing GET and POST
GD> variables in the same request... hurk... ;-)

No one does. Embedding hidden field with SID into any form (POST or
GET) is sufficient. Only local relative links (<a href=/some/page) and
redirects are usually being rewrote.


-- 
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: Rp.: Re: Rp.: Re: [Phplib-users] Doc suggestions

[Guillaume D. <gde...@pr...>]

> extension, just like in ASP, JSP/Servlets and other. Any good
> session handling object is written with cookie-less environment in
> mind. Cookies OR url rewriting are the only available methods in HTTP
> for the session propagation,

Well... in a formular, you use an hidden input to propagate the SID...
it's not strictly the same thing of an URL rewriting (if you use the
method POST, I mean...). URL use the HTTP GET method...

It's more clearly to write : <form action="toto.php"
method="post"><input type="hidden" name="SID"
value="fdsfsdfdsfdfsfdsfsdf"> than to write <form
action="toto.php?SID=dsfdsfsdfdsfdssf" method="post"> ... doing this
works... but it's not a good way to program IMHO... mixing GET and POST
variables in the same request... hurk... ;-)

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

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

Hello, Giancarlo,

> I would like to know which other major scripting language allows any
> session propagation other than cookie. 

Any language. It is not question of language. It is a question of
technology. Session module is not a core part of PHP. It is just an
extension, just like in ASP, JSP/Servlets and other. Any good
session handling object is written with cookie-less environment in
mind. Cookies OR url rewriting are the only available methods in HTTP
for the session propagation, and both are used.
Look at Amazon.com. What do you think those long meaningless digit
strings in urls do? They are nothing more than session identifiers.
Well, they at Amazon do extra work - they even don't remove SIDs when
cookies are enabled.
Then look at Sun.com. They use the same technology, just dig beyond
the first advertising pages to Sun's shop or something else that
requires a session to work - you'll see the SID in urls.
Of course, they use servlets/JSP.
Look at WROX site, they also munge cookies and run ASP.
Zope (the system in Python) also use both cookies and url rewriting
for session handling.




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

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

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

Then you agree on the other points of the message?

Giancarlo


 Kristian Koehntopp <kr...@ko...> a écrit le  8/7/02 20:41:

>Am Do 4.Juli 2002 23:38 
>schrieb Giancarlo:
>> I would like to know which 
>other major scripting 
>language allows any
>> session propagation other 
>than cookie. 
>
>http://www.google.com/sear
>ch?q=cookie%20munger
>
>http://www.six.udc.es/softw
>are/technet/17.html
>"Using the IIS Resource Kit 
>CD"
>
>"Cookie Munger
>
>Cookie Munger is a filter 
>that enables Active Server 
>Pages to provide 
>cookielike functionality to 
>browsers that do not 
>support cookies or that do 
>not accept them."
>
>
>-- 
>http://www.amazon.de/exec
>/obidos/wishlist/18E5SVQ5H
>JZXG
>
>
>
>-----------------------------
>--------------------------
>This sf.net email is 
>sponsored by:ThinkGeek
>Oh, it's good to be a geek.
>http://thinkgeek.com/sf
>_____________________________
>__________________
>Phplib-users mailing list
>Php...@li...urcefor
>ge.net
>https://lists.sourceforge.net
>/lists/listinfo/phplib-users

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

[Kristian K. <kr...@ko...>]

Am Do 4.Juli 2002 23:38 schrieb Giancarlo:
> I would like to know which other major scripting language allows any
> session propagation other than cookie.=20

http://www.google.com/search?q=3Dcookie%20munger

http://www.six.udc.es/software/technet/17.html
"Using the IIS Resource Kit CD"

"Cookie Munger

Cookie Munger is a filter that enables Active Server Pages to provide=20
cookielike functionality to browsers that do not support cookies or that =
do=20
not accept them."


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

Re: [Phplib-users] OOHForms: Removing element

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

Hello Stefan,

> The problem is that a form element with the *same name* but different > type is beeing used twice in a php-document: First as type=select and 
to use OOHForms you have to create a form object and add elements like:

$f = new form;                   // create a form object

$f->add_element(...);     // set up form elements


> after that in a completely new context as type=hidden. For any reason 
so why don't you create a new form object for your "completely new context" like this:

$g = new form;                   // create a form object

$g->add_element(...);     // set up form elements



HTH Peter KUrsawe

Re: [Phplib-users] regexp url ohhforms

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

On Mon, Jul 08, 2002 at 02:09:19PM +0200, Bertram Simon wrote:
> Hi there,
> 
> I am looking for a regular expresions, which hits a complete url in
> oohforms:
> 
> http://www.foo.com/index.php
> http://www.foo.com/default.asp?id=1&m=2
> https://www.foo.de
> 
> Any ideas?
> 
> This is my last version, but i doesn't work:
> 
> (^$)|(^http\://[a-z0-9\.-]+\.[a-z]{2,3}(/\S*)?$)

Here's the last regular expression that I did to parse a url:

/^(?:([a-zA-Z]+)\:\/\/)?(?:([A-Za-z0-9\_\.\-]*?)(?:\:([A-Za-z0-9\_\.\-]*?))?\@)?([a-zA-Z0-9\.\_\-]*?)(?:\:([0-9]{1,5}))?(?:(\/(?:[^\?]*?\/)*)([^\?]*?)?(?:\?(.*?))?(?:#(.*))?)?$/

It matches (in this order):
$service,$user,$password,$host,$port,$path,$file,$params,$anchor

URL matching is non-trivial.

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

[Phplib-users] regexp url ohhforms

[Bertram S. <ph...@ag...>]

Hi there,

I am looking for a regular expresions, which hits a complete url in
oohforms:

http://www.foo.com/index.php
http://www.foo.com/default.asp?id=1&m=2
https://www.foo.de

Any ideas?

This is my last version, but i doesn't work:

(^$)|(^http\://[a-z0-9\.-]+\.[a-z]{2,3}(/\S*)?$)


Thank you

Bertram

[Phplib-users] OOHForms: Removing element

[Stefan M. <me...@me...>]

Hello,

is there a chance to remove an oohform element again, which has been 
added previously with the add_element function?

The problem is that a form element with the *same name* but different 
type is beeing used twice in a php-document: First as type=select and 
after that in a completely new context as type=hidden. For any reason 
it seems that the first element is still active and beeing parsed 
together with new second hidden element through a get_finish() call.

To make it short: Is there a pendant to the add_element function 
(e.g. remove_element) or any other chance to solve the problem 
without changing the source of oohforms.inc in PHPLib?

Thanks in advance,
Stefan Melcher

RE: [Phplib-users] Doc suggestions

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

At 7:13 -0700 5/7/02, rick herbel wrote:

>check out the microsoft asp sessions they all set a cookie

Yeah, but we all know Microsoft solutions are broken which
is why we use PHP :)

 ...R.

[Phplib-users] sess vs. auth instantiation

[Ron N. <ro...@im...>]

Why would the the "Example_Session" object (in the demo program index.php3) 
instantiate correctly, with sessions working, but the Example_Auth class 
(in the demo program showoff.php3) come up with a bunch of "undefined 
object" warnings?

If the include path was off, seems like sessions wouldn't work.  The 
prepend file is there, because if I do an include(prepend.php3) I get 
duplicate object warnings.

Ideas?  Tnx in advance.
Ron

RE: [Phplib-users] Doc suggestions

[rick h. <ric...@tc...>]

check out the microsoft asp sessions they all set a cookie

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of Richard
Archer
Sent: Thursday, July 04, 2002 1:53 PM
To: php...@so...
Subject: Re: [Phplib-users] Doc suggestions


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.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf
_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users