Hello all,
I have posted a similar question in comp.lang.php in the past, but haven't
had any response to it then. I kinda swept the problem under the rug since
then. But I would really like to resolve this issue once and for all now.
The problem might be PHP related but since I only develop applications using
PHP, I'm not a hundred percent sure. Therefor I've taken the liberty to
crosspost to comp.lang.php and alt. www.webmaster. I assume the majority of
frequent contributors of these groups have dealt with developing session
management also, so I'm kind of hoping your experience in this field might
resolve this issue.
The problem is the following:
User profiles on the site I'm developing will be publically available
through:
http://www.example.com/profile/view/<username>
A users own profile (when logged in) will be available through: http://www.example.com/profile/view/ or http://www.example.com/profile/ (which will redirect to last url)
So when an anonymous user visits one of these last two pages, the requested
page is stored as a referer in a session and the user is redirected to http://www.example.com/user/login/
where the user is prompted to login.
On succes it gets redirected to the stored referer url again. A pretty
common procedure I would assume.
This works fine on either IE or Firefox (windows). But in Opera I get
multiple sessions created in the database of which one *does* contains a
userId but Opera redirects back to the login page again.
Only when I manually enter the target url I do get to see the logged in
users profile page.
My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page to
serve. So, after much testing, I thought it might have something to do with
Opera's favicon requests.
But after defining an extra RewriteRule
RewriteRule ^(.*)favicon.ico /images/favicon.gif [NC,L]
in my .htaccess file, the problem still persisted.
Are any of you formiliar with this issue?
I understand that this might be difficult to interpret without seeing any
code. But since the code is pretty extensive, and I haven't really narrowed
it down to a particular few lines, I thought I describe the problem without
code first. Maybe somebody has had similar experiences and knows what the
problem could be.
But if you desire to examine some code, I'ld be happy to put some up on a
filesharing server for you to view. (e.g. the session wrapper class and
other relevant code).
Thank you for your time and input.
Cheers. 41  3182 
"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl.. .
Hello all,
<snip>
PS.: I forgot to mention that, before redirecting, I *do* let PHP perform a
session_write_close().
amygdala wrote:
The problem might be PHP related but since I only develop applications using
PHP, I'm not a hundred percent sure. Therefor I've taken the liberty to
crosspost to comp.lang.php and alt.www.webmaster. I assume the majority of
frequent contributors of these groups have dealt with developing session
management also, so I'm kind of hoping your experience in this field might
resolve this issue.
I don't code in PHP. I have written my own session management procedures
in Perl. I will answer based on the assumption that PHP uses cookies to
manage sessions.
User profiles on the site I'm developing will be publically available
through:
http://www.example.com/profile/view/<username>
A users own profile (when logged in) will be available through:
http://www.example.com/profile/view/ or
http://www.example.com/profile/ (which will redirect to last url)
So when an anonymous user visits one of these last two pages, the requested
page is stored as a referer in a session and the user is redirected to
http://www.example.com/user/login/
where the user is prompted to login.
On succes it gets redirected to the stored referer url again. A pretty
common procedure I would assume.
This works fine on either IE or Firefox (windows). But in Opera I get
multiple sessions created in the database of which one *does* contains a
userId but Opera redirects back to the login page again.
(I realize I haven't snipped very well, but I don't know what to remove
and still keep my comments in context.)
Again, I don't know how PHP manages sessions, but what you are saying
here about Opera seems strange to me. If PHP is using a cookie to store
session information in the browser, then there should only be one
session. One cookie can't have multiple values.
BTW, the browser doesn't create sessions in the database. PHP is doing
that. The browser stores session information in a cookie, which can only
contain one value.
My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page to
serve.
Why? If you have stored the URL of the page you want to go to in a
cookie, you should be looking for which page to serve in that cookie.
Or are you examining $_SERVER[ 'REQUEST_URI' ] to determine what URL to
store in the cookie? Again, why? If I have a PHP script at
example.com/user/login, why doesn't that script know its own URL? Why
can't the script at example.com/user/login simply store its own URL in
the cookie?
I may be way off base here, but your approach seems odd to me.
On Fri, 10 Aug 2007 17:39:55 +0200, amygdala <no*****@noreply.comwrote:
Hello all,
I have posted a similar question in comp.lang.php in the past, but
haven't
had any response to it then. I kinda swept the problem under the rug
since
then. But I would really like to resolve this issue once and for all now.
The problem might be PHP related but since I only develop applications
using
PHP, I'm not a hundred percent sure. Therefor I've taken the liberty to
crosspost to comp.lang.php and alt.www.webmaster. I assume the majority
of
frequent contributors of these groups have dealt with developing session
management also, so I'm kind of hoping your experience in this field
might
resolve this issue.
The problem is the following:
User profiles on the site I'm developing will be publically available
through:
http://www.example.com/profile/view/<username>
A users own profile (when logged in) will be available through:
http://www.example.com/profile/view/ or
http://www.example.com/profile/ (which will redirect to last url)
So when an anonymous user visits one of these last two pages, the
requested
page is stored as a referer in a session and the user is redirected to
http://www.example.com/user/login/
where the user is prompted to login.
On succes it gets redirected to the stored referer url again. A pretty
common procedure I would assume.
This works fine on either IE or Firefox (windows). But in Opera I get
multiple sessions created in the database of which one *does* containsa
userId but Opera redirects back to the login page again.
Only when I manually enter the target url I do get to see the logged in
users profile page.
My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page
to
serve. So, after much testing, I thought it might have something to do
with
Opera's favicon requests.
Hmm, FF & MSIE equally request that damn thing, shouldn't matter I think....
I understand that this might be difficult to interpret without seeing any
code. But since the code is pretty extensive, and I haven't really
narrowed
it down to a particular few lines, I thought I describe the problem
without
code first. Maybe somebody has had similar experiences and knows what the
problem could be.
It's very hard to say. Are you sure you're not actually using the HTTP
REFERER header instead of the one stored in a session? It's pretty
unreliable, and very easy to disabled in Opera, i.e. the server never gets
this header. (Don't know wether it's a standard settings, it's a settingI
use nonetheless, and stored under'quick preferences', so easily accessable
for normal users). Another easily accessed Opera feature is to disable
redirecting. If you're relying on it to transfer the user to another page,
but don't exit your script after the redirect, chances are that in Opera
it might come across as 'the same page again'. So on a redirect, always do
something like:
$target = 'http://www.example.com';
header("Location: $target");
echo 'You're be redirected to '.$target.'. Click <a
href="'.$target.'">here</aif it doesn't work';
exit; //<-----IMPORTANT!
A very easy mistake to make is also differnce in domain (for instance with
or without 'www.' in front of it, cookies that are sent vie https aren't
set by http and vice versa).
If that doesn't work, I'd set up a testpage instead of the normal redirect
to /user/login/, and instead of redirecting, dump the session-id & the
$_SESSION array, and exit. That might give you some insight in what
happens.
It could be a path issue for the cookie also though (as /profile &
/user/login are different, maybe the cookie is set carelessly, and there
are 2 different cookies for the differents paths)... If you use
LiveHTTPHeaders in FF or Fiddler in MSIE, what do you see as Set-Cookie
statements?
If all fails, I'd appreciate a live example, as I'm quite an Opera-fan,
and I can't let this slide :P
f'upped to comp.lang.php BTW.
--
Rik Wasmus
In article <46***********************@news.kpnplanet.nl>,
amygdala <no*****@noreply.comwrote:
>
"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl. ..
>Hello all,
<snip>
PS.: I forgot to mention that, before redirecting, I *do* let PHP perform a
session_write_close().
Why? Are you using framesets? If so, why?
I do something similar on my site, and I use Opera to test. A
user gets a session cookie when first accessing any page on my
site. As long as the $_SESSION array contains no login information,
some content is restricted; any attempts to access that restricted
content go to a login page. As soon as the user logs in, $_SESSION
contains data proving that the user is logged in. $_SESSION also
contains the last page visited and next page requested, at all
times, so it's trivial to direct the user to the proper page after
logging in, using header("Location: http://example.com/xyz.php?a=b");
This works for me in Opera. At *no* time do I attempt to close the
session. That happens only when the user logs off, in which case I
delete the session.
-A
On Fri, 10 Aug 2007 18:31:55 +0200, axlq <ax**@spamcop.netwrote:
In article <46***********************@news.kpnplanet.nl>,
amygdala <no*****@noreply.comwrote:
>>
"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl. ..
>>Hello all,
<snip>
PS.: I forgot to mention that, before redirecting, I *do* let PHP
perform a
session_write_close().
Why?
A good reason would be several concurrent requests (which also might be
stylesheets, javascript, images, the lot), a website in which there are
'heavy' pages (take a long time to load), and users are likely to have
several windows open.
It is not strictly necessary to use session_write_close(), but a lot of
loading problems in a PHP-heavy site can be avoided with it. And if you're
done with a session, why not? session-closing/database-closing/unsetting
variables are just the kind of thing that might improve performance when
the server is stretched.
F'upped to c.l.php
--
Rik Wasmus
On Fri, 10 Aug 2007 18:10:24 +0200, Scott Bryce <sb****@scottbryce.com>
wrote:
>My application examins $_SERVER[ 'REQUEST_URI' ] to determine which
page to serve.
Why?
Standard practice: single 'point-of-entry' website, serving up pages as
requested in the url. Saves a whole lot of code duplication, allthough it
might decrease performance. Look at it like an index file in the root
examing GET variables and serving up different pages according to the
given values. Only, for more easily remembered urls for humans, and the
kind of urls search-engines like, the url contains a pseudo-path: the
actual path does not exists, but is handled by a script which might be
anywhere.
If you have stored the URL of the page you want to go to in a cookie,
you should be looking for which page to serve in that cookie.
Never store that kind of a thing in a cookie. Use a session and just a
session cookie, store data in the server-side session.
Or are you examining $_SERVER[ 'REQUEST_URI' ] to determine what URL to
store in the cookie? Again, why? If I have a PHP script at
example.com/user/login, why doesn't that script know its own URL?
Because the script might not be there? It's just a script, where the
request finally ends up being processed can have very little to do with
the requested URL.
I may be way off base here, but your approach seems odd to me.
More a difference in approach, but a very normal one.
--
Rik Wasmus
I ran into a login-related problem with NN4 about 6 years ago. This
was with an ASP site. The problem might be similar enough to suggest
somethig helpful:
I used a frameset that consisted of two frames. Everything was from
the same domain. On frame offered help links (that didn't require a
login). The other frame offered a login screen. Upon a successful
login, the login page was replaced by the applicaiton home page (in
the same frame). We were using the standard ASP Session to keep track
of the login.
This worked very well in IE and NN *** until *** we added SSL to
protect the login page. To do this, the login page url changed from http://www.whatever.com/login.asp to https://www.whatever.com:443/login.asp.
The rest of the site url's remained the same. That broke the login
with NN4. It still worked fine with IE.
In NN4, the browser cookie was apparantly not getting set to record
the session id and thus the login state was lost. I experimented, but
was not able to come up with a simple solution. We ended up replacing
the frameset with a simple login page (no frameset). This allowed the
login to work in NN4 (cookie saved, even with SSL). Once logged in,
the user was redirected to the actual application, which then loaded
the frameset and two frames (help and application).
It looked like the problem was caused by bad vibes between NN4,
frames, SSL and cookies. I never found a smoking gun. I just changed
the design, which was not great to begin with.
BTW, I stopped using framesets almost 5 years ago. I stopped
supporting NN4 about 4 years ago. Haleluja!
I hope this helps.
Gerard Vignes
On Fri, 10 Aug 2007 18:47:24 +0200, www.gerardvignes.com
<ge**********@gmail.comwrote:
I ran into a login-related problem with NN4 about 6 years ago. This
was with an ASP site. The problem might be similar enough to suggest
somethig helpful:
I used a frameset that consisted of two frames. Everything was from
the same domain. On frame offered help links (that didn't require a
login). The other frame offered a login screen. Upon a successful
login, the login page was replaced by the applicaiton home page (in
the same frame). We were using the standard ASP Session to keep track
of the login.
This worked very well in IE and NN *** until *** we added SSL to
protect the login page. To do this, the login page url changed from
http://www.whatever.com/login.asp to
https://www.whatever.com:443/login.asp.
The rest of the site url's remained the same. That broke the login
with NN4. It still worked fine with IE.
In NN4, the browser cookie was apparantly not getting set to record
the session id and thus the login state was lost. I experimented, but
was not able to come up with a simple solution. We ended up replacing
the frameset with a simple login page (no frameset). This allowed the
login to work in NN4 (cookie saved, even with SSL). Once logged in,
the user was redirected to the actual application, which then loaded
the frameset and two frames (help and application).
It looked like the problem was caused by bad vibes between NN4,
frames, SSL and cookies. I never found a smoking gun.
The domain http://example.com is not necessarily https://example.com. A
cookie might be set for both or just one.
For PHP -check wether session.cookie_secure is set (will only be sent
over https) or off (will be sent to both). See also
<http://nl3.php.net/manual/en/function.setcookie.php>, for more detailed
explanation about cookies & their parameters.
--
Rik Wasmus
"Rik" <lu************@hotmail.comschreef in bericht
news:op.twuq52o5qnv3q9@metallium...
On Fri, 10 Aug 2007 18:31:55 +0200, axlq <ax**@spamcop.netwrote:
>In article <46***********************@news.kpnplanet.nl>,
amygdala <no*****@noreply.comwrote:
>>>
"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl ...
Hello all,
<snip>
PS.: I forgot to mention that, before redirecting, I *do* let PHP
perform a
session_write_close().
Why?
A good reason would be several concurrent requests (which also might be
stylesheets, javascript, images, the lot), a website in which there are
'heavy' pages (take a long time to load), and users are likely to have
several windows open.
It is not strictly necessary to use session_write_close(), but a lot of
loading problems in a PHP-heavy site can be avoided with it. And if you're
done with a session, why not? session-closing/database-closing/unsetting
variables are just the kind of thing that might improve performance when
the server is stretched.
F'upped to c.l.php
--
Rik Wasmus
Exactly. To top it off, I implemented this because I assumed that by not
doing so, Opera's session might not be commited before the redirect.
"Rik" <lu************@hotmail.comschreef in bericht
news:op.twuritleqnv3q9@metallium...
On Fri, 10 Aug 2007 18:10:24 +0200, Scott Bryce <sb****@scottbryce.com>
wrote:
>>My application examins $_SERVER[ 'REQUEST_URI' ] to determine which
page to serve.
Why?
Standard practice: single 'point-of-entry' website, serving up pages as
requested in the url. Saves a whole lot of code duplication, allthough it
might decrease performance. Look at it like an index file in the root
examing GET variables and serving up different pages according to the
given values. Only, for more easily remembered urls for humans, and the
kind of urls search-engines like, the url contains a pseudo-path: the
actual path does not exists, but is handled by a script which might be
anywhere.
>If you have stored the URL of the page you want to go to in a cookie,
you should be looking for which page to serve in that cookie.
Never store that kind of a thing in a cookie. Use a session and just a
session cookie, store data in the server-side session.
>Or are you examining $_SERVER[ 'REQUEST_URI' ] to determine what URL to
store in the cookie? Again, why? If I have a PHP script at
example.com/user/login, why doesn't that script know its own URL?
Because the script might not be there? It's just a script, where the
request finally ends up being processed can have very little to do with
the requested URL.
>I may be way off base here, but your approach seems odd to me.
More a difference in approach, but a very normal one.
--
Rik Wasmus
Thanks for answering that one Rik, I couldn't have said it better. :-)
"www.gerardvignes.com" <ge**********@gmail.comschreef in bericht
news:11**********************@i13g2000prf.googlegr oups.com...
>I ran into a login-related problem with NN4 about 6 years ago. This
was with an ASP site. The problem might be similar enough to suggest
somethig helpful:
I used a frameset that consisted of two frames. Everything was from
the same domain. On frame offered help links (that didn't require a
login). The other frame offered a login screen. Upon a successful
login, the login page was replaced by the applicaiton home page (in
the same frame). We were using the standard ASP Session to keep track
of the login.
This worked very well in IE and NN *** until *** we added SSL to
protect the login page. To do this, the login page url changed from
http://www.whatever.com/login.asp to
https://www.whatever.com:443/login.asp.
The rest of the site url's remained the same. That broke the login
with NN4. It still worked fine with IE.
In NN4, the browser cookie was apparantly not getting set to record
the session id and thus the login state was lost. I experimented, but
was not able to come up with a simple solution. We ended up replacing
the frameset with a simple login page (no frameset). This allowed the
login to work in NN4 (cookie saved, even with SSL). Once logged in,
the user was redirected to the actual application, which then loaded
the frameset and two frames (help and application).
It looked like the problem was caused by bad vibes between NN4,
frames, SSL and cookies. I never found a smoking gun. I just changed
the design, which was not great to begin with.
BTW, I stopped using framesets almost 5 years ago. I stopped
supporting NN4 about 4 years ago. Haleluja!
I hope this helps.
Gerard Vignes
"www.gerardvignes.com" <ge**********@gmail.comschreef in bericht
news:11**********************@i13g2000prf.googlegr oups.com...
>I ran into a login-related problem with NN4 about 6 years ago. This
was with an ASP site. The problem might be similar enough to suggest
somethig helpful:
I used a frameset that consisted of two frames. Everything was from
the same domain. On frame offered help links (that didn't require a
login). The other frame offered a login screen. Upon a successful
login, the login page was replaced by the applicaiton home page (in
the same frame). We were using the standard ASP Session to keep track
of the login.
I don't use frames. Like you point out later on: haleluja!! ;-)
This worked very well in IE and NN *** until *** we added SSL to
protect the login page. To do this, the login page url changed from
http://www.whatever.com/login.asp to
https://www.whatever.com:443/login.asp.
The rest of the site url's remained the same. That broke the login
with NN4. It still worked fine with IE.
I don't use SSL either. But thanks for your input anyway.
"Rik" <lu************@hotmail.comschreef in bericht
news:op.twup20qfqnv3q9@metallium...
On Fri, 10 Aug 2007 17:39:55 +0200, amygdala <no*****@noreply.comwrote:
Hello all,
I have posted a similar question in comp.lang.php in the past, but
haven't
had any response to it then. I kinda swept the problem under the rug
since
then. But I would really like to resolve this issue once and for all now.
The problem might be PHP related but since I only develop applications
using
PHP, I'm not a hundred percent sure. Therefor I've taken the liberty to
crosspost to comp.lang.php and alt.www.webmaster. I assume the majority
of
frequent contributors of these groups have dealt with developing session
management also, so I'm kind of hoping your experience in this field
might
resolve this issue.
The problem is the following:
User profiles on the site I'm developing will be publically available
through:
http://www.example.com/profile/view/<username>
A users own profile (when logged in) will be available through:
http://www.example.com/profile/view/ or
http://www.example.com/profile/ (which will redirect to last url)
So when an anonymous user visits one of these last two pages, the
requested
page is stored as a referer in a session and the user is redirected to
http://www.example.com/user/login/
where the user is prompted to login.
On succes it gets redirected to the stored referer url again. A pretty
common procedure I would assume.
This works fine on either IE or Firefox (windows). But in Opera I get
multiple sessions created in the database of which one *does* contains a
userId but Opera redirects back to the login page again.
Only when I manually enter the target url I do get to see the logged in
users profile page.
My application examins $_SERVER[ 'REQUEST_URI' ] to determine which page
to
serve. So, after much testing, I thought it might have something to do
with
Opera's favicon requests.
Hmm, FF & MSIE equally request that damn thing, shouldn't matter I think...
I understand that this might be difficult to interpret without seeing any
code. But since the code is pretty extensive, and I haven't really
narrowed
it down to a particular few lines, I thought I describe the problem
without
code first. Maybe somebody has had similar experiences and knows what the
problem could be.
It's very hard to say. Are you sure you're not actually using the HTTP
REFERER header instead of the one stored in a session? It's pretty
unreliable, and very easy to disabled in Opera, i.e. the server never gets
this header. (Don't know wether it's a standard settings, it's a setting I
use nonetheless, and stored under'quick preferences', so easily accessable
for normal users). Another easily accessed Opera feature is to disable
redirecting. If you're relying on it to transfer the user to another page,
but don't exit your script after the redirect, chances are that in Opera
it might come across as 'the same page again'. So on a redirect, always do
something like:
$target = 'http://www.example.com';
header("Location: $target");
echo 'You're be redirected to '.$target.'. Click <a
href="'.$target.'">here</aif it doesn't work';
exit; //<-----IMPORTANT!
A very easy mistake to make is also differnce in domain (for instance with
or without 'www.' in front of it, cookies that are sent vie https aren't
set by http and vice versa).
If that doesn't work, I'd set up a testpage instead of the normal redirect
to /user/login/, and instead of redirecting, dump the session-id & the
$_SESSION array, and exit. That might give you some insight in what
happens.
It could be a path issue for the cookie also though (as /profile &
/user/login are different, maybe the cookie is set carelessly, and there
are 2 different cookies for the differents paths)... If you use
LiveHTTPHeaders in FF or Fiddler in MSIE, what do you see as Set-Cookie
statements?
If all fails, I'd appreciate a live example, as I'm quite an Opera-fan,
and I can't let this slide :P
f'upped to comp.lang.php BTW.
--
Rik Wasmus
On Fri, 10 Aug 2007 19:14:44 +0200, amygdala <no*****@noreply.comwrote:
<snip identical text>
Yes, that's what I said.... Or am I missing something?
--
Rik Wasmus
First off: sorry about the empty posts people. I pushed accidentally pushed
the send button (twice :-S ).
"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl.. .
>
<snip (very useful info nonetheless :-) >
$target = 'http://www.example.com';
header("Location: $target");
echo 'You're be redirected to '.$target.'. Click <a
href="'.$target.'">here</aif it doesn't work';
exit; //<-----IMPORTANT!
Well whatta you know!! As soon as I put this suggestion of yours after the
header("Location: $target"); it works! And mind you, not necessarily the
exit() part, but the echo part!! How strange is that? I'm loosing all sense
of logic on this one.
Could it be that Opera needs some kind of body content after a redirection
header? Or could it perhaps be that Opera indeed thinks that it should
redirect back to the login page again, since it is redirected to a page,
that redirected to the login page in the first place. lol
In other words, does Opera cache the redirect? In that it has been there
before and remembers: I need to go to the login page, cause nothing has
seemed to change?
Eerrr, that was kind of what you said already wasn't it?
I'm gonna investigate this a little more, cause this doesn't make enough
sense to me yet.
But low and behold, I got it working. Thanks a bunch so far Rik! That made
my day!
"Rik" <lu************@hotmail.comschreef in bericht
news:op.twuuoj2lqnv3q9@metallium...
On Fri, 10 Aug 2007 19:14:44 +0200, amygdala <no*****@noreply.comwrote:
><snip identical text>
Yes, that's what I said.... Or am I missing something?
--
Rik Wasmus
LOL, sorry Rik, I'm a bit tense today, and therefor I accidentily pushed the
send button. No plagiarism intended. :)
On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.comwrote:
First off: sorry about the empty posts people. I pushed accidentally
pushed
the send button (twice :-S ).
"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl.. .
>>
<snip (very useful info nonetheless :-) >
>$target = 'http://www.example.com';
header("Location: $target");
echo 'You're be redirected to '.$target.'. Click <a
href="'.$target.'">here</aif it doesn't work';
exit; //<-----IMPORTANT!
Well whatta you know!! As soon as I put this suggestion of yours after
the
header("Location: $target"); it works! And mind you, not necessarily the
exit() part, but the echo part!! How strange is that? I'm loosing all
sense
of logic on this one.
Could it be that Opera needs some kind of body content after a
redirection
header? Or could it perhaps be that Opera indeed thinks that it should
redirect back to the login page again, since it is redirected to a page,
that redirected to the login page in the first place. lol
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable Automatic
Redirection.
It's enabled by default, but can be disabled for whatever purpose. All the
more reason why a header redirect should be accompanied by some
information one is redirected, and a script should die()/exit() after that.
Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html information
these pages should not be cached.
Possibility 3:
The script isn't terminated after the first header-redirect, continues to
run, and effectively changes the redirect by a second header() call.
Putting an echo directly after it will force the headers to be sent, so
they cannot be replaced anymore, resulting in the first one being the only
one, and thus the one obeyed by the browser. Another example why one
should die()/exit() after a redirect.
<?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
?>
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
?>
--
Rik Wasmus
..oO(amygdala)
>Exactly. To top it off, I implemented this because I assumed that by not
doing so, Opera's session might not be commited before the redirect.
Are you sure you really understood how sessions work? The browser's
only task is to keep the session ID, that's it. The handling of the
session itself - open, read, write, close - is done on the server.
Sessions are browser-independent, there's nothing to commit.
Micha
"Michael Fesser" <ne*****@gmx.deschreef in bericht
news:al********************************@4ax.com...
.oO(amygdala)
>>Exactly. To top it off, I implemented this because I assumed that by not
doing so, Opera's session might not be commited before the redirect.
Are you sure you really understood how sessions work? The browser's
only task is to keep the session ID, that's it. The handling of the
session itself - open, read, write, close - is done on the server.
Sessions are browser-independent, there's nothing to commit.
Micha
Actually I do understand how sessions work, that's why this whole thing
didn't make any sense to me. Why would it work on other browsers, but not on
Opera.
But when all logic fails, I tend to resort to ad-hoc trial and error,
including these kind of things. But Rik's latest post in which he poses some
possibilities, start to make sense. I'm gonna keep the exit() statement
behind the redirects, but I'm still gonna investigate whether my application
indeed is doing something else after the redirect, that it shouldn't.
On Fri, 10 Aug 2007 20:32:45 +0200, Michael Fesser <ne*****@gmx.dewrote:
.oO(amygdala)
>Exactly. To top it off, I implemented this because I assumed that by not
doing so, Opera's session might not be commited before the redirect.
Are you sure you really understood how sessions work? The browser's
only task is to keep the session ID, that's it. The handling of the
session itself - open, read, write, close - is done on the server.
Sessions are browser-independent, there's nothing to commit.
Are you sure you understood how redirecting and sessions works? A script
that has sent a header redirect _can_ continue on and one, doing heavy
work that lasts for an x amount of time. The session will only be closed
automatically when the script ends. If the user is allready requesting the
following page it might slow him down considerably, as the session data
isn't made available untill the end of that renegade script...
So, if a session is no longer needed, it's a wise idea to close is, just
not very necessary in your normal garden variety of PHP scripts.
--
Rik Wasmus
"Rik" <lu************@hotmail.comschreef in bericht
news:op.twuwcnszqnv3q9@metallium...
On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.comwrote:
First off: sorry about the empty posts people. I pushed accidentally
pushed
the send button (twice :-S ).
"amygdala" <no*****@noreply.comschreef in bericht
news:46***********************@news.kpnplanet.nl.. .
>>
<snip (very useful info nonetheless :-) >
>$target = 'http://www.example.com';
header("Location: $target");
echo 'You're be redirected to '.$target.'. Click <a
href="'.$target.'">here</aif it doesn't work';
exit; //<-----IMPORTANT!
Well whatta you know!! As soon as I put this suggestion of yours after
the
header("Location: $target"); it works! And mind you, not necessarily the
exit() part, but the echo part!! How strange is that? I'm loosing all
sense
of logic on this one.
Could it be that Opera needs some kind of body content after a
redirection
header? Or could it perhaps be that Opera indeed thinks that it should
redirect back to the login page again, since it is redirected to a page,
that redirected to the login page in the first place. lol
Somehow, your posts don't get quoted properly by my newsreader (yes, its OE
:-S ), so I'll resort to my own:
<Rik>
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable Automatic
Redirection.
It's enabled by default, but can be disabled for whatever purpose. All the
more reason why a header redirect should be accompanied by some
information one is redirected, and a script should die()/exit() after that.
</Rik>
I know, but it's not an issue.
<Rik>
Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html information
these pages should not be cached.
</Rik>
Yes, that's a reasonable assumption, I will look into that a little more.
<Rik>
Possibility 3:
The script isn't terminated after the first header-redirect, continues to
run, and effectively changes the redirect by a second header() call.
Putting an echo directly after it will force the headers to be sent, so
they cannot be replaced anymore, resulting in the first one being the only
one, and thus the one obeyed by the browser. Another example why one
should die()/exit() after a redirect.
<?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
?>
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
?>
</Rik>
Yes, that makes sense. Although my application should not behave this way,
since it only calls for one function in one controller class per page, I
will look into this a little more. I could very well be overlooking flaws in
my application logics.
Thanks for the great suggestions Rik. You've been very helpful.
Cheers!
amygdala wrote:
Somehow, your posts don't get quoted properly by my newsreader (yes,
its OE :-S ), so I'll resort to my own:
OE Quotefix, a must-have for MSOE users :)
..oO(Rik)
>On Fri, 10 Aug 2007 20:32:45 +0200, Michael Fesser <ne*****@gmx.dewrote:
>Are you sure you really understood how sessions work? The browser's
only task is to keep the session ID, that's it. The handling of the
session itself - open, read, write, close - is done on the server.
Sessions are browser-independent, there's nothing to commit.
Are you sure you understood how redirecting and sessions works?
Yes.
>[...]
So, if a session is no longer needed, it's a wise idea to close is, just
not very necessary in your normal garden variety of PHP scripts.
That's all correct - I was just picking on the "Opera's session might
not be commited before the redirect". Maybe it was just written in a
misleading way, but some problems simply cannot be related to a
particular browser.
And since I'm an Opera fan as well (since v3.60) ... ;-)
Micha
Rik wrote:
amygdala wrote:
>Somehow, your posts don't get quoted properly by my newsreader (yes,
its OE :-S ), so I'll resort to my own:
OE Quotefix, a must-have for MSOE users :)
Thanks for the tip Rik! Installed it. Seems to work like a charm.
Rik wrote:
On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.com>
wrote:
>>
Could it be that Opera needs some kind of body content after a
redirection
header? Or could it perhaps be that Opera indeed thinks that it
should redirect back to the login page again, since it is redirected
to a page, that redirected to the login page in the first place. lol
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable
Automatic Redirection.
It's enabled by default, but can be disabled for whatever purpose.
All the more reason why a header redirect should be accompanied by
some information one is redirected, and a script should die()/exit()
after that.
Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html
information these pages should not be cached.
Possibility 3:
The script isn't terminated after the first header-redirect,
continues to run, and effectively changes the redirect by a second
header() call. Putting an echo directly after it will force the
headers to be sent, so they cannot be replaced anymore, resulting in
the first one being the only one, and thus the one obeyed by the
browser. Another example why one should die()/exit() after a redirect.
<?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
>>
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this is the
last thing done by the application when redirecting. Also, I have added
cache control headers and the likes. But still in Opera the problem persists
if I leave out the echo part you see above between the comments.
So, from my experience it seems as if Opera wants some body content for the
redirect to work and revalidate the url I landed on before I had to log in.
Does anyone have any other clue as to what might be going on here?
Thanks.
amygdala wrote:
Rik wrote:
>On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.com>
wrote:
>>Could it be that Opera needs some kind of body content after a
redirection
header? Or could it perhaps be that Opera indeed thinks that it
should redirect back to the login page again, since it is redirected
to a page, that redirected to the login page in the first place. lol
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable
Automatic Redirection.
It's enabled by default, but can be disabled for whatever purpose.
All the more reason why a header redirect should be accompanied by
some information one is redirected, and a script should die()/exit()
after that.
Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html
information these pages should not be cached.
Possibility 3:
The script isn't terminated after the first header-redirect,
continues to run, and effectively changes the redirect by a second
header() call. Putting an echo directly after it will force the
headers to be sent, so they cannot be replaced anymore, resulting in
the first one being the only one, and thus the one obeyed by the
browser. Another example why one should die()/exit() after a redirect.
<?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this is the
last thing done by the application when redirecting. Also, I have added
cache control headers and the likes. But still in Opera the problem persists
if I leave out the echo part you see above between the comments.
So, from my experience it seems as if Opera wants some body content for the
redirect to work and revalidate the url I landed on before I had to log in.
Does anyone have any other clue as to what might be going on here?
Thanks.
Why are you sending a message they will never see, anyway? Normally a
redirect header has NO text associated with it.
If you have your header set up appropriately, they will be redirected.
All the message might do is screw things up for the browser.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:xq******************************@comcast.com. ..
amygdala wrote:
>>
This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this is the
last thing done by the application when redirecting. Also, I have added
cache control headers and the likes. But still in Opera the problem
persists if I leave out the echo part you see above between the comments.
So, from my experience it seems as if Opera wants some body content for
the redirect to work and revalidate the url I landed on before I had to
log in.
Does anyone have any other clue as to what might be going on here?
Thanks.
Why are you sending a message they will never see, anyway? Normally a
redirect header has NO text associated with it.
If you have your header set up appropriately, they will be redirected. All
the message might do is screw things up for the browser.
Because as Rik has pointed out earlier: some browsers might not obey the
request for a redirect. I predominantly browse using Opera, and in Opera,
you can also *choose* not to be redirected automatically. So having said
that, it makes sense to add an extra option for visitors, when they are not
redirected automatically.
"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:xq******************************@comcast.com. ..
amygdala wrote:
>Rik wrote:
>>On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.com>
wrote:
Could it be that Opera needs some kind of body content after a
redirection
header? Or could it perhaps be that Opera indeed thinks that it
should redirect back to the login page again, since it is redirected
to a page, that redirected to the login page in the first place. lol
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable
Automatic Redirection.
It's enabled by default, but can be disabled for whatever purpose.
All the more reason why a header redirect should be accompanied by
some information one is redirected, and a script should die()/exit()
after that.
Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html
information these pages should not be cached.
Possibility 3:
The script isn't terminated after the first header-redirect,
continues to run, and effectively changes the redirect by a second
header() call. Putting an echo directly after it will force the
headers to be sent, so they cannot be replaced anymore, resulting in
the first one being the only one, and thus the one obeyed by the
browser. Another example why one should die()/exit() after a redirect.
<?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this is the
last thing done by the application when redirecting. Also, I have added
cache control headers and the likes. But still in Opera the problem
persists if I leave out the echo part you see above between the comments.
So, from my experience it seems as if Opera wants some body content for
the redirect to work and revalidate the url I landed on before I had to
log in.
Does anyone have any other clue as to what might be going on here?
Thanks.
Why are you sending a message they will never see, anyway? Normally a
redirect header has NO text associated with it.
If you have your header set up appropriately, they will be redirected. All
the message might do is screw things up for the browser.
PS.: Correct me if I'm wrong, but are my headers not set up properly?
amygdala wrote:
"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:xq******************************@comcast.com. ..
>amygdala wrote:
>>Rik wrote:
On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.com>
wrote:
Could it be that Opera needs some kind of body content after a
redirection
header? Or could it perhaps be that Opera indeed thinks that it
should redirect back to the login page again, since it is redirected
to a page, that redirected to the login page in the first place. lol
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable
Automatic Redirection.
It's enabled by default, but can be disabled for whatever purpose.
All the more reason why a header redirect should be accompanied by
some information one is redirected, and a script should die()/exit()
after that.
Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html
information these pages should not be cached.
Possibility 3:
The script isn't terminated after the first header-redirect,
continues to run, and effectively changes the redirect by a second
header() call. Putting an echo directly after it will force the
headers to be sent, so they cannot be replaced anymore, resulting in
the first one being the only one, and thus the one obeyed by the
browser. Another example why one should die()/exit() after a redirect.
<?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this is the
last thing done by the application when redirecting. Also, I have added
cache control headers and the likes. But still in Opera the problem
persists if I leave out the echo part you see above between the comments.
So, from my experience it seems as if Opera wants some body content for
the redirect to work and revalidate the url I landed on before I had to
log in.
Does anyone have any other clue as to what might be going on here?
Thanks.
Why are you sending a message they will never see, anyway? Normally a
redirect header has NO text associated with it.
If you have your header set up appropriately, they will be redirected. All
the message might do is screw things up for the browser.
PS.: Correct me if I'm wrong, but are my headers not set up properly?
Well, I don't see why you have the session_write_close() - the session
will be closed during exit() processing, anyway.
I also don't see why you have all of the cache control stuff. It's
completely unnecessary in this case.
Keep it simple - the 302 moved and location should be all you need.
And quite frankly, I wouldn't worry about opera users who disable the
redirects. After all - if you did the redirect in the normal way
(.htaccess or httpd.conf file), they wouldn't get a message. So they
must be used to getting blank screens.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Mon, 13 Aug 2007 00:24:18 +0200, amygdala <no*****@noreply.comwrote:
Rik wrote:
>On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.com>
wrote:
>>>
Could it be that Opera needs some kind of body content after a
redirection
header? Or could it perhaps be that Opera indeed thinks that it
should redirect back to the login page again, since it is redirected
to a page, that redirected to the login page in the first place. lol
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable
Automatic Redirection.
It's enabled by default, but can be disabled for whatever purpose.
All the more reason why a header redirect should be accompanied by
some information one is redirected, and a script should die()/exit()
after that.
Possibility 2:
Opera get's the redirect, but still has the page with the same URL in
cache, so decides to use that one. Set some header and/or html
information these pages should not be cached.
Possibility 3:
The script isn't terminated after the first header-redirect,
continues to run, and effectively changes the redirect by a second
header() call. Putting an echo directly after it will force the
headers to be sent, so they cannot be replaced anymore, resulting in
the first one being the only one, and thus the one obeyed by the
browser. Another example why one should die()/exit() after a redirect..
<?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
>>>
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this is the
last thing done by the application when redirecting. Also, I have added
cache control headers and the likes. But still in Opera the problem
persists
if I leave out the echo part you see above between the comments.
So, from my experience it seems as if Opera wants some body content for
the
redirect to work and revalidate the url I landed on before I had to log
in.
Can you set this up somewhere accessable? I'm curious what happens if I
try it in Opera here. Never gave me problems before.
--
Rik Wasmus
Rik wrote:
On Mon, 13 Aug 2007 00:24:18 +0200, amygdala <no*****@noreply.com>
wrote:
>Rik wrote:
>>On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.com>
wrote:
Could it be that Opera needs some kind of body content after a
redirection
header? Or could it perhaps be that Opera indeed thinks that it
should redirect back to the login page again, since it is
redirected to a page, that redirected to the login page in the
first place. lol
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable
Automatic Redirection.
It's enabled by default, but can be disabled for whatever purpose.
All the more reason why a header redirect should be accompanied by
some information one is redirected, and a script should die()/exit()
after that.
Possibility 2:
Opera get's the redirect, but still has the page with the same URL
in cache, so decides to use that one. Set some header and/or html
information these pages should not be cached.
Possibility 3:
The script isn't terminated after the first header-redirect,
continues to run, and effectively changes the redirect by a second
header() call. Putting an echo directly after it will force the
headers to be sent, so they cannot be replaced anymore, resulting in
the first one being the only one, and thus the one obeyed by the
browser. Another example why one should die()/exit() after a
redirect. <?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this
is the last thing done by the application when redirecting. Also, I
have added cache control headers and the likes. But still in Opera
the problem persists
if I leave out the echo part you see above between the comments.
So, from my experience it seems as if Opera wants some body content
for the
redirect to work and revalidate the url I landed on before I had to
log in.
Can you set this up somewhere accessable? I'm curious what happens if
I try it in Opera here. Never gave me problems before.
Hi Rik,
I've set up little example (without the echo part in the redirect method)
which you should be able to access temporarily through: http://amygdala.kicks-ass.net/profile/
(Please let me know if you are not able to access it.)
If all goes well, this will automatically redirect you to the login page.
From there on use:
username: demo
password: demodemo (yes, 8 chars)
In my Opera version (9.02) this brings up the login page again, instead of
redirecting me to http://amygdala.kicks-ass.net/profile/view/demo
When I manually go to the above url after logging in, I do get to see a
var_dump as intended.
Bedankt alvast! (Thank you in advance)
amygdala wrote:
Rik wrote:
>On Mon, 13 Aug 2007 00:24:18 +0200, amygdala <no*****@noreply.com>
>>>
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this
is the last thing done by the application when redirecting. Also, I
have added cache control headers and the likes. But still in Opera
the problem persists
if I leave out the echo part you see above between the comments.
So, from my experience it seems as if Opera wants some body content
for the
redirect to work and revalidate the url I landed on before I had to
log in.
Can you set this up somewhere accessable? I'm curious what happens if
I try it in Opera here. Never gave me problems before.
Hi Rik,
I've set up little example (without the echo part in the redirect
method) which you should be able to access temporarily through:
http://amygdala.kicks-ass.net/profile/
(Please let me know if you are not able to access it.)
If all goes well, this will automatically redirect you to the login
page. From there on use:
username: demo
password: demodemo (yes, 8 chars)
In my Opera version (9.02) this brings up the login page again,
instead of redirecting me to
http://amygdala.kicks-ass.net/profile/view/demo
When I manually go to the above url after logging in, I do get to see
a var_dump as intended.
Bedankt alvast! (Thank you in advance)
Alright, this is strange:
When I access my own example through a proxy (using the above url) it works
as intended. Come to think of it, I do recall reading somewhere that Opera
sometimes has problems with cookies when developing on a localhost server.
Are you aware of any such thing?
On Mon, 13 Aug 2007 11:53:58 +0200, amygdala <no*****@noreply.comwrote:
>>This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT' );
header( 'Cache-Control: no-store, no-cache, must-revalidate' );
header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this
is the last thing done by the application when redirecting. Also, I
have added cache control headers and the likes. But still in Opera
the problem persists
if I leave out the echo part you see above between the comments.
Can you set this up somewhere accessable? I'm curious what happens if
I try it in Opera here. Never gave me problems before.
I've set up little example (without the echo part in the redirect method)
which you should be able to access temporarily through:
http://amygdala.kicks-ass.net/profile/
(Please let me know if you are not able to access it.)
HTTP/1.x 302 Moved Temporarily
....
Set-Cookie: PHPSESSID=jhiktdcd4efk720iqahhhquokhm24ill; path=/
Set-Cookie: PHPSESSID=upgdihd7gbiqnen492advkiu0c0piv4v; path=/
Location: http://127.0.0.1/user/login/
....
I haven't set up your site on my local box, so no, it's not working :).
If all goes well, this will automatically redirect you to the login page.
OK, on another domain perhaps, so that might get some freaky results in
cookies/sessions. When I manually go to http://amygdala.kicks-ass.net/user/login/ I can see the form, and when
logging in I'm again redirected to 127.0.0.1 (/profile/view/), which is
offcourse not found. So, manually going to http://amygdala.kicks-ass.net/profile/view/, I get redirected without a
hitch to http://amygdala.kicks-ass.net/profile/view/demo, and I see a
var_dump of a User object, seems OK to me.
Redirecting seems fine here (Opera 9.23), only to the wrong domain... I
offcourse continuously get the 'page not found' for the 127.0.0.1
redirects, but I am redirected nonetheless. What if you use the
$_SERVER['HTTP_HOST'] in the url to which you redirect?
Bedankt alvast! (Thank you in advance)
Geen probleem :-)
--
Rik Wasmus
On Mon, 13 Aug 2007 12:04:54 +0200, amygdala <no*****@noreply.comwrote:
Alright, this is strange:
When I access my own example through a proxy (using the above url) it
works
as intended. Come to think of it, I do recall reading somewhere that
Opera
sometimes has problems with cookies when developing on a localhost
server.
Are you aware of any such thing?
Only domain conflicts if they aren't set properly :P
--
Rik Wasmus
Jerry Stuckle wrote:
amygdala wrote:
>"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:xq******************************@comcast.com ...
>>amygdala wrote:
Rik wrote:
On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.com>
wrote:
>Could it be that Opera needs some kind of body content after a
>redirection
>header? Or could it perhaps be that Opera indeed thinks that it
>should redirect back to the login page again, since it is
>redirected to a page, that redirected to the login page in the
>first place. lol
Possiblity 1:
Opera -Tools -preferences -Advanced -Network -Enable
Automatic Redirection.
>
It's enabled by default, but can be disabled for whatever purpose.
All the more reason why a header redirect should be accompanied by
some information one is redirected, and a script should
die()/exit() after that.
Possibility 2:
Opera get's the redirect, but still has the page with the same
URL in cache, so decides to use that one. Set some header and/or
html information these pages should not be cached.
>
Possibility 3:
The script isn't terminated after the first header-redirect,
continues to run, and effectively changes the redirect by a second
header() call. Putting an echo directly after it will force the
headers to be sent, so they cannot be replaced anymore, resulting
in the first one being the only one, and thus the one obeyed by
the browser. Another example why one should die()/exit() after a
redirect. <?php
//this will offcourse end in /second.html
header('Location: /first.html');
header('Location: /second.html');
<?php
//this will end in /first.html
header('Location: /first.html');
flush();
header('Location: /second.html');
This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT'
); header( 'Cache-Control: no-store, no-cache, must-revalidate'
); header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this
is the last thing done by the application when redirecting. Also,
I have added cache control headers and the likes. But still in
Opera the problem persists if I leave out the echo part you see
above between the comments. So, from my experience it seems as if Opera
wants some body
content for the redirect to work and revalidate the url I landed
on before I had to log in.
Does anyone have any other clue as to what might be going on here?
Thanks.
Why are you sending a message they will never see, anyway? Normally a
redirect header has NO text associated with it.
If you have your header set up appropriately, they will be
redirected. All the message might do is screw things up for the
browser.
PS.: Correct me if I'm wrong, but are my headers not set up properly?
Well, I don't see why you have the session_write_close() - the session
will be closed during exit() processing, anyway.
I also don't see why you have all of the cache control stuff. It's
completely unnecessary in this case.
Keep it simple - the 302 moved and location should be all you need.
I would think so to, but if you have read the entire thread you would see
that I am having trouble with getting it to work as expected in Opera. So I
thought I'ld use every option at my disposal to make sure the redirect and
the session saving works as expected.
But now, it looks like the Opera problem only exists when accessing the
application local on localhost. (See my reply to Rik)
Rik wrote:
On Mon, 13 Aug 2007 11:53:58 +0200, amygdala <no*****@noreply.com>
wrote:
>>>This thing still has me puzzled. What I did is the following:
My SessionHandler class has the following method:
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT'
); header( 'Cache-Control: no-store, no-cache, must-revalidate'
); header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
Since I have now included the exit() statement I am sure that this
is the last thing done by the application when redirecting. Also, I
have added cache control headers and the likes. But still in Opera
the problem persists
if I leave out the echo part you see above between the comments.
Can you set this up somewhere accessable? I'm curious what happens
if I try it in Opera here. Never gave me problems before.
I've set up little example (without the echo part in the redirect
method) which you should be able to access temporarily through:
http://amygdala.kicks-ass.net/profile/
(Please let me know if you are not able to access it.)
HTTP/1.x 302 Moved Temporarily
...
Set-Cookie: PHPSESSID=jhiktdcd4efk720iqahhhquokhm24ill; path=/
Set-Cookie: PHPSESSID=upgdihd7gbiqnen492advkiu0c0piv4v; path=/
Location: http://127.0.0.1/user/login/
...
I haven't set up your site on my local box, so no, it's not working
:).
Errrr, sorry about that Rik, forgot to change
define( 'ROOT_PATH', 'http://' . $_SERVER['SERVER_NAME'] );
to
define( 'ROOT_PATH', 'http://amygdala.kicks-ass.net' );
>If all goes well, this will automatically redirect you to the login
page.
OK, on another domain perhaps, so that might get some freaky results
in cookies/sessions. When I manually go to
http://amygdala.kicks-ass.net/user/login/ I can see the form, and when
logging in I'm again redirected to 127.0.0.1 (/profile/view/), which
is offcourse not found. So, manually going to
http://amygdala.kicks-ass.net/profile/view/, I get redirected without
a hitch to http://amygdala.kicks-ass.net/profile/view/demo, and I see
a var_dump of a User object, seems OK to me.
But then this should be OK indeed.
Redirecting seems fine here (Opera 9.23), only to the wrong domain...
I offcourse continuously get the 'page not found' for the 127.0.0.1
redirects, but I am redirected nonetheless. What if you use the
$_SERVER['HTTP_HOST'] in the url to which you redirect?
>Bedankt alvast! (Thank you in advance)
Geen probleem :-)
Thanks again!
On Mon, 13 Aug 2007 12:33:20 +0200, amygdala <no*****@noreply.comwrote:
Rik wrote:
>>I've set up little example (without the echo part in the redirect
method) which you should be able to access temporarily through:
http://amygdala.kicks-ass.net/profile/
(Please let me know if you are not able to access it.)
HTTP/1.x 302 Moved Temporarily
...
Set-Cookie: PHPSESSID=jhiktdcd4efk720iqahhhquokhm24ill; path=/
Set-Cookie: PHPSESSID=upgdihd7gbiqnen492advkiu0c0piv4v; path=/
Location: http://127.0.0.1/user/login/
...
I haven't set up your site on my local box, so no, it's not working
:).
Errrr, sorry about that Rik, forgot to change
define( 'ROOT_PATH', 'http://' . $_SERVER['SERVER_NAME'] );
to
define( 'ROOT_PATH', 'http://amygdala.kicks-ass.net' );
Ah, and everything works like a charm :P (allthough the double set-cookie
PHPSESSID should be taken care of).
So, possibly a server/domain issue somewhere when developing locally,
works OK on the net though.
--
Rik Wasmus
Rik wrote:
On Mon, 13 Aug 2007 12:04:54 +0200, amygdala <no*****@noreply.com>
wrote:
>Alright, this is strange:
When I access my own example through a proxy (using the above url) it
works
as intended. Come to think of it, I do recall reading somewhere that
Opera
sometimes has problems with cookies when developing on a localhost
server.
Are you aware of any such thing?
Only domain conflicts if they aren't set properly :P
Hehe, no this should not be the cause of this, since I just set up this
temporarily subdomain (through DynDNS.com) pointing to my local webserver
today. Usually I only develop locally, through 127.0.0.1.
But anyway, thanks for the help Rik.
Rik wrote:
On Mon, 13 Aug 2007 12:33:20 +0200, amygdala <no*****@noreply.com>
wrote:
>Rik wrote:
>>>I've set up little example (without the echo part in the redirect
method) which you should be able to access temporarily through:
http://amygdala.kicks-ass.net/profile/
(Please let me know if you are not able to access it.)
HTTP/1.x 302 Moved Temporarily
...
Set-Cookie: PHPSESSID=jhiktdcd4efk720iqahhhquokhm24ill; path=/
Set-Cookie: PHPSESSID=upgdihd7gbiqnen492advkiu0c0piv4v; path=/
Location: http://127.0.0.1/user/login/
...
I haven't set up your site on my local box, so no, it's not working
:).
Errrr, sorry about that Rik, forgot to change
define( 'ROOT_PATH', 'http://' . $_SERVER['SERVER_NAME'] );
to
define( 'ROOT_PATH', 'http://amygdala.kicks-ass.net' );
Ah, and everything works like a charm :P (allthough the double
set-cookie PHPSESSID should be taken care of).
Well, this double Set-Cookie should indeed not be happening. Although I do
use session_regenerate_id() (paranoid mode ;) on every request. But I don't
suspect that that causes two set-cookie's in one response.
What kind of tool are you using to analyse/view this information if you
don't mind telling me? Is there any HTTPLiveHeader thingy for Opera I am not
aware of?
Thanks in advance
So, possibly a server/domain issue somewhere when developing locally,
works OK on the net though.
Looks like that is the case, yes.
amygdala wrote:
Jerry Stuckle wrote:
>amygdala wrote:
>>"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:xq******************************@comcast.co m...
amygdala wrote:
Rik wrote:
>On Fri, 10 Aug 2007 20:07:03 +0200, amygdala <no*****@noreply.com>
>wrote:
>>Could it be that Opera needs some kind of body content after a
>>redirection
>>header? Or could it perhaps be that Opera indeed thinks that it
>>should redirect back to the login page again, since it is
>>redirected to a page, that redirected to the login page in the
>>first place. lol
>Possiblity 1:
>Opera -Tools -preferences -Advanced -Network -Enable
>Automatic Redirection.
>>
>It's enabled by default, but can be disabled for whatever purpose.
>All the more reason why a header redirect should be accompanied by
>some information one is redirected, and a script should
>die()/exit() after that.
>Possibility 2:
>Opera get's the redirect, but still has the page with the same
>URL in cache, so decides to use that one. Set some header and/or
>html information these pages should not be cached.
>>
>Possibility 3:
>The script isn't terminated after the first header-redirect,
>continues to run, and effectively changes the redirect by a second
>header() call. Putting an echo directly after it will force the
>headers to be sent, so they cannot be replaced anymore, resulting
>in the first one being the only one, and thus the one obeyed by
>the browser. Another example why one should die()/exit() after a
>redirect. <?php
>//this will offcourse end in /second.html
>header('Location: /first.html');
>header('Location: /second.html');
><?php
>//this will end in /first.html
>header('Location: /first.html');
>flush();
>header('Location: /second.html');
This thing still has me puzzled. What I did is the following:
>
My SessionHandler class has the following method:
>
public function redirect( $url )
{
session_write_close();
header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT'
); header( 'Cache-Control: no-store, no-cache, must-revalidate'
); header( 'Cache-Control: post-check=0, pre-check=0', false );
header( 'Pragma: no-cache' );
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url );
// this part between the comments is important
echo 'You\'re being redirected to ' . $url . ' .
Click <a href="' . $url. '">here</aif it doesn\'t work';
// end important part
exit(); // exit doesn't really make a difference for Opera
}
>
Since I have now included the exit() statement I am sure that this
is the last thing done by the application when redirecting. Also,
I have added cache control headers and the likes. But still in
Opera the problem persists if I leave out the echo part you see
above between the comments. So, from my experience it seems as if Opera
wants some body
content for the redirect to work and revalidate the url I landed
on before I had to log in.
>
Does anyone have any other clue as to what might be going on here?
>
Thanks.
Why are you sending a message they will never see, anyway? Normally a
redirect header has NO text associated with it.
If you have your header set up appropriately, they will be
redirected. All the message might do is screw things up for the
browser.
PS.: Correct me if I'm wrong, but are my headers not set up properly?
Well, I don't see why you have the session_write_close() - the session
will be closed during exit() processing, anyway.
I also don't see why you have all of the cache control stuff. It's
completely unnecessary in this case.
Keep it simple - the 302 moved and location should be all you need.
I would think so to, but if you have read the entire thread you would see
that I am having trouble with getting it to work as expected in Opera. So I
thought I'ld use every option at my disposal to make sure the redirect and
the session saving works as expected.
But now, it looks like the Opera problem only exists when accessing the
application local on localhost. (See my reply to Rik)
Yes, I did read the entire thread. That's why I said it. Don't use
options just because they're there. Use them because there is a need
for them.
For instance - the cache control would have no effect on them, and using
them just complicates matters.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Jerry Stuckle wrote:
amygdala wrote:
>Jerry Stuckle wrote:
>>amygdala wrote:
"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:xq******************************@comcast.c om...
amygdala wrote:
>Rik wrote:
>>On Fri, 10 Aug 2007 20:07:03 +0200, amygdala
>><no*****@noreply.comwrote:
>>>Could it be that Opera needs some kind of body content after a
>>>redirection
>>>header? Or could it perhaps be that Opera indeed thinks that it
>>>should redirect back to the login page again, since it is
>>>redirected to a page, that redirected to the login page in the
>>>first place. lol
>>Possiblity 1:
>>Opera -Tools -preferences -Advanced -Network -Enable
>>Automatic Redirection.
>>>
>>It's enabled by default, but can be disabled for whatever
>>purpose. All the more reason why a header redirect should be
>>accompanied by some information one is redirected, and a script
>>should die()/exit() after that.
>>Possibility 2:
>>Opera get's the redirect, but still has the page with the same
>>URL in cache, so decides to use that one. Set some header and/or
>>html information these pages should not be cached.
>>>
>>Possibility 3:
>>The script isn't terminated after the first header-redirect,
>>continues to run, and effectively changes the redirect by a
>>second header() call. Putting an echo directly after it will
>>force the headers to be sent, so they cannot be replaced
>>anymore, resulting in the first one being the only one, and
>>thus the one obeyed by the browser. Another example why one
>>should die()/exit() after a redirect. <?php
>>//this will offcourse end in /second.html
>>header('Location: /first.html');
>>header('Location: /second.html');
>><?php
>>//this will end in /first.html
>>header('Location: /first.html');
>>flush();
>>header('Location: /second.html');
>This thing still has me puzzled. What I did is the following:
>>
>My SessionHandler class has the following method:
>>
> public function redirect( $url )
> {
> session_write_close();
> header( 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' );
> header( 'Last-Modified: ' . gmdate( 'D, d M Y H:i:s' ) . ' GMT'
> ); header( 'Cache-Control: no-store, no-cache, must-revalidate'
> ); header( 'Cache-Control: post-check=0, pre-check=0', false );
> header( 'Pragma: no-cache' );
> header( 'HTTP/1.0 302 Moved Temporarily' );
> header( 'Location: ' . $url );
> // this part between the comments is important
> echo 'You\'re being redirected to ' . $url . ' .
> Click <a href="' . $url. '">here</aif it doesn\'t work';
> // end important part
> exit(); // exit doesn't really make a difference for Opera
> }
>>
>Since I have now included the exit() statement I am sure that
>this is the last thing done by the application when redirecting.
>Also,
>I have added cache control headers and the likes. But still in
>Opera the problem persists if I leave out the echo part you see
>above between the comments. So, from my experience it seems as
>if Opera wants some body
>content for the redirect to work and revalidate the url I landed
>on before I had to log in.
>>
>Does anyone have any other clue as to what might be going on
>here? Thanks.
Why are you sending a message they will never see, anyway?
Normally a redirect header has NO text associated with it.
>
If you have your header set up appropriately, they will be
redirected. All the message might do is screw things up for the
browser.
PS.: Correct me if I'm wrong, but are my headers not set up
properly?
Well, I don't see why you have the session_write_close() - the
session will be closed during exit() processing, anyway.
I also don't see why you have all of the cache control stuff. It's
completely unnecessary in this case.
Keep it simple - the 302 moved and location should be all you need.
I would think so to, but if you have read the entire thread you
would see that I am having trouble with getting it to work as
expected in Opera. So I thought I'ld use every option at my disposal
to make sure the redirect and the session saving works as expected.
But now, it looks like the Opera problem only exists when accessing
the application local on localhost. (See my reply to Rik)
Yes, I did read the entire thread. That's why I said it. Don't use
options just because they're there. Use them because there is a need
for them.
I don't use them because they are there, I use them because every other
option in my mind was exhausted, so I thought I'ld give it a try and one by
one remove a header to see where the problem would arise in Opera. But I
started off putting them all in there for debugging purposes.
session_write_close(): because with Opera I was getting multiple session
entries in my DB. And I know this doesn't make sense logically (I can tell
client processes from server processes) and I know an exit() statement
should suffice, yada yada yada.
Cache-Control and other cache headers: because I thought Opera might somehow
not revalidate the initial redirected url.
But to tell you the truth, I don't see how any cache headers could harm:
header( 'HTTP/1.0 302 Moved Temporarily' );
header( 'Location: ' . $url ); This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Bartosz Wegrzyn |
last post by:
I need help with sessions.
I createt set of web site for nav with authorization.
first I go into main.php which looks like this:
<?php
//common functions
include_once '../login/common.php';...
|
by: Guy Hocking |
last post by:
Hi there,
I am having trouble with an ASP login that uses sessions to control access
to certain pages. However the sessions are not being carried accross upon
using response.redirect.
I realise...
|
by: Edgardo Sepulveda |
last post by:
Hi, one question, is there a limit on the numbers of sessions that a
client can have? i dont know why but suddently, as i handle a lot of the
user information with sessions, and also have added a...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
