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 :-)
Bill
<div>-------- Original message --------</div><div>From: Bill Ross
<r...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
