473,324 Members | 2,541 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

List Fails on some computers - www missing in url

Hello,

Can someone tell me why on some computers the following list will fail . I
have a user reported that some of the links in the below list will fail and
some will work. The ones that fail will have the www missing in the URL. For
example when this particular computer will have the link as
http://mysite.com/entry_page.php instead of
http://www.mysite.com/entry_page.php

This is only happening on 1 computer as far as I know and I sure can't
explain it. Hope you can!

This you very much!

Vic

<div id="navcontainer">
<ul id="navlist">
<li><a href="judges.php" >Judges</a></li>
<li><a href="entry_page.php" >Enter Horse</a></li>
<li><a href="fileupload.php?do=upload">Show Schedule</a></li>
<li><a href="classes_listdetail.php?do=<?php echo $_SESSION['ShowID'];
?>">Class List</a></li>
<li><a href="showresults.php">Show Results</a></li>
<li><a href="myhorses.php">My Horses</a></li>
<li><a href="removeshow.php?remove=<?php echo $_SESSION['ShowID'];
?>">Remove Show</a></li>
</ul>
</div>
Mar 3 '07 #1
18 2426
Rik
On Sat, 03 Mar 2007 20:50:02 +0100, Vic Spainhower <vi*@showsec.comwrote:
Hello,

Can someone tell me why on some computers the following list will fail .
I
have a user reported that some of the links in the below list will fail
and
some will work. The ones that fail will have the www missing in the URL.
For
example when this particular computer will have the link as
http://mysite.com/entry_page.php instead of
http://www.mysite.com/entry_page.php

This is only happening on 1 computer as far as I know and I sure can't
explain it. Hope you can!
Euhm, this is a HTML question. But i'd bet the user entered the site on
http://example.com instead of http://www.example.com. If one of the 2
doesn't work, I'd set a webserver-level redirect to the right domain.
--
Rik Wasmus
Mar 3 '07 #2
On Mar 3, 8:50 pm, "Vic Spainhower" <v...@showsec.comwrote:
Hello,

Can someone tell me why on some computers the following list will fail . I
have a user reported that some of the links in the below list will fail and
some will work. The ones that fail will have the www missing in the URL. For
example when this particular computer will have the link ashttp://mysite.com/entry_page.php instead ofhttp://www.mysite.com/entry_page.php

This is only happening on 1 computer as far as I know and I sure can't
explain it. Hope you can!

This you very much!

Vic

<div id="navcontainer">
<ul id="navlist">
<li><a href="judges.php" >Judges</a></li>
<li><a href="entry_page.php" >Enter Horse</a></li>
<li><a href="fileupload.php?do=upload">Show Schedule</a></li>
<li><a href="classes_listdetail.php?do=<?php echo $_SESSION['ShowID'];
?>">Class List</a></li>
<li><a href="showresults.php">Show Results</a></li>
<li><a href="myhorses.php">My Horses</a></li>
<li><a href="removeshow.php?remove=<?php echo $_SESSION['ShowID'];
?>">Remove Show</a></li>
</ul>
</div>

On Mar 3, 8:50 pm, "Vic Spainhower" <v...@showsec.comwrote:
Hello,

Can someone tell me why on some computers the following list will fail . I
have a user reported that some of the links in the below list will fail and
some will work. The ones that fail will have the www missing in the URL. For
example when this particular computer will have the link ashttp://mysite.com/entry_page.php instead ofhttp://www.mysite.com/entry_page.php

This is only happening on 1 computer as far as I know and I sure can't
explain it. Hope you can!

This you very much!

Vic

<div id="navcontainer">
<ul id="navlist">
<li><a href="judges.php" >Judges</a></li>
<li><a href="entry_page.php" >Enter Horse</a></li>
<li><a href="fileupload.php?do=upload">Show Schedule</a></li>
<li><a href="classes_listdetail.php?do=<?php echo $_SESSION['ShowID'];
?>">Class List</a></li>
<li><a href="showresults.php">Show Results</a></li>
<li><a href="myhorses.php">My Horses</a></li>
<li><a href="removeshow.php?remove=<?php echo $_SESSION['ShowID'];
?>">Remove Show</a></li>
</ul>
</div>
Maybe the SESSION data is lost on 2nd domain :

If on http://mysite.com/page.php you do:
session_start();
$_SESSION['data']='something';

on http://www.mysite.com/page.php:
session_start();
$_SESSION['data'] might be nothing...

because cookie is different for
http://www.mysite.com and http://mysite.com

Mar 4 '07 #3
In article <11**********************@p10g2000cwp.googlegroups .com>,
my*****@yahoo.ca says...
>
because cookie is different for
http://www.mysite.com and http://mysite.com
It shouldn't be it's the same domain just addressed differently.
If PHP does that it's a bug that should be reported as critical.
Paul
--------------------
"It's better to burn out, than to fade away."
Highlander.
Mar 5 '07 #4
paul wrote:
In article <11**********************@p10g2000cwp.googlegroups .com>,
my*****@yahoo.ca says...
>because cookie is different for
http://www.mysite.com and http://mysite.com

It shouldn't be it's the same domain just addressed differently.
If PHP does that it's a bug that should be reported as critical.
Paul
--------------------
"It's better to burn out, than to fade away."
Highlander.
Paul,

It's not PHP. It's how the browser and HTTP protocol work.

www.example.com is not the same as example.com. It may or may not be on
the same server. And if it were on a different server, there could be a
security exposure.

So the browser doesn't send a cookie stored by example.com to
www.example.com (or vice versa). There is nothing special about the www
identifier other than it is a convention.

The same would be true if you had xyz.example.com or
thisisanothersubdomain.example.com.

P.S. When using example url's, use example.com, example.org, etc.
That's what they were set up for.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 5 '07 #5
In article <R4******************************@comcast.com>,
js*******@attglobal.net says...
www.example.com is not the same as example.com. It may or may not be on
the same server. And if it were on a different server, there could be a
security exposure.
It is always the same domain. What server hardware is used is irrelevant.
An HTML request for www.thisdoman.com will always produce the same
resulting connection as thisdomain.com. The fact it may be on different
hardware is totally irrelevant.

Sessions identify domains not hardware.
Organisations register domain names not the hardware they run them on
or the server types they provide. And conventions exist because thats how
things work.

I say again. If that is indeed what happens then its a critical bug in
PHP and people all over the world will be scratching their heads
wondering why their secured by password connections frequently fail.

If this does happen I guess PHP could create 2 sessions for the same user
connection and that would be a security hazard as data that should exist
would simply vanish.

That is your real security exposure and it would indeed be caused by PHP
not HTML.

Paul
Mar 5 '07 #6
>www.example.com is not the same as example.com. It may or may not be on
>the same server. And if it were on a different server, there could be a
security exposure.
It is always the same domain. What server hardware is used is irrelevant.
An HTML request for www.thisdoman.com will always produce the same
resulting connection as thisdomain.com.
False. And there is nothing in DNS that even requires both or neither
of www.example.com and example.com to exist and have an A record.

Apache also has features that allow the content served to depend on the
host name presented, and it's perfectly possible to have www.example.com
and example.com have different content. VERY often, they DO have
different content: one just sends a redirect to the other domain,
which is not the same thing.

>The fact it may be on different
hardware is totally irrelevant.
The fact that it may have totally different content IS relevant.

>Sessions identify domains not hardware.
Have you noticed that www.microsoft.com and support.microsoft.com
have different content? They are in the same domain.
>Organisations register domain names not the hardware they run them on
or the server types they provide. And conventions exist because thats how
things work.
Conventions about www being the web server are just that, conventions.
You cannot depend on no one violating them. Everyone drives on the right
hand side of the road, right? It's a convention. So there can't possibly
be anyone driving on the left ha....<splat>!
>I say again. If that is indeed what happens then its a critical bug in
PHP and people all over the world will be scratching their heads
wondering why their secured by password connections frequently fail.
Why would a "secured by password" connection randomly switch between
two domains?

I will also comment that if you think that this is a bug in PHP, you've
got a problem, because THERE IS NO CHANGE YOU CAN MAKE IN PHP TO FIX IT.
You have to change people's browsers.
>If this does happen I guess PHP could create 2 sessions for the same user
connection and that would be a security hazard as data that should exist
would simply vanish.
PHP has no way of realizing that it should not create 2 sessions for the
same user.
>That is your real security exposure and it would indeed be caused by PHP
not HTML.
Mar 6 '07 #7
paul wrote:
In article <R4******************************@comcast.com>,
js*******@attglobal.net says...
>www.example.com is not the same as example.com. It may or may not be on
the same server. And if it were on a different server, there could be a
security exposure.

It is always the same domain. What server hardware is used is irrelevant.
An HTML request for www.thisdoman.com will always produce the same
resulting connection as thisdomain.com. The fact it may be on different
hardware is totally irrelevant.

Sessions identify domains not hardware.
Organisations register domain names not the hardware they run them on
or the server types they provide. And conventions exist because thats how
things work.

I say again. If that is indeed what happens then its a critical bug in
PHP and people all over the world will be scratching their heads
wondering why their secured by password connections frequently fail.

If this does happen I guess PHP could create 2 sessions for the same user
connection and that would be a security hazard as data that should exist
would simply vanish.

That is your real security exposure and it would indeed be caused by PHP
not HTML.

Paul

Paul,

That's what you don't get. www.example.com is NOT the same as example.com.

Whether or not it creates the same connection is immaterial. That is
below the HTTP protocol.

Yes, organizations register the domain. But www.example.com is NOT the
same as example.com which is not the same as ftp.example.com which is
not the same as xyz.example.com.

The HTTP protocol sees each of the above as a different server. And
browsers do not send cookies from one server to another.

Creating two sessions is not a security hazard - it is required by the
protocol. If you have any bitches, it's with the HTTP protocol, not PHP.

But good luck - every language (i.e. VBScript, Perl, Python, Java, etc.)
using the HTTP protocol and every browser (i.e. IE, Opera, Firefox,
Mozilla, etc.) works the same way. You need to change the protocol, not
complain about PHP.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 6 '07 #8
>>www.example.com is not the same as example.com. It may or may not be on
>>the same server. And if it were on a different server, there could be a
security exposure.
I placed the following re-direct in index.php and it goes into a re-direct
loop. This would tell me they are in fact the same domain and a re-direct
will not solve the problem.

<meta http-equiv="REFRESH" content="2; URL=http://www.mysite.com">

Vic
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Jv******************************@comcast.com. ..
paul wrote:
>In article <R4******************************@comcast.com>,
js*******@attglobal.net says...
>>www.example.com is not the same as example.com. It may or may not be on
the same server. And if it were on a different server, there could be a
security exposure.

It is always the same domain. What server hardware is used is irrelevant.
An HTML request for www.thisdoman.com will always produce the same
resulting connection as thisdomain.com. The fact it may be on different
hardware is totally irrelevant.

Sessions identify domains not hardware.
Organisations register domain names not the hardware they run them on
or the server types they provide. And conventions exist because thats how
things work.

I say again. If that is indeed what happens then its a critical bug in
PHP and people all over the world will be scratching their heads
wondering why their secured by password connections frequently fail.

If this does happen I guess PHP could create 2 sessions for the same user
connection and that would be a security hazard as data that should exist
would simply vanish.

That is your real security exposure and it would indeed be caused by PHP
not HTML. Paul

Paul,

That's what you don't get. www.example.com is NOT the same as
example.com.

Whether or not it creates the same connection is immaterial. That is
below the HTTP protocol.

Yes, organizations register the domain. But www.example.com is NOT the
same as example.com which is not the same as ftp.example.com which is not
the same as xyz.example.com.

The HTTP protocol sees each of the above as a different server. And
browsers do not send cookies from one server to another.

Creating two sessions is not a security hazard - it is required by the
protocol. If you have any bitches, it's with the HTTP protocol, not PHP.

But good luck - every language (i.e. VBScript, Perl, Python, Java, etc.)
using the HTTP protocol and every browser (i.e. IE, Opera, Firefox,
Mozilla, etc.) works the same way. You need to change the protocol, not
complain about PHP.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Mar 6 '07 #9
Vic Spainhower wrote:
>>>www.example.com is not the same as example.com. It may or may not be on
the same server. And if it were on a different server, there could be a
security exposure.
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:Jv******************************@comcast.com. ..
>paul wrote:
>>In article <R4******************************@comcast.com>,
js*******@attglobal.net says...
www.example.com is not the same as example.com. It may or may not be on
the same server. And if it were on a different server, there could be a
security exposure.

It is always the same domain. What server hardware is used is irrelevant.
An HTML request for www.thisdoman.com will always produce the same
resulting connection as thisdomain.com. The fact it may be on different
hardware is totally irrelevant.

Sessions identify domains not hardware.
Organisations register domain names not the hardware they run them on
or the server types they provide. And conventions exist because thats how
things work.

I say again. If that is indeed what happens then its a critical bug in
PHP and people all over the world will be scratching their heads
wondering why their secured by password connections frequently fail.

If this does happen I guess PHP could create 2 sessions for the same user
connection and that would be a security hazard as data that should exist
would simply vanish.

That is your real security exposure and it would indeed be caused by PHP
not HTML. Paul
Paul,

That's what you don't get. www.example.com is NOT the same as
example.com.

Whether or not it creates the same connection is immaterial. That is
below the HTTP protocol.

Yes, organizations register the domain. But www.example.com is NOT the
same as example.com which is not the same as ftp.example.com which is not
the same as xyz.example.com.

The HTTP protocol sees each of the above as a different server. And
browsers do not send cookies from one server to another.

Creating two sessions is not a security hazard - it is required by the
protocol. If you have any bitches, it's with the HTTP protocol, not PHP.

But good luck - every language (i.e. VBScript, Perl, Python, Java, etc.)
using the HTTP protocol and every browser (i.e. IE, Opera, Firefox,
Mozilla, etc.) works the same way. You need to change the protocol, not
complain about PHP.


I placed the following re-direct in index.php and it goes into a
re-direct
loop. This would tell me they are in fact the same domain and a
re-direct
will not solve the problem.

<meta http-equiv="REFRESH" content="2;
URL=http://www.mysite.com">
>
Vic

(Top posting fixed)
It doesn't say anything about them being the same domain. All it says
is the same server is handling both requests.

You could be on www.example.com and redirect to www.example.org. If
they are the same host, you will also get the loop.

You will even get the same loop if example.com redirects to example.org
and example.org redirects to example.com (when they are on different
servers).

P.S. Please don't top post.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 6 '07 #10
Rik
Vic Spainhower <vi*@showsec.comwrote:
>>>www.example.com is not the same as example.com. It may or may not be
on
the same server. And if it were on a different server, there could
be a
security exposure.

It is always the same domain. What server hardware is used is
irrelevant.
An HTML request for www.thisdoman.com will always produce the same
resulting connection as thisdomain.com.
No it will not, and I'm amazed you dare to state such a huge error as an
absolute truth.
I placed the following re-direct in index.php and it goes into a
re-direct
loop. This would tell me they are in fact the same domain and a re-direct
will not solve the problem.

<meta http-equiv="REFRESH" content="2;
URL=http://www.mysite.com">
You have to check wether they're at the right domain offcourse. If it
resolves to the same directory, I'd either make _all_ links relative, or
I'd use mod_rewrite in apache for this:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ %{SERVER_PROTOCOL}://www.%{HTTP_HOST}/$1 [R,QSA]

--
Rik Wasmus
Posted on Usenet: any site claiming this as original content or me as an
contributing member is stealing content.
Ask Smart Questions: http://tinyurl.com/anel
Mar 6 '07 #11

You have to check wether they're at the right domain offcourse. If it
resolves to the same directory, I'd either make _all_ links relative, or
I'd use mod_rewrite in apache for this:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ %{SERVER_PROTOCOL}://www.%{HTTP_HOST}/$1 [R,QSA]

--
Rik Wasmus

Thanks Rik,

This seems to have worked for me. However, I have to check with the user who
was having the problem and see if it works on his machine. Appreciate your
help.

if ($_SERVER["HTTP_HOST"] == 'mysite.com')
echo '<meta http-equiv="REFRESH" content="0; URL=http://www.mysite.com">';
?>

Vic

Posted on Usenet: any site claiming this as original content or me as an
contributing member is stealing content.
Ask Smart Questions: http://tinyurl.com/anel
Mar 6 '07 #12
On Mar 6, 12:30 am, paul<paul.mast...@dummy.comwrote:
If this does happen I guess PHP could create 2 sessions for the same user
That's exactly what happened to me just 2 weeks ago. I spent a whole
day debugging to find that I had a session cookie for example.com/
p.php and another for www.example.com/p.php. The browser of course
kept serving up the same page so it took me a long time to notice that
some links had www and others not. It was a Joomla site btw, and in
the admin panel the @@@@@@@ admin didn't put www in one of the links.


Mar 6 '07 #13
Rik
Vic Spainhower <vi*@showsec.comwrote:
This seems to have worked for me. However, I have to check with the user
who
was having the problem and see if it works on his machine. Appreciate
your
help.
if ($_SERVER["HTTP_HOST"] == 'mysite.com')
echo '<meta http-equiv="REFRESH" content="0;
URL=http://www.mysite.com">';
?>
When given the chance, alwyas opt for a HTTP header redirect instead of
meta and/or javascript redirect. They're much more reliable.

PS: Please don't quote signatures. Your reply looks rather odd in real
newsreaders.

--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Mar 6 '07 #14
Vic Spainhower wrote:
>>>www.example.com is not the same as example.com. It may or may not be on
the same server. And if it were on a different server, there could be a
security exposure.

I placed the following re-direct in index.php and it goes into a re-direct
loop. This would tell me they are in fact the same domain and a re-direct
will not solve the problem.

<meta http-equiv="REFRESH" content="2; URL=http://www.mysite.com">
To Vic and Paul:

You do realize that 'mysite.com' *is* a real domain register to someone
and 'thisdomain.com' is not register at this moment, but is a valid
domain name. In case you haven't figured it out yet, if you need to use
a domain name for your example you're are supposed to use:

example.com
example.net
example.org

and not use a valid domain that could be registered to someone...

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Mar 7 '07 #15
In article <cO******************************@comcast.com>,
js*******@attglobal.net says...
>
That's what you don't get. www.example.com is NOT the same as
example.com.
Yes it is - for any domain issued - denying that simple fact allows PHP
to continue to ignore a security critical bug. A fact easily tested.
Try going to any site with either and you get the same result unless
its a very old domain. Nobody is now issued with a domain where those
2 addresses result in a different IP address. Nobody.
Its exactly the same - as you yourself so rightly
pointed out and thereby made the point yourself-

the WWW is just a convention that means nothing in relation to the
domain.

However the rest of that string defines the domain.

PHP using sessions constitutes a massive security hazard until this
serious bug is fixed.

Mar 8 '07 #16
>That's what you don't get. www.example.com is NOT the same as
>example.com.

Yes it is - for any domain issued - denying that simple fact allows PHP
to continue to ignore a security critical bug. A fact easily tested.
Why is this a security bug, whereas a user being able to erase his
session cookie at any time and start a new session ISN'T just as
bad a security bug? Oh, yes, the user can also fiddle with the
HOSTS file so example.com and www.example.com point at different
places *for his browser* even if they don't for the rest of the
world.

There are a number of things PHP does not deal with. Power failures,
for one thing. A lot of the reason PHP does not deal with power
failures is that there's nothing it can do about them.

The same applies to sessions. If the browser doesn't send a session
cookie because the hostname is different, PHP has no way to know
if it was part of a session. There's no way for PHP to fix this,
short of a mind-reading protocol. Even that wouldn't work unless
browsers were made intelligent enough to have a mind to read.
>Try going to any site with either and you get the same result unless
its a very old domain. Nobody is now issued with a domain where those
2 addresses result in a different IP address. Nobody.
A domain is not *issued* with any DNS records at all, other than
NS records pointing at the DNS hosting company the domain owner is
using. And remember, DNS has been around for a long time before
anyone even thought up www. The DNS records for a domain are up
to the owner of that domain, although this is often done with the
advice of techs for the company that hosts the DNS for the domain
(web hosting companies, usually) who are usually NOT the same as
the companies issuing domains (Network Solutions, Register.com,
GoDaddy, etc.)
Did you know that there are domains without any web site at all?
Some just use it for mail. Or for giving host names to all their
dial-modems and customer DSL lines.
>Its exactly the same - as you yourself so rightly
pointed out and thereby made the point yourself-

the WWW is just a convention that means nothing in relation to the
domain.

However the rest of that string defines the domain.
It is common for there to be multiple web sites in the same domain
with totally different content. Check out www.microsoft.com and
support.microsoft.com.
>PHP using sessions constitutes a massive security hazard until this
serious bug is fixed.
The same so-called "bug" exists even if you uninstall PHP.

Mar 9 '07 #17
Rik
Gordon Burditt <go***********@burditt.orgwrote:
>>That's what you don't get. www.example.com is NOT the same as
example.com.

Yes it is - for any domain issued
OMFG! Back to school. Don't pretend to now anything anymore.
>denying that simple fact allows PHP
to continue to ignore a security critical bug. A fact easily tested.
So you're the reason so many bug report sites are cluttered, out of date,
and seriously slow.
The same applies to sessions. If the browser doesn't send a session
cookie because the hostname is different, PHP has no way to know
if it was part of a session. There's no way for PHP to fix this,
short of a mind-reading protocol. Even that wouldn't work unless
browsers were made intelligent enough to have a mind to read.
Time to implement DWIM() :-)
http://ars.userfriendly.org/cartoons/?id=20011121
>Try going to any site with either and you get the same result unless
its a very old domain. Nobody is now issued with a domain where those
2 addresses result in a different IP address. Nobody.
What 'issued'? Configured you mean? Ad how much research have you done on
the subject? Hardly anything i'd imagine.

Also, often there are a lot of websites running on the same IP. Should the
browser sent out cookies to totally unrelated sites that just happen to
have the same hoster?
>the WWW is just a convention that means nothing in relation to the
domain.
It is a subdomain. Get it?
>PHP using sessions constitutes a massive security hazard until this
serious bug is fixed.

The same so-called "bug" exists even if you uninstall PHP.
And I wouldn't call it a security hazard if users can't login. 't Would be
more of a hazard if they can log in with wrong credentials. And the moment
my browser is sending out cookies to different domains then those that set
them it the moment I trash it for another one.
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Mar 9 '07 #18
tr***@yourself.com wrote:
In article <cO******************************@comcast.com>,
js*******@attglobal.net says...
>>>That's what you don't get. www.example.com is NOT the same as
example.com.

Yes it is - for any domain issued - denying that simple fact allows PHP
to continue to ignore a security critical bug. A fact easily tested.
Try going to any site with either and you get the same result unless
its a very old domain. Nobody is now issued with a domain where those
2 addresses result in a different IP address. Nobody.
Its exactly the same - as you yourself so rightly
pointed out and thereby made the point yourself-

the WWW is just a convention that means nothing in relation to the
domain.

However the rest of that string defines the domain.

PHP using sessions constitutes a massive security hazard until this
serious bug is fixed.

NO, NO, NO!!!

www.example.com IS NOT THE SAME as example.com. And neither is the same
as ftp.example.com, mail.example.com, gopher.example.com,
news.example.com, ad nauseum.

"www" is a CONVENTION to identify a website for a particular domain. It
MAY OR MAY NOT be the same as example.com.

I can EASILY (and have) set up domain registrations such that
example.com IS NOT the same as www.example.com. And neither is the same
as any of the others listed above.

www.example.com MAY point to example.com . BUT IT DOES NOT HAVE TO!
That is the key here. And to allow ANY cookie for example.com to be
sent to ANY SUBDOMAIN (or host, as the case may be) for example.com,
such as www.example.com, mail.example.com and so on, is a HUGE security
risk.

THIS IS NOT A PHP PROBLEM! It's not the internet works! That includes
ALL browsers - IE, Mozilla, Firefox, Opera and the rest. If your
"theory" is correct, then EVERYONE ELSE IS WRONG. And I don't think so.

Before you start talking about how you think it should be - you need to
find out how things really works.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 9 '07 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Lars Bonnesen | last post by:
A Win2k, SQL2k machine with SP2 that only just now has been updated to SP3a fails in different ways. Among other things, when I now start Enterprise Manager, I get a message saying "rebbrui.rll" is...
3
by: Steve | last post by:
Hi all How would i get a list of all Active Computers on a network? All I need are the computer names. Kind Regards, Steve.
0
by: Joao Correia via DotNetMonster.com | last post by:
Hello all, This is my first post in this forum My problem is: I have to list all domains, computers, users and groups here...we have some domains, plus 20.000 computers (with NT/4, XP and...
0
by: Selden McCabe | last post by:
I have a VB6 application running on a number of computers at a school. These all have Microsoft Office (and also Outlook) installed. They are using an Exchange server. This app uses the...
2
by: Jesper | last post by:
Hi, I wrote and compiled back in 2003 a console C++ application in visual studio 6. Now, I've made some minor changes to some the program, converted the solution to Visual Studio .net 2005. On...
4
by: Ian Richardson | last post by:
Hi, The function I've put together below is a rough idea to extend a SELECT list, starting from: <body> <form name="bambam"> <select id="fred"> <option value="1">1</option> <option...
12
by: joshd | last post by:
Hello, Im sorry if this question has been asked before, but I did search before posting and couldnt find an answer to my problem. I have two classes each with corresponding linked lists, list1...
4
by: JB | last post by:
I am trying to get a list of all the active computers running on my domain. I'm writing some remote management style software with WMI, which works fine when i know the computer name, but i just...
6
by: belias | last post by:
So...here we go. I'm having an issue with one computer on a network not being able to ping other computers by name. I've spent the last day searching similar issues and I've tried all the steps...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.