PDA

View Full Version : extjs.com/s.gif



foniksonik
7 Jun 2007, 2:52 PM
WTF guys... why are my pages dialing up extjs.com? This is in several locations and I only noticed it just now. This is a serious privacy violation and you guys should get this corrected ASAP, unacceptable.

Here's the offensive line of code:

BLANK_IMAGE_URL:"http:/"+"/extjs.com/s.gif"

Otherwise I love your library... so get that fixed yesterday.

What's funny is that it's documented in the source but never mentioned on the build page or in an install file or anything like that.

/**
* URL to a 1x1 transparent gif image used by Ext to create inline icons with CSS background images. (Defaults to
* "http://extjs.com/s.gif" and you should change this to a URL on your server).
* @type String
*/
BLANK_IMAGE_URL : "http:/"+"/extjs.com/s.gif",

brian.moeskau
7 Jun 2007, 3:58 PM
Those comments are also reflected in the API documentation:

http://extjs.com/deploy/ext/docs/output/Ext.html

As you quoted yourself:


...and you should change this to a URL on your server

It's there for your convenience -- the alternative is for Ext to be broken by default out of the box until you manually create your own .gif file. Most people prefer the current approach. But if you have privacy concerns, then by all means change the url as the docs suggest.

foniksonik
8 Jun 2007, 9:40 PM
Those comments are also reflected in the API documentation:

http://extjs.com/deploy/ext/docs/output/Ext.html

As you quoted yourself:

It's there for your convenience -- the alternative is for Ext to be broken by default out of the box until you manually create your own .gif file. Most people prefer the current approach. But if you have privacy concerns, then by all means change the url as the docs suggest.

Thanks. Any way that API call can be made more obvious and important, as in, it could default to writing a warning message at the top of the page letting you know that BLANK_IMAGE_URL has not been set, you may want to use that space for doing some additional sanity checks for configuration... There are plenty of precedents in open source software to providing warnings to users when settings are non-optimal.

brian.moeskau
9 Jun 2007, 11:03 PM
We could probably do something like that, but... I really think your privacy concerns might be a bit overstated. Generally speaking, the biggest privacy issue with remote image linking is with images loaded into emails. Since someone has sent you an email, AND they can provide a unique image url with each email, they can tie your specific email address to your IP address, validate that your email address is valid, log the exact time that you read your email, etc.

If you load Ext code onto a site that references extjs.com for an image file, we have absolutely nothing that can tie that particular image to you. We have the fact that SOME IP address hit that image, but it's not tied to anything that would usefully identify anyone. So yes, in theory I guess we could count how many IP addresses have our code loaded with the default image path, but it would tell us nothing private about anyone and would give us no more information than a typical web server log.

So, we will consider putting in a more obvious warning of some type that the default should be changed. But I wanted to clarify to other readers who might read this thread that while it is something to be aware of, they should not consider this to be a "serious" or "offensive" privacy violation.

perrich
9 Jun 2007, 11:58 PM
I think it's not really a privacy violation and anything else. But, if Ext user needs HTTPS web apps, a browser security issue (HTTP link under HTTPS) will be displayed...

Maybe, it can be added to "Getting started with Ext" section of the FAQ ?

KimH
12 Jun 2007, 12:12 AM
It has been added to the wiki (http://extjs.com/learn/Ext_FAQ).

perrich
12 Jun 2007, 2:09 AM
Thanks.

haibijon
12 Jun 2007, 4:50 AM
WTF guys... why are my pages dialing up extjs.com? This is in several locations and I only noticed it just now. This is a serious privacy violation and you guys should get this corrected ASAP, unacceptable.

This is no privacy violation... This has been documented in the API docs, as well as the source itself since alpha release, and its also come up in the forum several times. Read the documentation, don't blame the developers for your laziness.

sj137
12 Jun 2007, 12:41 PM
i think "laziness" is a little hard... i'm new to javascript and i'm trying to learn a whole lot to get the project i'm working on done as quickly as possible, i'm never going to be able to read the entire documentation...

and just like i get annoyed when spam emailers use dirty tricks to collect info on people, my first thoughts were shock and horror that possibly extjs might be doing the same, tho i only entertained the thought for a milli-second and then i remembered what a great bunch of guys you really are and there had to be another explanation which i now clearly see there is, however i don't know why you don't just include the gif with the distribution and link to it the way you link to other gifs used in the library, i only say this cos when i demo'd the library for some people on a pc without an internet connection this is how the tree looked in firefox...

http://www.blackandwhiteuk.com/s_gif_prob.JPG

...it's a bit ghastly, especially embarrassing for me cos i'd been raving to everyone about how beautiful extjs looks, and that it wipes the floor with the competition etc etc... ;)

hope there's a better way to solve this prob in future versions... all the best, peace out.

SJ

para
14 Jun 2007, 6:10 AM
I just discovered this too. I've been working with ext for 3 months and never noticed...
Couldn't s.gif be included in the resources/images/default/ and have the default set to that folder? I don't claim to understand the complexities of the system, but it seems pretty straight-forward to me.

haibijon
14 Jun 2007, 12:26 PM
I just discovered this too. I've been working with ext for 3 months and never noticed...
Couldn't s.gif be included in the resources/images/default/ and have the default set to that folder? I don't claim to understand the complexities of the system, but it seems pretty straight-forward to me.

Yeah, gotta say this does sound like an easy solution to the problem...

neongrau
18 Jun 2007, 5:46 AM
not really a solution, the image is used in HTML context (as src for generated html) and depending on what directory depth your actual views are in 99% of all use cases this would cause a request that ends in a 404. and to solve that you would have to define the path. so the current solution is the only possible way to make ext work out of the box.

but i find it a bit amusing how people get paranoid about a request to an outside server without even understanding the issue, ppl are so negative ;)

*scnr*

but maybe it'd a good idea to leave Ext.BLANK_IMAGE_URL declared null, and add

if (Ext.BLANK_IMAGE_URL.length==0) alert('please point Ext.BLANK_IMAGE_URL to a transparent gif image for ext to work')

haibijon
18 Jun 2007, 3:55 PM
Makes sense, I guess if there was an easy solution jack would have figured it out... 8-|

efege
21 Jun 2007, 5:15 AM
Hey, should we be doing something (more clever) about this issue? People keep posting the same question, even in the Bugs forum:

http://extjs.com/forum/showthread.php?t=8034

nbinder
25 Jun 2007, 2:24 AM
Simple suggestion that would help much:

Add the definition to every single example in the "Learn" section as a first step. Not much work, nearly maximum impact.

The alert is also a good idea I think.

em_te
25 Jun 2007, 8:58 PM
Or rename the image to something like "spacer.gif".

dt
13 Sep 2007, 11:21 AM
Is s.gif is trying to set a cookie? IE7 complains about this and block the attempt. However, Firebug say no cookie is send.

I think is a privacy violation (with or without cookie) because you (the person that has access to server logs) can see from the referer - the website where extjs is use. You should find another way to load that file.

Until you'll find a sollution, the quick fix to avoid the SSL warning message is to replace http:// with :// (just remove the http and the browser will choose the best communication protocol).

brian.moeskau
13 Sep 2007, 11:43 AM
Did you even read this thread?

http://extjs.com/learn/Ext_FAQ#My_code_links_to_extjs.com.2Fs.gif

eddyoc
1 Nov 2007, 8:02 AM
I have to say that this bizarre request causes no end of problems. This is the first line of my code:

Ext.BLANK_IMAGE_URL = "./images/default/s.gif";

Overriding the default Ext setting. But, every now and again, for no apparent reason, Ext decides simply to revert to its default setting and a request is made over the internet for a tiny pixel.

From the client's perspective this is a security breach!! Their awesome Ext web application snugly safe behind HTTPS suddenly sends data off to the world wide web. We know it's a request for a pixel but to the client it's a reason to avoid the Ext plaform. Love your app, but this Ext thing won't be SOX compliant. It's an uphill battle once some suit says something like that.

Ditch this crazy setup and simply bundle the gif with the js and css files. Whatever benefits you derive from the current setup it's costing you clients and hurting your reputation.

My two cents worth.

MClark00
1 Nov 2007, 9:05 PM
Guys, I completely agree with eddydoc. I realize when writing the library that the use cases you envision can't cover every usecase a customer might try to tackle, but I think there is enough feedback here that suggests that this should be fixed.

In my case, we're using Ext as the skin for a Java webapp, and all of the JS is packaged in a self-contained war. Since we don't always know exactly which context we'll be deployed in, we can't construct an absolute URL to the s.gif ahead of time. Is this really something that's impossible to fix in the library? To me, if you can't fix it because of the way it's being used in the library, it seems for a prime target for refactoring something in the library.

That said, great job on the work you're doing. I don't mean to come across like a jerk, this is just a big annoyance.

Thanks,
Matt Clark

Animal
1 Nov 2007, 11:27 PM
Ditch this crazy setup and simply bundle the gif with the js and css files.
My two cents worth.

It is bundled in there, (in images/default) so that you can set up the URL to point to it if you wish when you have read the docs and the FAQ.

But what do you suggest that the default blank image URL is set up to exactly, that will work? Please reply with a suggested better default URL for this setting.

"/eddydocswebapp/images/default/s.gif"??

How can it possibly be set by default to know where to access the image on your server?

alex.tomes
2 Nov 2007, 4:03 AM
Suggestion : can't this darn pixel be linked like all other images in EXT through CSS and relative path?

evant
2 Nov 2007, 4:04 AM
No, because I think it has to be inserted as an image element, as opposed to being the background image of some element.

mystix
2 Nov 2007, 7:51 AM
i'm puzzled + lost + confounded + confused + baffled.

I for one thought that if we followed the Yellow Brick Road -- FAQ Entry (http://extjs.com/learn/Ext_FAQ#My_code_links_to_extjs.com.2Fs.gif) / thread 8887 (Section 2e) / thread 13985 (Section 2e) / 1.x BLANK_IMAGE_URL docs (http://extjs.com/deploy/ext/docs/output/Ext.html#BLANK_IMAGE_URL) / 1.x SSL_SECURE_URL docs (http://extjs.com/deploy/ext/docs/output/Ext.html#SSL_SECURE_URL) / 2.x BLANK_IMAGE_URL docs (http://extjs.com/deploy/dev/docs/?class=Ext) / 2.x SSL_SECURE_URL docs (http://extjs.com/deploy/dev/docs/?class=Ext) -- we'd be sure to find the Wizard of Ext.

Animal
3 Nov 2007, 8:01 AM
No, because I think it has to be inserted as an image element, as opposed to being the background image of some element.

That's correct, the output element has to be an image with a rooted URI:



<img src="/evants_webapp/evants_static_resources/images/s.gif">


So that if you are in the page "/evants_webapp/foo/bar/bletch/page.jsp" it will be able to find it.

Lobos
4 Nov 2007, 9:07 AM
I only noticed when I lost my connection and had to work offline, everything broke...

Anyway, I do love your library, but how about a big warning about this somewhere, it lost me a lot of time - if I was online I would have found out the problem here in no time, but I wasn't and it should be taken into consideration that this could happen to others as well.

And yes this is probably a big rant showing what a fool I am for not RTFM... but I have read lots and lots of docs here, I just never came across that bfore...

Anyway I conclude with all the respect in the world for your great work! I have just got a tree working with my php node system... very, very happy about this! So thanks for these wonderful toys!

-Lobos

BlackLoter
19 May 2009, 7:46 AM
Hope I'm not reviving a thread which is too old, but I just saw it and thought worth answering.
Although I don't think this is a big issue as it is easily configurated once known, there actually is a workaround.
The idea is to get
- a css property from the style sheet reading from there where the image is being loaded from
- the path to the stylesheet
If you know both of them you can easily build the path to the image.
I noticed that in Firefox you immediately get the absolute path of the image from the css (thus you don't need anything else), while in IE you get the path relative to the css (as it is written in the style sheet) so you also need the path to the style sheet to compose the 2 things.

Here is some sample code:



function testMe() {
if (!document.styleSheets) return;
var thecss = new Array();
for (var i=0; i<document.styleSheets.length; i++) {
if (document.styleSheets[i].cssRules) { // Standards Compliant
thecss = document.styleSheets[i].cssRules;
}
else {
thecss = document.styleSheets[i].rules; // IE
}
for (var j=0;j<thecss.length;j++) {
if (thecss[j].selectorText=='.x-drag-overlay') {
alert(document.styleSheets[i].href);
alert(thecss[j].style.backgroundImage);
}
}
}
}



This function will alert the location of the ext-all.css file and of the s.gif one, if placed in a page where the ext-all.css stylesheet is used.
What it does is looking through all the css properties of the imported style sheets and then extract the 'background-image' from the '.x-drag-overlay' class definition (which uses s.gif as its background).