php-windows Digest 4 Mar 2001 04:02:49 -0000 Issue 473
Topics (messages 5806 through 5811):
Re: expat
5806 by: alain samoun
pulling arrays from nested arrays?
5807 by: Doug Brewer
5808 by: Ernest E Vogelsinger
IE 5.5,authentication,PHP sessions: IE never stops running?
5809 by: Ken
5810 by: John Henckel
5811 by: Ken
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
With Apache it works for me...
For instructions, try the example of this article:
http://www.phpbuilder.com/columns/justin20000428.php3
There is an error at the end of the xml file, <newsboy> should be <NewsBoy>
after this correction, everything works.
Message from Alain Samoun
[EMAIL PROTECTED]
-----Original Message-----
From: Rohan Amin [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 02, 2001 7:38 PM
To: [EMAIL PROTECTED]
Subject: [PHP-WIN] expat
Has anyone been able to get expat working on Windows using Personal Web
Server? I can't find good instructions anywhere...
Thanks,
Rohan Amin
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Hello, looking for some insight on the behavior of arrays.
I've got an array. One of the elements of that array is another array.
If I refer to it this way, I can get at it:
while(list($this, $that) = each($first_array["second array"])) {
# it works!
}
But let's say I want to alter the items in the second array, removing
items or sorting differently, so to preserve the original I want to
create a new array equivalent to the second array:
$new_array = $first_array["second array"]; # what's wrong with this?
while(list($this, $that) = each($new_array)) {
# doesn't work!
}
Any ideas or pointers? I've tried:
$new_array = array ($first_array["second array"]);
but no go.
TIA,
Doug
At 01:21 04.03.2001, Doug Brewer said:
--------------------[snip]--------------------
>$new_array = $first_array["second array"]; # what's wrong with this?
this is a copy of $first_array["second array"].
>while(list($this, $that) = each($new_array)) {
> # doesn't work!
>}
this modifies the copy!
After applying the modifications, do
$first_array["second array"] = $new_array;
to replace the original with the modified contents.
Usually you would use references to arrays to handle this, but I haven't
found a way yet to get list() to return references instead of copies...
...ebird
>O Ernest E. Vogelsinger
(\) http://www.1-at-web.at/
^ ICQ# 13394035
I'm experiencing strange behavior with my user authentication scheme in my PHP app,
with users using IE 5.5.
I am using browser authentication (WWW-Authenticate and 401 headers), "no cache"
headers, and PHP 4 sessions.
I am finding that even when the user totally quits IE, if he then restarts IE, one or
both (haven't isolated for sure yet) of the following happen:
- The browser still knows the user and password, and so will send it to the server
upon an authentication request under the same realm, without prompting the user. (The
user does NOT have "save this password" checked on the user/password prompt when it
first comes up.)
- The session is still active. A call to session_start() returns the pre-existing
session, instead of getting a new one.
If the user restarts his machine, IE no longer remembers his user and password, and so
a prompt is displayed upon authentication headers being sent. And I presume (not 100%
certain) that a new session gets created.
Both of these are behaving like IE is still running. Is this a known issue with IE
5.5? Does it just stay running? These symptoms make it sound like this, and less
like a logic problem in my PHP app. (I have verified that the username and password
are sent when the user gets an authentication prompt, without the user typing
anything. I'm assuming there's no possible way that a PHP session can retain this
information; I am reading $PHP_AUTH_USER and $PHP_AUTH_PW...there's no way these can
be set unless the browser were already running and the user had previously entered
them into their prompts, right?)
Has anyone else run into this? My application works perfectly under Netscape 4, IE 4,
and Opera 5.
Thanks,
Ken
I, too, am using PHP with authentication and IE 5. However I am using
.htaccess to generate the headers instead of PHP. I found this text...
a quote from PHP manual.....
>Both Netscape and Internet Explorer will clear the local browser window's
>authentication cache for the realm upon receiving a server response of
>401. This can effectively "log out" a user, forcing them to re-enter their
>username and password. Some people use this to "time out" logins, or
>provide a "log-out" button.
This doesn't answer Ken's question, but at least perhaps you can use it to
provide a "log-out" button. Let me know if it works or not.
At 09:57 PM 3/3/01 -0500, kenzo wrote:
>I'm experiencing strange behavior with my user authentication scheme in my
>PHP app, with users using IE 5.5.
>
>I am using browser authentication (WWW-Authenticate and 401 headers), "no
>cache" headers, and PHP 4 sessions.
>
>I am finding that even when the user totally quits IE, if he then restarts
>IE, one or both (haven't isolated for sure yet) of the following happen:
>
>- The browser still knows the user and password, and so will send it to
>the server upon an authentication request under the same realm, without
>prompting the user. (The user does NOT have "save this password" checked
>on the user/password prompt when it first comes up.)
>- The session is still active. A call to session_start() returns the
>pre-existing session, instead of getting a new one.
>
>If the user restarts his machine, IE no longer remembers his user and
>password, and so a prompt is displayed upon authentication headers being
>sent. And I presume (not 100% certain) that a new session gets created.
>
>Both of these are behaving like IE is still running. Is this a known
>issue with IE 5.5? Does it just stay running? These symptoms make it
>sound like this, and less like a logic problem in my PHP app. (I have
>verified that the username and password are sent when the user gets an
>authentication prompt, without the user typing anything. I'm assuming
>there's no possible way that a PHP session can retain this information; I
>am reading $PHP_AUTH_USER and $PHP_AUTH_PW...there's no way these can be
>set unless the browser were already running and the user had previously
>entered them into their prompts, right?)
>
>Has anyone else run into this? My application works perfectly under
>Netscape 4, IE 4, and Opera 5.
>
>Thanks,
>Ken
John Henckel alt. mailto:[EMAIL PROTECTED]
Zumbro Falls, Minnesota, USA (507) 753-2216
http://geocities.com/jdhenckel/
Thanks for the idea, John.
I know about the auth logout. Unfortunately, that means that when a user clicks
"logout", he gets a "log in" prompt! And, in IE, he has to deliberately blank out the
password field, THEN hit enter, THEN the prompt will come again, and he has to hit
escape.
There's another possible path than the above, but it, too, involves a prompt coming up
when they hit logout, and they have to clear the password field.
If, when they click "logout", and they get the first confusing "log in" prompt, they
click "cancel", then they won't be logged out. The browser will continue to remember
and report their username and password.
Try explaining how to follow these instructions to an inexperienced user!
The point of my system was to use, among other things, the session cookie to determine
whether the user is in a new session or the same one as before. The logout button
sets a flag in the database. In short, then I know, when the user's browser tries to
log in again, if he's in the SAME session, and he had previously hit logout, then I
will have to send an auth header, with a new realm. But if he's in a NEW session,
then I can assume his browser no longer remembers his user/pass, so the actual user
must've typed it, so here I will let the user proceed without sending an auth header.
If IE 5.5 refuses to clear the user/password field, and refuses to clear the session
cookie, then I can't think of any way of him getting to log out without making him go
through an annoying second "enter your username and password" prompt...which is most
disappointing.
It's sounding like, thanks to this terrible behavior of IE 5.5, I may have to switch
to not using browser authentication at all, and instead deal with the nuisance or
security risk of passing along authentication information in the session, and
requiring the user to click "logout" when it's time to logout (forcing a destruction
of the information stored in the session).
Any suggestions?
- Ken
At 09:45 PM 3/3/01 -0600, John Henckel wrote:
>I, too, am using PHP with authentication and IE 5. However I am using .htaccess to
>generate the headers instead of PHP. I found this text...
>
>a quote from PHP manual.....
>>Both Netscape and Internet Explorer will clear the local browser window's
>authentication cache for the realm upon receiving a server response of 401. This can
>effectively "log out" a user, forcing them to re-enter their username and password.
>Some people use this to "time out" logins, or provide a "log-out" button.
>
>This doesn't answer Ken's question, but at least perhaps you can use it to provide a
>"log-out" button. Let me know if it works or not.
>
>At 09:57 PM 3/3/01 -0500, kenzo wrote:
>>I'm experiencing strange behavior with my user authentication scheme in my PHP app,
>with users using IE 5.5.
>>
>>I am using browser authentication (WWW-Authenticate and 401 headers), "no cache"
>headers, and PHP 4 sessions.
>>
>>I am finding that even when the user totally quits IE, if he then restarts IE, one
>or both (haven't isolated for sure yet) of the following happen:
>>
>>- The browser still knows the user and password, and so will send it to the server
>upon an authentication request under the same realm, without prompting the user.
>(The user does NOT have "save this password" checked on the user/password prompt when
>it first comes up.)
>>- The session is still active. A call to session_start() returns the pre-existing
>session, instead of getting a new one.
>>
>>If the user restarts his machine, IE no longer remembers his user and password, and
>so a prompt is displayed upon authentication headers being sent. And I presume (not
>100% certain) that a new session gets created.
>>
>>Both of these are behaving like IE is still running. Is this a known issue with IE
>5.5? Does it just stay running? These symptoms make it sound like this, and less
>like a logic problem in my PHP app. (I have verified that the username and password
>are sent when the user gets an authentication prompt, without the user typing
>anything. I'm assuming there's no possible way that a PHP session can retain this
>information; I am reading $PHP_AUTH_USER and $PHP_AUTH_PW...there's no way these can
>be set unless the browser were already running and the user had previously entered
>them into their prompts, right?)
>>
>>Has anyone else run into this? My application works perfectly under Netscape 4, IE
>4, and Opera 5.
>>
>>Thanks,
>>Ken
