I am working on a phonegap application which runs simple ajax requests to a rendered website, pulls down the html and reskins content locally.
A requirement is that websites on an internal network can be requested. I have connections via global ip addresses working fine, but cannot get the ajax to work on internal networks.
For example connecting to a 10.0.0.xx address will always fail. The device is connected to the same network and I can access the websites on the internal network fine in browser.
Is there any way around this?
Make sure you modified your domain whitelist file correctly to allow external access.
For more information about domain whitelist, check the online doc: http://docs.phonegap.com/en/2.1.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide
Hope this helps. Let me know if this works for after modifying your domain whitelist file.
Example of domain whitelist configuration for iOS:
Open your file Cordova.plist and check that you made the following:
1 - Set OpenAllWhitelistURLsInWebView to YES
2 - Right click on ExternalHosts -> Add Row
3 - Set the String value of your new added row to *, so you should have your new line look like this:
Item0 String *
Normally, you would replace * with the external URL you want provide access to. But, to make sure that the problem really comes from the whitelist, we will use *.
Related
I am developing a web page that needs to display, in an iframe, a report served by another company's SharePoint server. They are fine with this.
The page we're trying to render in the iframe is giving us X-Frame-Options: SAMEORIGIN which causes the browser (at least IE8) to refuse to render the content in a frame.
First, is this something they can control or is it something SharePoint just does by default? If I ask them to turn this off, could they even do it?
Second, can I do something to tell the browser to ignore this http header and just render the frame?
If the 2nd company is happy for you to access their content in an IFrame then they need to take the restriction off - they can do this fairly easily in the IIS config.
There's nothing you can do to circumvent it and anything that does work should get patched quickly in a security hotfix. You can't tell the browser to just render the frame if the source content header says not allowed in frames. That would make it easier for session hijacking.
If the content is GET only you don't post data back then you could get the page server side and proxy the content without the header, but then any post back should get invalidated.
UPDATE: 2019-12-30
It seem that this tool is no longer working! [Request for update!]
UPDATE 2019-01-06: You can bypass X-Frame-Options in an <iframe> using my X-Frame-Bypass Web Component. It extends the IFrame element by using multiple CORS proxies and it was tested in the latest Firefox and Chrome.
You can use it as follows:
(Optional) Include the Custom Elements with Built-in Extends polyfill for Safari:
<script src="https://unpkg.com/#ungap/custom-elements-builtin"></script>
Include the X-Frame-Bypass JS module:
<script type="module" src="x-frame-bypass.js"></script>
Insert the X-Frame-Bypass Custom Element:
<iframe is="x-frame-bypass" src="https://example.org/"></iframe>
The X-Frame-Options header is a security feature enforced at the browser level.
If you have control over your user base (IT dept for corp app), you could try something like a greasemonkey script (if you can a) deploy greasemonkey across everyone and b) deploy your script in a shared way)...
Alternatively, you can proxy their result. Create an endpoint on your server, and have that endpoint open a connection to the target endpoint, and simply funnel traffic backwards.
Yes Fiddler is an option for me:
Open Fiddler menu > Rules > Customize Rules (this effectively edits CustomRules.js).
Find the function OnBeforeResponse
Add the following lines:
oSession.oResponse.headers.Remove("X-Frame-Options");
oSession.oResponse.headers.Add("Access-Control-Allow-Origin", "*");
Remember to save the script!
As for second question - you can use Fiddler filters to set response X-Frame-Options header manually to something like ALLOW-FROM *. But, of course, this trick will work only for you - other users still won't be able to see iframe content(if they not do the same).
So my ISP (Smartfren; Indonesia) has decided to start injecting all non-SSL pages with an iframing script that allows them to insert ads into pages. Here's what's happening:
My browser sends a request to the server. ISP intercepts it and instead returns a javascript that loads the requested page inside an iframe.
Aside being annoying in principle, this injection also breaks any number of standard page functionality; and presents possible security hazards.
What I've tried to do so far:
Using a GreaseMonkey script to nix away the injected code and redirect to the original URL. Result: Breaks some legitimate iframes. Also, the ISP's code gets executed, because GreaseMonkey only kicks in after the page is loaded.
Using Privoxy for a local proxy and setting up a filter to clean up the injection and replace it with a plain javascript redirect to the original URL. Result: Breaks some legitimate iframes. ISP's code never gets to the browser.
You can view the GreaseMonkey and Privoxy fixes I've been working on at the following paste: http://pastebin.com/sKQTvgY2 ... along with a sample of the ISP's injection.
Ideally I could configure Privoxy to immediately resend the request when the alteration is detected, instead of filtering out the injected JS and replacing it with a JS redirection to the original URL. (The ISP-injection gets switched off when the same request is resent without delay.) I'm yet to figure out how to accomplish that. I believe it'd fix the iframe-breaking problem.
I know I could switch to a VPN or use the Tor browser. (Or change the ISP.) I'm hoping there's another way around. Any suggestions on how to eliminate this nuisance?
Actually now I have a solution:
The ISP proxy react on the Accept: header that the browser sends.
So this is the default for firefox:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Now we are going to change this default:
And set it to: Accept: */*
Here is how to setup header hacker for google chrome
Set the title to anything you like:NO IFRAME
Append/replace select replace with
String */*
And Match string to .* and then click add.
In the permanent header switches
Set domain to .* and select the rule you just created
PS: changing it in the firefox settings does not work 100% because some request like ajax seem to bypass it so a plugin is the only way as it literally intercepts every outgoing browser request
That's it no more iframes!!!
Hope this helps!
UPDATE: Use DNSCrypt is the best solution 😁
OLD ANSWER
Im using this method
Find resource that contain iframe code (use chrome dev tool)
Block the url with proxy or host file
I'm using linux, so i edited my hosts file on
/etc/hosts
Example :
127.0.0.1 ibnads.xl.co.id
I'll try to explain it as easy as possible.
Replication:
I'm doing an auth/login system where:
The user input him credentials and send the data to the server [classic form].
The server check everything and then (if it's ok) set up a session in the server and response an static view which is rendered using handlebars and by passing one variable: sessionName.
This view includes a js snipet which add a cookie using the code below: document.cookie += ';session_name={{ sessionName }}'. At this moment, all is still correct. And the cookie is added correctly.
And then it redirects to the root of the website. At this point, I expect to have the cookie I set before. But there's not.
Relevant data:
The variable sessionName is compiled properly.
The Analytics [Mixpanel and Google Analytics] cookies are persistent.
I tested in Chrome 39 and Firefox Developers Edition using Mac OSX Yosemite.
The server uses node.js and hapi.js of Wallmart Labs with the hapi.js plugin hapi-auth-cookie
I also tested to set the cookie manually but it doesn't persists neither. Any kind of the ones that I use.
The cookie is a simple string; accurately: hubato so: ;session_name=huabto.
TL;DR
My cookies doesn't persist when navigating. Regardless how or what I set in the cookie.
I had to add the path=/ parameter and it works like a charm!
You can find all the information related to the cookies here.
And beware of the characters you're using because not all of them are allowed.
Background
We have two web applications hosted on different sub-domains. Application 1 is an internal admin system. Application 2 is a helpdesk system.
We can modify the source code of Application 1 but we have no access to modify Application 2.
The Goal
To display a link against an order in Application 1 that will open a new window, the URL of which is that of a ticket in Application 2.
The idea being that our staff can see that an order has a helpdesk ticket raised against it and simply needs to click a link on the order to view the ticket and reply to it.
The problem
Regardless of how I open the new window (window.open, target="_blank", etc.) the ticket in the new window is unable to make any ajax requests back to the helpdesk system where it is hosted.
The URL of the new window is part of Application 2.
In Google dev tools it tells me "The frame requesting access has a protocol of "http", the frame being accessed has a protocol of "https". Protocols must match." even when I open it using _blank.
If I go to the exact same URL manually everything works... but this doesn't help when I need it to work from the link.
Is there any way to achieve the above?
If not, is there any way I can open a new window that is "detached" from the window that opened it so that same origin policy no longer applies?
Edit 2014-03-28 10:23
I have no access to App2's code at all. I cannot make any changes to App2. Any answer must take this into account.
I am trying to open a new window from my application (App1) where the target URL of that window is a page in App2. That page inside App2 then needs to be able to use ajax to communicate with other areas of App2. This is where the problem lies. Because App1 opened the window the same origin policy is preventing that window from making it's ajax requests.
I suspect that JavaScript on the second (helpdesk) app is trying to access the first app via window.opener (which could lead to the cross-origin error you're seeing) and subsequent JavaScript (fetching stuff via AJAX) is then not getting executed. You can probably narrow things down by setting appropriate breakpoints in the second app.
If this is the cause and you can't modify the source for the helpdesk app, how about going to a URL in the internal domain that would then redirect to the help desk? The redirect should cause the window.opener property to become null (same as manually typing in the URL).
Assuming https://admin.mydomain.co.uk and http://helpdesk.mydomain.co.uk, clicking on the "Help Ticket" link would go to a URL in the internal app, e.g. https://admin.mydomain.co.uk/getHelp?ticketId, which would respond with a 301 response and an appropriate Location: http://helpdesk.domain.uk/help/ticketId header taking the user to the actual helpdesk URL.
You could use a proxy server or iframe proxying.
Use the following url //app2.mydomain.co.uk without the http or https.
It's not only a cross domain problem but a protocol issue :
You can't embed https into http page without this warning.
Consider using iframe inside your App1 :
<iframe src="https://app2.mydomain.co.uk" ></iframe>
Or maybe you can use CORS to access data between your two domains ( but i think it's not the point, you want the whole App2 page, isn't it ? )
Edit : By re-reading your question, i'm pretty sure of two thing :
You're not looking at the right direction. You say App2 don't use SSL, and that obviously false when Chrome say "Protocols must match"
It's not a "attach" or "detached" problem. If you put a link (blank or not) in a page, it can be load the new page without any problem, nor link with the referal page.
So my guess is : Your are calling App2 without SSL ( no https), BUT inside the App2, there is some https involved ( certainly some ajax query). So here is the problem : When you open the page without https, it's seem to load, but when the first https Ajax fires, it fail.
Try using https when calling your App2 url, and give us the result
My solution is this: in Application 1 you create a method your method that calling Application 2 on the server side, then you can use AJAX calling your method which will return result of Application 2.
I am trying to host an ASP.NET MVC4 web application with IIS 7.5. When debugging the app everything works fine (I'm assuming this is because of Windows Authentication).
However, when I publish the app and browse to it I get a 405 Method not allowed error:
POST http://localhost/ 405 (Method Not Allowed)
send
i.extend.ajax
i.(anonymous function)
(anonymous function)
From what I've been reading this is either a problem with the Handler Mappings in IIS or some configuration is needed in the web.config. Either way, I have not found the correct solution.
Could anyone tell me what my web.config should include to all POSTS? And/or how to set up the correct Handler mapping in IIS, as I am new to web development and find the number of options a bit overwhelming.
The piece of javascript that throws the error is the following:
$.post("/", { latitude: locLat, longitude: locLon, username: $('#onlineUsers').attr('itemid') });
A 405 is thrown by IIS when an HTTP verb(GET,PUT,POST,DELETE,HEAD,etc.) is requested and is not supported/disallowed by the designated handler.
You'll need to open the IIS manager -> Default Web Site -> Handler Mappings (Or the handler mappings specific to your web-application)
In here you'll need to play with the handler mappings as one of them is not allowing "POST" verbs.
As you are not posting to any specific page (.aspx, .ashx, etc.), it will be difficult to identify the exact handler that is causing you issues.
Handlers of interest may be:
ExtensionlessUrlHandler-ISAPI-4.0_32bit /64bit
StaticFile
Once you identify the handler your request is being routed to, double click it to open the dialogue.
From there click "Request Restrictions" then "Verbs"
Make sure the appropriate verb is present in the text area.
As I mentioned before, I'm not sure which handler is handling your request as you are not posting to any particular page (you may have URL re-writing in place that is routing your request appropriately).
If the above fails, you may need to check if WebDAV Publishing is installed and remove it (restart required).
Maybe you should modify your post'URl format like this:
$.post('#Url.Content("~/Attach/UpdateAttach")'
some users here are having shared hosting and not dedicated servers, so they might not be able to get access to the IIS control panel..
this is my case and here is what I found..
I have my web application on the root directory created through Godaddy control panel.. and the POST request is acknowledged ..
then I used the FileZilla to create a testing folder for my jquery ..( notice i used FileZilla , so the web application and hence the IIS of GoDaddy is not aware that I wanted this folder to be part of my we application )
then whenever I test this jQuery on this testing folder.. I get that error [405 Method not allowed]..
the solution was extremely simple :
I moved my testing page out of that testing folder created by FileZilla and located it inside a folder that was created through Godaddy control panel ( in this case the IIS will be aware that this page is part of my web application :) )
Hope that will help those on Shared hosting