tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat) ...@ice-sa.com>
Subject Re:[OT] loading images through a Servlet
Date Fri, 02 Oct 2015 09:46:58 GMT
On 02.10.2015 11:39, Bill Ross wrote:
> And if I find anyone hitting me with unknown or aged-out hashes I will report their IP
addresses to porn sites so they can be blocked there as well. This honeypot activity could
be an alternate source of income, if I hadn't just disclosed the method :-)
>

Never mind that. If you have actually found an innovative solution to the 
"browser-knows-all-anyway" conundrum, much bigger fame (and income) awaits you.

> Bill
>
> <div>-------- Original message --------</div><div>From: Bill Ross <ross@cgl.ucsf.edu>
</div><div>Date:10/02/2015  2:04 AM  (GMT-08:00) </div><div>To: Tomcat
Users List <users@tomcat.apache.org> </div><div>Subject: Re: loading images
through a Servlet </div><div>
> </div>Thanks Andre for the well-considered reply. To Thad - thanks, I also
> asked on stackoverflow after here.
>
> I believe I have solved the obfuscation problem independent of the
> javascript issue. What I just got working is logically:
>
>       img.src = "/images/" + /servlet/getnext(params)
>
> Where I now have a Servlet at /images that serves the file, thanks to a
> generous coder at stackoverflow. I'll post the nicely designed code here
> if anyone wants.
>
> I am adding a table to map random hashes to file names. I'll insert
> there and have getnext() return the hash instead of the file name. The
> new Servlet I just added will look up the hash, check the age of the
> record and refuse it if older than a second, and then serve up the
> mapped file from the filesystem with current date and some flippant
> random file name in the headers.
>
> So as far as I can see, the only thing not obfuscated is the image
> itself and my ego, which is harmless here.
>
>> I can think of even more hare-brained schemes where for instance some
> Ajax function of yours could open a websocket connection to the server,
> and receive a stream of image objects from the server over that single
> connection and "plug" them into the page as appropriate.  But any kind
> of thing like that would start to deviate seriously from standard
> practices, and need a serious effort of development and debugging before
> it could be considered as "production-level".
>
> This is exactly what I was fishing for, and I thought maybe it had been
> solved in some javascript library.
>
>> P.S. and if you really want to know how to display tons of images
> fast, I suggest that you have a look (in a manner of speaking of course)
> at some of those many XXX websites.  They /must/ have ways to do this
> efficiently..
>
> Maybe I will be selling to them :-) Thinking of my slideshow app overall.
>
> Bill
>
>
>
> On 10/2/2015 1:16 AM, André Warnier (tomcat) wrote:
>> On 01.10.2015 23:52, Bill Ross wrote:
>>> Please let me know if there is a better place to ask
>>> Servlet/javascript interface questions.
>>
>> For the javascript part, there are probably better places.  But the
>> people here are awesome, so it's worth giving it a try.
>> For the servlet side of it, this /is/ probably one of the best places.
>> But let's start with javascript :
>>
>> First a general principle : if you are thinking about security or any
>> form of obfuscation in the face of a determined and competent client,
>> basically forget it. To get an image or anything else from a server,
>> the browser (or else), has to know how to get it, so you need to send
>> it that information. And once the server sends any information to the
>> client, it is no longer under your control, because the browser (or
>> other program, such as curl and the like) is under total control of
>> the client (user).
>>
>> So, as long as /that/ is not your ultimate purpose,
>>
>>>
>>> I have a slide show web page that does the logical equivalent of:
>>>
>>>       var img = new Image();
>>>       img.src = "/images/" + /servlet/getnextfile(params)
>>>       img.[onload]: document["image"].src = img.src; resizeImage();
>>>
>>> Rather than using the 'getnextfile' servlet to get a file name and
>>> then load it, I would
>>> like to have getnextfile return a stream of bytes from the database
>>> which seems feasible
>>> (streaming a BLOB I assume), but I don't know how to receive that
>>> into an Image (which
>>> wouldn't have 'src' set - ?).
>>
>> Have a look here : http://www.w3schools.com/jsref/dom_obj_image.asp
>>
>> The javascript DOM "img" object does not seem to have any callable
>> method by which it can retrieve its own image content.  The only way
>> to have it retrieve that content, is by changing its "src" property.
>> This you can do, and it will apparently refresh its own image by
>> itself when you do.
>> But the "src" property has to be set to a URL, so it "retrieves
>> itself" by making a HTTP call to the server.. chicken and egg kind of
>> thing.
>>
>> In a form of obfuscation, you could try to set the "src" property to
>> something like 'javascript: retrieve_image("some id")' (Note: I
>> haven't tried this), and then have this "retrieve_image()" function be
>> something in one of your javascript libraries, which would in turn
>> retrieve the image from the server, in a way less visible to the
>> casual script kiddie.
>>
>> But do not forget that the browser first has to receive that
>> javascript library from the server, so it has it, and the person
>> controlling the browser can see it, and turn it off at will or modify
>> it to do anything he wants; see basic principle above.
>> In a more sophisticated way, you can probably add a custom method to
>> the img objects on the page (see jquery for that kind of thing), so
>> that you can have them change their own src property and retrieve
>> their content in a less-immediately visible way.  But again, refer to
>> basic principle above.
>>
>>>
>>> One motivation is to reduce the round trips to the server for faster
>>> response time.
>>
>> Basically, you still have to retrieve the image from the server, so I
>> do not believe that you will gain much on that side.
>>
>> Also, over quite a long period by now, as well browsers as webservers
>> have been both well-debugged and optimised to death, to respectively
>> retrieve and serve "things" using the "normal" HTTP methods (think of
>> caching e.g., on both sides, and content compression), and avoid
>> introducing security holes in the process (*).
>> Anything that you would do yourself is likely in the end to be even
>> less optimised and secure.
>> (This is not to discourage innovation of course.  You might after all
>> still invent a better mousetrap).
>>
>> (*) yes, I know, successive IE versions are kind of a counter-example
>> to that statement.
>>
>>> Another motivation is to keep the filename from the user.
>>
>> See basic principle.  Anyone who installs the "web developer" plugin
>> into his Mozilla browser, can ultimately find out anything about
>> anything that is part of the page shown in the browser.
>>
>> I can think of even more hare-brained schemes where for instance some
>> Ajax function of yours could open a websocket connection to the
>> server, and receive a stream of image objects from the server over
>> that single connection and "plug" them into the page as appropriate.
>> But any kind of thing like that would start to deviate seriously from
>> standard practices, and need a serious effort of development and
>> debugging before it could be considered as "production-level".
>> So the question would be : is it worth it ?
>>
>>
>> P.S. and if you really want to know how to display tons of images
>> fast, I suggest that you have a look (in a manner of speaking of
>> course) at some of those many XXX websites.  They /must/ have ways to
>> do this efficiently..
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message