The question is probably easily misunderstood, so I'll go into more detail:
I am trying to automate a task in a certain (very outdated) browser-based idle game that is written in PHP in order to polish my portfolio with a little more variated projects.
I used DevTools to reverse most of the requests and wrote a small C# Request wrapper to test them. I can get most of the actions I want to work, using the respective ajax get requests and the correct cookies/headers - not really part of the problem.
Example:
Attacking an enemy:
https://somebrowsergame.com/game/ajax.php?mod=location&submod=attack&location=3&stage=2&premium=0&sh=****mysessionhash****
Making a GET request to this URI with the correct headers and cookies, I can perform the in-game action programmatically and successfully from my C# console application and see that the fight has taken place when visiting the site in the browser.
The problem:
When monitoring all requests after clicking the "attack" button, via DevTools, even with preserve logs enabled, I don't see any redirects or way of determining how my browser gets told where to navigate to.
Findings
I found out that the button calls a javascript function attack() in its onClick event and tried debugging the javascript in DevTools in order to find out where somethign happens (such as setting document.href or smth), but when Debugging I ran into a seemingly infinite loop of setInterval handler and setTimeout handler in the call stack.
I also cleared the Network tab after the onClick event (and after the ajax request which I could find during Debugging) but the only request/response I got was the document GET request for the final page, no request telling my browser which site to navigate to.
Monitoring requests
The request made to initiate the action (via button click on website or ajax GET request as outlined above)
The document response / site navigated to
What I want to know is how my browser got told which site to navigate too, as the request URI for the document request (getting the html of the target page) has a parameter generated on the server side (logId)
I have also used "All" request types in DevTools, as well as negative filters when monitoring requests but never was I able to see how my browser knows which page to navigate to. I tried with source breakpoints at "beforeunload", tried inspecting the javascript source connected to the onclick event of the button (which didnt give me anything, as the js is minified and barely readable - i am not even sure if the navigation is done via window.target.href) and googled this question in all possible wordings which lead me nowhere
I am not too versed in web development, but I am sure my browser has to be told where to navigate to in some fashion after clicking that button?
Related
I've got a communication between client and server. The process is simple:
I'm making an AJAX POST request to a controller which generates a pdf in the file system
On success of the above request a form GET request is made to get the pdf back and the standard browser "save or open" dialog box opens up
The reason I'm having a two step process is because I need to have a progress bar while the pdf is being generated.
The reason of the second request being a form submit rather than part of the AJAX request is because I can't get the standard browser "save or open" dialog box.
The problem with this approach is that IE7 & IE8 pop up a their annoying notification bar notifying the user that the it is dangerous to download the content and I don't want that.
So:
I need the progress bar.
If I go for an AJAX request only I need a way to pop up the "save or open" dialog box.
If I go for the a form GET submit I need a way of knowing when the file has been generated in order to stop the progress bar, something like a shared flag between server and client.
Any help appreciated.
One possible (a little of an anti pattern) workaround is this, but it's not a great design probably
However I've seen this (and admit I did this) before, and except some guilt, it did the trick
user clicks a link that goes to the servlet that generates the PDF and will just wait (timeout settings should be applied) until it's ready... (Content-Disposition header etc...) just like a regular download
The servlet will report progress on a shared session variable while generating the PDF
an AJAX call to the server will read from the session variable the progress and show to the user
when the PDF is done, the browser will just download it (request timeout risk perhaps)
The main issue here is using the request thread as a worker thread and blocking it, which may give this answer a couple of downvotes...
I'm not that familiar with Message Driven Beans but this is another, probably better solution.
I'm trying to figure out right configuration for cross origin AJAX call in Safari extension injected script.
My configuration in Extension Builder:
Extension Website Access: All
Include Secure Pages: true
Whitelist: -
Blacklist: -
My goal is to get something like Chromes "permissions": "http://mysite.com/*", and be able to pull user configuration from web service.
note: JSONP drops warning, so I would prefer to avoid it.
Any luck with this? I'm having the same problems. Same setup works fine in the Chrome extension, but hitting Access-Contol-Allow-Origin when trying to do it in Safari Extension.
FIXED - UPDATE:
Hey, I figured out what the problem is. So, it looks like you need to do the cross-domain ajax via the background page. What I end up doing is determining all the requests I need to make in the injected script, then message pass the requests to the background page. The background page listens for messages from the injected script, makes the appropriate ajax calls, and then sends the results via a message to the injected script. The injected script is then listening for messages from the background page, once it gets the message(s) with the ajax results, it takes the appropriate action in the page that's being viewed.
So I am concerned with
webdriver.navigate().back();
in particular. AFter reading How does the Back button in a web browser work?
it made me think of how can I make sure back button behaves as expected?
Here's different ways of having "back" navigation. How would you go about detecting which approach to use? Listen to whether POST or GET is being made? Listen for AJAX requests and plan the appropriate plan?
a) navigate back() (essentially hitting back button in firefox)
b) make GET request to the previous page url
c) click on "return to results" on current page
with a) back() sometimes do not work correctly for AJAX sites with no breadcrumbs. or for POST search results for example where pressing back will prompt alert message.
with b) my concern is that the url may not match up,
ex) dynamic urls with unique hash sessionid parameters
http://www.aa.com/results.php?sessionid=29756293changeseverytime
So how do I create a contingency to make sure the back navigation works correctly as expected for a variety of web apps and sites (there are lot of variability in terms of how the back button will behave).
Why don't you store the location of the page that you want to verify, hit a link, use the goBack and then verify location of check the variables (the one you stored and the location of the verify page)?
By the way, if your site uses AJAX I suggest you use the pause function that waits for the AJAX lib. To fully load, or set the speed of your site (maybe combine them together in rare cases).
I have a very strict requirement to use POST to pass in request parameters to my application upon entry. Once entering the application (page1), entering form information and continuing to the next page (page2) via a commandButton, the expectation is that the data will be posted and later read from a session scoped manage bean. All works well except when using browser back on page2 to navigate back to page1.
I have tried adding a redirect tag on the navigation rule that navigates from page1 to page2 to no avail. I have also tried this implementation of the Post-Get-Redirect pattern (http://balusc.blogspot.com/2007/03/post-redirect-get-pattern.html). Am I missing something obvious here?
Abel, the scope of page1 is request.
The solution we came up with which is no means ideal is to disable browser caching on the previous page. What this means is that whenever you refresh the page using the browser refresh button or click the browser back button, the browser will indicate that the page is expired and prompt a warning asking whether you want to re-submit the request.
We do have a work around which is to provide navigation buttons within the webpage but the idea was to support browser back. This would be easy using GET parameters, but POST provides additional complexity which we have decided to mitigate by by providing our in-house navigation buttons.
I have a page that gathers environment status from a couple of IBM WebSphere servers using iframes similar to this:
<iframe src="http://server:9060/ibm/console/status?text=true&type=server&node=NODE&name=ServerName_server_NODE"></iframe>
and it happily prints out "Started" or "Unavailable" etc. But if I load the same url in a normal browser sometimes it works, sometimes it does not? Some of them are showing a login page, while others are simply return HTTP code 500.
So whats the difference between loading the page through an iframe vs through a browser?
I can tell you that the iframe solution works no matter which machine I am doing it on, so I do not belive it has anything to do with the user whos opening the page. And before you ask, why not keep the solution that works, well its because it takes a long time to open the page with the iframes vs a page where everything is requested through ajax.
Update: Using jQuery to perform the ajax call returns "error" and "undefined" for the servers that I can't see in a normal browser.
One difference is an iframe has to render the view while XHR would not.
An iframe is essentially the same as opening with the browser. In both cases the browsers credentials are used, so there will be no difference between the two.
Secondly, loading something in an iframe should take the same amount of time as requesting it through XHR, since in both cases the browser makes an HTTP request and waits for the response. Although I should add that an iframe will take time to render the content onto the page. However if you plan on displaying it with ajax anyways, an iframe/xhr solution will be more or less the same.
In case of ajax request same origin policy (which restricts cross domain call) comes into picture. So you can't make cross domain call using xhr. Alternative for same is embed flex swf file in your page as activex control and make flex call through javascript and then flex is responsible to make cross domain call (flex can if targeted domain allows cross domain using crossdomain.xml) and renders result using javascript again.