addressbar?

[Ron Eggler]

Hi,

is it possible to read out the Addressbar with javascript or do I have to
use php for it?
Thank you!

 

[gobera]

Do you want to read the current URL? Use document.location

 

[Ron Eggler]

Do you want to read the current URL? Use document.location

yup, hm, document.location.... does return the actual domain? like
www.google.com/index.htm?

 

[Grant Wagner]

yup, hm, document.location.... does return the actual domain? like
www.google.com/index.htm?

It's window.location.href (or simply location.href). And why not try it:

<script type="text/javascript">
alert(window.location.href);
</script>

More about the Location object: <url:
http://docs.sun.com/source/816-6408-10/location.htm />

 

[Thomas 'PointedEars' Lahn]

It's window.location.href (or simply location.href).

Or even more simple `location'


PointedEars

 

[Grant Wagner]

Or even more simple `location'

I don't like assigning a String value to a Location object, no matter
what the underlying implementation does for me and I think it was a
mistake to implement it that way. It interferes with trying to teach
proper OO concepts, and leads to statements like "JavaScript supports
associative arrays" because the concept of objects, properties and
methods becomes hazy and meaningless.

For the sake of 5 characters, location.href self-documents what is
occurring and I'll continue to both use and recommend it.

 

[Thomas 'PointedEars' Lahn]

I don't like assigning a String value to a Location object, no matter
what the underlying implementation does for me and I think it was a
mistake to implement it that way.

Well, using `location' instead of `location.href' workarounds the
Same Origin Policy by design, so you really should consider it.

It interferes with trying to teach proper OO concepts,

On the contrary. It teaches that an object has a value and still more
properties.

and leads to statements like "JavaScript supports associative arrays"
because the concept of objects, properties and methods becomes hazy
and meaningless.

I think if people want to have misconceptions, there is no way talking
them out of them.

For the sake of 5 characters,

.... and another lookup operation probably reducing efficiency ...

location.href self-documents what is occurring and I'll continue to
both use and recommend it.

PointedEars

 

[Randy Webb]

:




Well, using `location' instead of `location.href' workarounds the
Same Origin Policy by design, so you really should consider it.

No, if it lets you get around SOP then its a security flaw and should
*not* be considered.

On the contrary. It teaches that an object has a value and still more
properties.

No it doesn't. It teaches people bad habits by not learning what is
underlying and relying on the browser to handle it.

I think if people want to have misconceptions, there is no way talking
them out of them.

No, but, you *can* keep from propogating mis-understandings.

.... and another lookup operation probably reducing efficiency ...

That lookup has to happen either way. It's probably quicker to use .href
because then the browser doesn't have to guess what to do with the
string, the author has already told it.

 

[Thomas 'PointedEars' Lahn]

No, if it lets you get around SOP then its a security flaw and should
*not* be considered.

Rubbish. That behaviour is by design, as you could have read in the
Netscape JavaScript Reference. But then your other statements clearly
mark you as incompetent in the matter.


PointedEars

 

[Randy Webb]

Randy Webb wrote:




Rubbish. That behaviour is by design, as you could have read in the
Netscape JavaScript Reference.

So now you are referring to a documentation that is where?

And which NS browser does it Reference?

And, if *any* browser lets a page have access to the location property
from a different origin that is a security flaw. Thats not
documentation, thats plain common sense.

 

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

And, if *any* browser lets a page have access to the location
property from a different origin that is a security flaw.
Thats not documentation, thats plain common sense.

I think the point is that you don't need access to the - location -
object in order to assign to a - location - property of a window
object, only to the window object itself, while assigning to -
location.href - would require access to the location object (location
must be resolved as an object prior to assigning a property to it).

In a frame buster script a test along the lines of - if(self == top) -
demonstrates that you can have read access to the - top - object
(cross-domain scripts may resolve - top - as an object), even if it is a
different frame, from a different domain. It would be a security issue
if you could read the location object (say, calling its toString method
(even implicitly) to find the URL). It would also be a security issue if
you could read from - top.document - and any number of other properties
of - top-. But there is no security issue in assigning values to (at
least a few) properties of - top - as that would only replace the
original with something that you already know about, and render the
original completely inaccessible.

Obviously the issue is very much restricted to frame busting type
scripts.

Richard.

 

[Grant Wagner]

On the contrary. It teaches that an object has a value and still more
properties.

Except it the Location object doesn't have a value.

The implementation described by Netscape's documentation <url:
http://docs.sun.com/source/816-6408-10/location.htm />:

If you assign a string to the location property of an object, JavaScript
creates a location object and assigns that string to its href property.
For example, the following two statements are equivalent and set the URL
of the current window to the Netscape home page:

window.location.href="http://home.netscape.com/"window.location="http://home.netscape.com/"So
in at least one browser:

window.location = 'url';

is:

var s = 'url';
window.location = new Location();
window.location.href = s;

I don't see how hiding this fact helps anyone.

window.location contains a reference to a Location object, the Location
object has no value, it has properties. If you assign a string to the
window.location property containing the Location object reference, the
browser waves it's hands, says a magical incarnation and assigns that
string to the href property of a Location object referred to by
window.location.

This all has the madness of default properties in VisualBasic.

... and another lookup operation probably reducing efficiency ...

1) the inefficiency is negligible
2) if the description in the Netscape documentation is anywhere close to
accurate, assigning a string to the location property of the window
object actually involves _more_ work.

 

[Jim Ley]

window.location contains a reference to a Location object, the Location
object has no value, it has properties. If you assign a string to the
window.location property containing the Location object reference, the
browser waves it's hands, says a magical incarnation and assigns that
string to the href property of a Location object referred to by
window.location.

Which is hardly unusual behaviour in programming languages.

int i=0;
Integer int=i;

is expanded exactly the same in Java 1.5 for example.


Jim.

 

[Grant Wagner]

Which is hardly unusual behaviour in programming languages.

int i=0;
Integer int=i;

is expanded exactly the same in Java 1.5 for example.

Agreed, but in languages that support such "shortcuts" the behaviour is
consistent and documented.

Although it could be argued that location = 'url'; is documented, it
isn't consistent with the rest of the language. Then again, Location is
a host object, so I suppose it's allowed to play however it wants.

In the end it doesn't much matter what I think, location = 'url'; works
and I have to be prepared to read and understand code that makes use of
that syntax.