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.
Related
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?
I have a question similar to this WebView Windows Store App C# Ajax Not Working
I am loading a local html file onto WebView using :
webView.NavigateToLocalStreamUri(pageUri, localUriResolver_);
I am trying to make a ajax call to remote server. I am getting an error with status=0.
I tried with both jquery and plain XmlHttpRequest, results are same. I am not able to get remote file content.
At the same time, I am able to load local file. As all local files are redirected to my "localUriResolver", i am able to resolve the url and provide the content to ajax call.
Coming to remote content, I know this is cross domain request issue.
Is there a way to get around it on Windows 8.1 WebView. Is there some flag to override the cross-domain origin policy.
Thanks
I believe I am running into the same issue right now. It would appear as though my ajax request is not completing.
I see that our API is hit on our server but the complete callback of my jQuery ajax request is never triggered.
Currently investigating why, please update this if you've found a work around or solution.
I am using Firebug 1.10.2 with Firefox 14.0.1. When showing a web page, the Firebug add-on has this "behavior": Firebug’s “Aborted” message upon Ajax request.
What should I make? Is it so dangerous that I must improve my web application because the presence of some error, or it is a Firebug bug or something else?
Please see the documentation of XHR open() for example here:
https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest
Note: Calling this method an already active request (one for which
open()or openRequest()has already been called) is the equivalent of
calling abort().
Just create a new XHR instance whenever you need one. Better yet, use jQuery or other JS library to do AJAX. It should shield you from these intricacies.
I saw this problem when trying to load a JavaScript file using HTTPS, but was serving the site on my local development environment using HTTP. The request to fetch the JavaScript file would fail with the Aborted message in FireBug. Making the requests use the same protocol worked for me.
My web app runs under Tomcat, it uses AJAX requests very intensively, and during the development process I have to redeploy the web app intensively too. After the redeployment I usually simply refresh the page knowing that the user session is dropped, but I always get to the scenario described below:
Go to some page, a really big page with many JS-scripts included, that actually makes those intensive AJAX requests.
Stop Tomcat or redeploy the web app.
Refresh the page.
Enter the credentials in the sign-in form to authenticate.
Suddenly get the last AJAX request response in the browser window and the AJAX request URL in the URL bar.
Wow... It looks strange for me that AJAX request URLs appear in the URL bar along with their response in the web page display area. This actually happens to Firefox and Chrome (haven't tested it in other browsers). Unfortunately, I cannot reproduce the same behavior in a simple page written from scratch. Frankly speaking, I don't really understand what happens to such requests and why do browsers "think" if AJAX requests/responses are entered in URL bar by user...
Your possible explanations or hints for such a strange behavior are very and very appreciated. Thanks!
(Perhaps it can help: All AJAX requests are performed with jQuery 1.4.2)
I'm very sorry, as I understood later, the question is not complete, because there was another pitfall I didn't mention, so no one couldn't answer the question in principle. The reason of the bug was hiding in the... <body onunload="..."> tag definition. That was quite unexpected, but that code contained some AJAX request that must be invoked when a user leaves the page. I only realized that the authenicating module (FORM, j_security_check) returned a response (HTTP 302) containing the Location header - so that was the reason why browsers did redirects.
The exact scenario was like that:
Open the page containing <body onunload="some_ajax_here">.
Log out the app using another tab so you could stay at the same page.
Refresh the page so some ajax could be invoked - this AJAX request is not now allowed because it's a secured part of the application (you get the forwarded content of the login page).
Enter the credentials and now oops you get to the result of some ajax directly in the browser window.
As the quick fix, and I hope the final one, I added another request following that AJAX request:
$.ajax({
async: true,
method: "GET",
url: document.location.pathname + document.location.search
});
So the HTML page script simply makes self-page request the last one - j_security_check returns the Location referring the last used HTML page, and the redirect works fine. Perhaps my explanation is not clear and may be not complete or even full of mistakes, but it looks like that in general. I'm very sorry once again, and thank you #ChristopherSchultz!
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.