Re: client side same-origin IE issue
Two thumbs up for deferred binding. I overwrote the HTTPRequestImplIE6
deferred binding with my own ActiveX version. Works great. I hope this
thread is useful to someone at some point.
...
public class HTTPRequestImplIEActiveX extends HTTPRequestImpl {
@Override
protected native JavaScriptObject doCreateXmlHTTPRequest() /*-{
try {
return new ActiveXObject('MSXML2.XMLHTTP.3.0');
} catch (e) {
return new ActiveXObject("Microsoft.XMLHTTP");
}
}-*/;
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en
-~--~~~~--~~--~--~---
Re: client side same-origin IE issue
On Oct 4, 8:52 am, David Given wrote:
> I don't know of any web browsers that actually get Javascript security
> right when using the file: scheme --- they usually just deny everything
> (as you're finding out).
>
> How badly do you need to run this on a machine without a webserver? i.e.
> could you just install one? It would make life much simpler.
Running this application without a webserver is important.
To update where I'm at:
GWT 1.5.2
---
/**
* Internet Explorer 6 implementation of {...@link HTTPRequestImpl}.
*/
class HTTPRequestImplIE6 extends HTTPRequestImpl {
@Override
protected native JavaScriptObject doCreateXmlHTTPRequest() /*-{
return new ActiveXObject("Microsoft.XMLHTTP");
}-*/;
}
GWT 1.5.3
---
/**
* Internet Explorer 6 implementation of {...@link HTTPRequestImpl}.
*/
class HTTPRequestImplIE6 extends HTTPRequestImpl {
@Override
protected native JavaScriptObject doCreateXmlHTTPRequest() /*-{
if ($wnd.XMLHttpRequest) {
return new XMLHttpRequest();
} else {
try {
return new ActiveXObject('MSXML2.XMLHTTP.3.0');
} catch (e) {
return new ActiveXObject("Microsoft.XMLHTTP");
}
}
}-*/;
}
As quoted from http://msdn.microsoft.com/en-us/library/ms537505(VS.85).aspx
"The native XMLHTTPRequest object only permits HTTP and HTTPS urls
(regardless of zone) and permits only the following HTTP methods:
"GET", "POST", "HEAD", "PUT", "DELETE", "MOVE", "PROPFIND",
"PROPPATCH", "MKCOL", "COPY", "LOCK", "UNLOCK", "OPTIONS".
IE7's object allows only requests to the same port; IE8's object
removes that restriction."
This seems to be where I'm restricted from accessing file:\\ - a local
trusted source. Although IE is in the right by adhering to W3C
documentation. http://www.w3.org/TR/XMLHttpRequest/
"...it can be used to make requests over both HTTP and HTTPS (some
implementations support protocols in addition to HTTP and HTTPS, but
that functionality is not covered by this specification)."
And this request for the change
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/c3cae4dc71580eff/2dc6dc15d51fb641
although I don't know where the order of operations is recommended by
MSDN
Right now it looks as though I'll have to create a JSNI method for
specific access on IE deployments.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en
-~--~~~~--~~--~--~---
Re: client side same-origin IE issue
Brian Blain wrote: [...] > I wanted to be able to move the project war dir to another computer > that does not have a server and open ClientUpload.html. Right now when > ClientUpload.html is opened in Firefox or Chrome the URL is "file:/// > C:/.../ClientUpload/war/ClientUpload.html" and "C:/.../ClientUpload/ > war/ClientUpload.html" in IE (no file:/// attached to the front). I don't know of any web browsers that actually get Javascript security right when using the file: scheme --- they usually just deny everything (as you're finding out). How badly do you need to run this on a machine without a webserver? i.e. could you just install one? It would make life much simpler. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "They laughed at Newton. They laughed at Einstein. Of course, they │ also laughed at Bozo the Clown." --- Carl Sagan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
client side same-origin IE issue
I have a project using GWT 1.7 that is able to upload a file without a
server that works great on Firefox and Chrome, however when testing IE
I get "The URL myfile.xml is invalid or violates the same-origin
security restriction" error.
My GWT standard directory structure for relevant files looks as
follows:
ClientUpload\war\ClientUpload.html
ClientUpload\war\clientupload\clientupload.nocache.js
ClientUpload\war\clientupload\myfile.xml
I wanted to be able to move the project war dir to another computer
that does not have a server and open ClientUpload.html. Right now when
ClientUpload.html is opened in Firefox or Chrome the URL is "file:///
C:/.../ClientUpload/war/ClientUpload.html" and "C:/.../ClientUpload/
war/ClientUpload.html" in IE (no file:/// attached to the front).
The code to load the myfile.xml:
public class ClientUpload implements EntryPoint {
AsyncCallback callback = new AsyncCallback() {
public void onFailure(final Throwable caught) {
Window.alert("failed " + caught.getMessage());
}
public void onSuccess(final String result) {
Window.alert("results: " + result);
}
};
public void onModuleLoad() {
RequestBuilder requestBuilder = new RequestBuilder
(RequestBuilder.POST,
URL.encode("myfile.xml"));
requestBuilder.setHeader("Content-Type", "text/xml;
charset=utf-8;");
try {
requestBuilder.sendRequest("", new RequestCallback() {
public void onError(final Request request,
final Throwable caught) {
callback.onFailure(caught);
}
public void onResponseReceived(final Request request,
final Response response) {
callback.onSuccess(response.getText());
}
});
}
catch(Exception e) {
callback.onFailure(e);
}
}
}
I've tried multiple ways to solve the issue for IE: moving the
myfile.xml to different directories, appending GWT.getModuleBaseURL()
to the front of the file name, using GET instead of POST, etc. In FF/
Chrome let's say the file is not found in the desired location, the
result returned is the 404 error page including the attempted path to
the file, RequestURI=/clientupload/myfile.xml
I tried previously upgrading from 1.5.2 (with which this technique
worked) to 1.5.3 which didn't work and was able to let it slide, I was
hoping that maybe it would be noticed and/or fixed by now (1.7) but no
such luck. Looking at the issue tracker I see
http://code.google.com/p/google-web-toolkit/issues/detail?id=3022 as a
first guess to where it may have stopped working for (at least my
needs) IE7 possibly IE6 (can't confirm now)
So my questions are:
Why does this work in Firefox and Chrome and not IE?
Where or what would the origin be for IE local html files?
Is there maybe a better way without a server to load a XML file into
HTML? with GWT?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en
-~--~~~~--~~--~--~---
