 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / May 2005addressbar?
Hi, is it possible to read out the Addressbar with javascript or do I have to use php for it? Thank you!  SignatureroN www.rideon.ch Do you want to read the current URL? Use document.location > 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? SignatureroN www.rideon.ch >> 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? 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 /> SignatureGrant Wagner <gwagner@agricoreunited.com> comp.lang.javascript FAQ - http://jibbering.com/faq "Grant Wagner" schrieb: > "Ron Eggler" <NOspam@hotmail.com> wrote [...]: > >> 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? > > It's window.location.href (or simply location.href). Or even more simple `location' :) PointedEars > "Grant Wagner" schrieb: > [quoted text clipped - 6 lines] > > 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. SignatureGrant Wagner <gwagner@agricoreunited.com> comp.lang.javascript FAQ - http://jibbering.com/faq "Grant Wagner" schrieb: > "Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote [...] > > "Grant Wagner" schrieb: [quoted text clipped - 4 lines] > 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 > "Grant Wagner" schrieb: > [quoted text clipped - 12 lines] > 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. >>It interferes with trying to teach proper OO concepts, > > 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. >>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. No, but, you *can* keep from propogating mis-understandings. >>For the sake of 5 characters, > > .... 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. SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly >> "Grant Wagner" schrieb: >>> "Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote [...] [quoted text clipped - 9 lines] > 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 >>>"Grant Wagner" schrieb: >>> [quoted text clipped - 18 lines] > 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. SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly <snip> >>>>Well, using `location' instead of `location.href' >>>> workarounds the Same Origin Policy by design, >>>>so you really should consider it. <snip> > 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" schrieb: > >> It interferes with trying to teach proper OO concepts, > > 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. >> For the sake of 5 characters, > > ... 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. SignatureGrant Wagner <gwagner@agricoreunited.com> comp.lang.javascript FAQ - http://jibbering.com/faq >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. >>window.location contains a reference to a Location object, the >>Location [quoted text clipped - 10 lines] > > 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. SignatureGrant Wagner <gwagner@agricoreunited.com> comp.lang.javascript FAQ - http://jibbering.com/faq |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.