Is there any way to randomly access the URLs in Javascript's History object in Safari? I'm writing an extension where I need to, on a specifically-formatted page request, capture the URL of the previous page. From what I've been able to find, the History object definition is non-standard across browsers. Safari only seems to expose its length property and the standard methods that actually move within the history. Where other implementations expose current, previous and next properties, I can't see anything that tells me Safari does the same.
I've also tried document.referrer, but that doesn't appear to get populated in this case.
I just need to display the previously accessed URL on a given page. Is there any other way to access that URL?
Thanks.
You can't really do this, at least in any white-hat way. By design. You can step the user backward and forward, but you can't see the URLs.
Less scrupulous script-writers have of course taken this as a challenge. I believe the closest they've come is to dynamically write a bunch of known comparison links to the page, and then inspect them to see if they're showing in the "visited" color state. Perhaps if you're working in a closed and predictable environment (an intranet app?), with a known set of URLs, this might be a valid approach for you. Then again, in such an environment you could deal with this on the server side with session management.
Related
So this question is less of a problem I have and more of a question about how I should go about implementing something.
lets imagine for example I have a User and a Resource, and a User can have multiple Resource but a Resource can have only 1 User. How should you go about creating api endpoints for interacting with this data?
should it be something like
// POST /api/users/resource (to create a resource)
or something like
// POST /api/resource
thats just one example, but there is a lot of questions like that, that come to mind when im thinking about this.
it would be nice if someone who knew what is the right approach (or just a good approach) would give an example on how you would structure api endpoints with relational data like this.
any and all help is appreciated thanks!
I would go with the latter one. The reason for doing that would be the endpoint /api/resource does not bind us to create resources with respect to the user. Down the line in future, we could create resources for Supplier (a hypothetical example). Thus having better flexibility and not needing to change the endpoint for Supplier.
Part of the point of REST is that the server's implementation of a resource is hidden behind the uniform interface. In a sense, you aren't supposed to be able to tell from the resource identifiers whether or not you are dealing with "relational data".
Which is freeing (because you get to design the best possible resource model for your needs); but also leads to analysis-paralysis, because the lack of constraints means that you have many options to choose from.
POST /api/users/resource
POST /api/resource
Both of these are fine. The machines are perfectly happy to carry either message. If you wanted to implement an API that supported both options, that would also be OK.
So how do we choose?
The answer to this really has two parts. The first relates to understanding resources, which are really just generalizations of documents. When we ask for a document on the web, one of the things that can happen is that the document can be cached. If we are sending a message that we expect to modify a document, then we probably want caches to invalidated previously cached versions of the document.
And the primary key used to identified cached documents? The URI.
In the case where we are sending a message to a server to save a new document, and we expect the server to choose its own identifier for its copy of the new document, then one logical choice of request target is the resource that is the index of documents on the server.
This is why you will normally see CreateItem operations implemented as POST handlers on a Collection resource - if the item is successfully added, we want to invalidate previously cached responses to GET /collection.
Do you have to do it that way? No, you do not - it's a "trade off"; you weigh the costs and benefits of the options, and choose one. If you wanted to instead have a separate resource for the CreateItem operation, that's OK too.
The second part of the answer relates to the URI - having decided which document should be handling the requests, what spelling should we use for the identifier of that document.
And, once again, the machines don't care very much. It needs to be RFC 3986 compliant, and you'll save yourself a lot of bother if you choose a spelling that works well with URI Templates, but that still leaves you with a lot of freedom.
The usual answer? Think about the people, who they are, and what they are doing when they are looking at a URI. You've got visitors looking at a browser history, and writers trying to document the API, and operators reading through access logs trying to understand the underlying traffic patterns. Pick a spelling that's going to be helpful to the people you care about.
I am writing a simple clickbot in JavaScript to perform repetitive tasks on a 3rd party website. It just sets input values, calls the click() method of buttons and maybe I'll have it navigate to other URLs of the same website. I initially used Firefox but got the same behaviour with Internet Explorer.
I use plain JS so far and as long as I paste in every command by myself everything works fine but here's the problem: Any time a new page is loaded (including when JS clicks a submit button) I lose all vars and functions I defined. Note that I use the web console as opposed to a <script> tag that obyiousely would be dropped when a new DOM is loaded.
Honestly, I do not entirely understand why this happens. I looked at JavaScript scope and the documentation of window.location and document.location. This site even mentioned that "In a web browser, global variables are deleted when you close the browser window (or tab), but remain available to new pages loaded into the same window." (cf. here, but that's not the point here)
I thought it might be because strict mode might be enabled by default but that would have raised an error for name = "value" instead of silently interpreting it as a local variable.
According to this answer, any var declared outside any methods should be globals that are properties of window. Changing another propertie of window (e.g. location) should not affect them - as far as my reasoning goes - but even when assigning properties myself, they disappear when I load another page.
I suppose it could be worked around if I wrote my own website that has the site I need as an iFrame so the page my script runs on would not actually be changed. But still this is strange. Can anyone explain this behaviour? Is there another (easy) way around it?
[Edit1] Thanks to same-origine policy my proposed workaround using an own website and iframe does not work. Since the whole point of my clickbot is to be started once and click through all pages on it's own, a way to carry on data (i.e. strings including JSON) is answering this question but does not solve my problem.
[Edit2] For future visitors: After recent edits, the accepted answer does provide all information I needed. Greasemonkey is the way to go if you can use addons but the combination of bookmarklets and sessionStorage stil allow for a decent bot that performes all steps between two reloads with just one user input. Another (ugly bot possibly more powerfull) approach is to open the target website and use document.body.innerHTML and the iframe workaround. That way you bypass the same-origine policy and can build your own website as needed and still access the target website.
Regarding the lifetime of a variable this SO question goes into detail, but variables don't persist across reloads.
If you're staying within the same domain (e.g. everything happens at https://example.com, so https://example.com/page1, https://example.com/page2, etc.) then you can use cookies or local storage to keep track of values.
You can't keep track of functions easily with local storage or cookies.
Cookies and local storage are not available across domains.
I would use local storage as that is easier to interface with. So instead of:
var someVar = 'hello';
Write
localStorage['someVar'] = 'hello';
Then to use the variable:
console.log(localStorage['someVar']);
Local storage has a maximum size of 10MB. Probably enough for any automation script.
If you want to persist functions across page reloads, you should use something like grease monkey to store your user scripts.
in a programming challenge I recently took part in I had to use the window.name property to store / manipulate data. I found out that, when you change this property, it persists through page refreshes (although not when opening a new page with the same URL).
The only information I could find was that this is known and even used by some frameworks as data storage, but I would be interested in the why (as in why is window.name persistent? Any historical reasons?) and the how (which rules are there of when the window.name is kept between page changes and when it is discarded?).
Apparently, my Google-fu is not strong enough to find the answers to these questions (there is not even a mention of it on the MDN page!) so I hope that maybe you could help me.
My understanding of it is that the window object is persistent throughout the lifetime of a tab, and represents the window that is loading different HTML documents.
Each tab contains its own window object, which is why even when you navigate to/from different pages the window object is persistent, whereas if you check on a different tab the window.name will be different.
When opening different html pages, most of them do not override the window.name property, and it is completely optional. If nothing else is manipulating it, it will be what you leave it as. Most pages only touch on manipulating the window.document itself.
Named windows are used as link targets, for one:
some page
The link will open in a new window once, and in the same window if it still exists on subsequent clicks, with the window’s name being how it’s targeted.
The second argument of window.open is also a window name.
window.open('example.html', 'some_page');
You can try it out in your browser across unrelated websites; in one tab’s console, set window.name = 'test'; and in the other, use window.open('https://example.com/', 'test');. (You may have to let it through a pop-up blocker.) The unrelated tab should navigate to https://example.com/.
I've never worked with the HTML5 onpopstate/pushState Method. However I'm building (or have already built) a website where scrolling through the page changes the hash in the addressbar to the ID of the currently shown element in the viewport. So I have a kind of browserhistory and Deep Linking on my single-page-layout.
I'm still doing this with setting the top.location.hash and using the hashchange() function. Now I've come across this new HTML5 popstate/onPushstate Method and thought this would be intersting …
First of: What are the benefits of using this popstate/onPushState Methods? Is it better using this than the classical way of using top.location.hash? Is the performance better?
If so, is there a way to query or find out if the current browser is supporting this Methods? So I can use those methods for modern browsers and fallback on the old way in older browsers.
Is that possible? If yes, than how?
What are the benefits of using this popstate/onPushState Methods?
You get real URLs that don't depend on JavaScript to function.
If so, is there a way to query or find out if the current browser is supporting this Methods?
if (history && history.pushState)
… or just use a compatibility library
You can do more things with the html5 history api.
You can replace the current item in the history or create a new one. With the hashtag solution you can only add new ones.
When you create or replace a history entry you can also change the url and pass an javascript object that will be returned to you in popstate which can contain any data.
A very good example for a good use of this api is github (http://www.github.com). At start they sent the full page once, after that they change the page and url to match the new page that you would load on initial request. (this means that refresh works very nicely)
if you want to test for history support you can do this like this:
if (history && history.pushState)
I want to pass javascript object from one page to other page so anyone can tell me how to do it?
Is that possible to do so using jQuery?
Few ways
Server side postback
Have a POST form on your page and save your serialized object inside a hidden input then post it to the other page. You will be able to process that data on the server and most likely put it back somehow into the page. Either as javascript object or anything else.
Client side URL examination
Make a GET request to your other page by attaching your serialized object to URL as:
http://www.app.com/otherpage.xyz?MyObject=SerializedData
That other page can then easily parse its URL and deserialize data using Javascript.
What's in a window.name = local cross-page session
This is a special technique that's also used in a special javascript library that exposes window.name as a dictionary, so you can save many different objects into it and use it as local cross-page-session. It has some size limitations that may affect you, but check the linked page for that and test your browsers.
HTML5 local storage
HTML5 has the ability of local storage that you can use exactly for these purposes. But using it heavily depends on your browser requirements. Modern browsers support it though and data can be restored even after restarting browsers or computers...
Cookies
You can always use cookies but you may run into their limitations. These days cookies are not the best choice even though they have the ability to preserve data even longer than current window session.
Javascript object serialization
You will of course have to use some sort of a (de)serializer on your client side in some of the upper cases. Deserializers are rather easy to find (jQuery already includes a great function $.getJSON()) and are most likely part of your current javascript library already (not to even mention eval()).
But for object to JSON string serialization I'd recommend json2.js library that's also recommended by John Resig. This library uses in-browser implemented JSON (de)serialization features if they exist or uses it's own implementation when they don't. Hence recommendation.
That is only possible if the pages exist at the same time, and one page is opened from the other so that you have a reference to the other pages windows object.
If you navigate from one page to another, they don't exist at the same time, so you can't communicate like that. You would have to serialise the object into a string that you can send along in the request, for example sending JSON in the query string.
There are different ways of persisting data, like in the query string, post data, cookies, window name or HTML5 local storage, but all those methods can only persist string values, not Javascript objects.
This is possible to do, and you have a couple of options.
Local Storage
Can be added/eddited/removed at any stage and accessed across a domain. (doesn't work natively in ie6 and ie7 however there are work arounds for that)
The Window Object
I would put a massive cavet around this not being the best solution, it's not at all secure, so only use it for things that don't need to be kept private. window.name = { "json" : "object"} which is then available in the following page in the window.name property.
I believe that the only way to pass a javascript object from one page to another is to serialize it into string and pass it in url. For example if you have object
var temp = { id: 1, value: 'test' }
you may want to use JSON-js to serialize it and pass it in for example http://mysite.com/?data=serialization. Then after you load the page you need to deserialize it via for example $.parseJSON().
If your application uses sessions, you could serialize it (as per other answers) then POST it to the server where it is stored in a session variable. In the next page, you retrieve it from the session variable.
In Javascript, normally all variables only exist in a scope that is unique to that page load. They don't persist between different pages if there is a new page load.
The exceptions to this are
Cookies.
Local storage.
Cookies are truly cross-browser but are extremely limited in terms of size. You shouldn't expect to be able to store more than 4kB of cookies for a page reliably; in fact you probably shouldn't be using any more than 1kB. Cookie data slows down the loading of every page and other request, so it should be used sparingly.
There are various types of local storage available to Javascript, but the only practical cross-browser implementation of this is HTML5 webstorage which is implemented in all modern browsers (IE8+, FF, Chrome, Safari, etc), but is notably not implemented in IE6 or IE7, if that matters.
Both these approaches store a value in the user's browser which can be made to be persistent so that it can be written to and read from by pages from the same site, even between page views (and even, often, between browser sessions or computer reboots).
I wrote a library some time ago, that can store most js objects to localstorage. For example instances of your prototype classes, with references to other objects, self references included. Bare in mind that IE support is lackluster.