Re: [OT] loading images through a Servlet

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bill,

On 10/2/15 5:02 PM, Bill Ross wrote:
> On 10/2/2015 1:55 PM, André Warnier (tomcat) wrote:
>> On 02.10.2015 21:18, Bill Ross wrote:
>>> Installed FF, HttpFox wasn't installed, installed it but it
>>> doesn't show up under developer tools, but I found something
>>> and here are my headers:
>>> 
>>> HTTP/1.1 200 OK Etag: W/"resized_2_33068.jpg-1443146350159" 
>>> Last-Modified: Fri, 25 Sep 2015 01:59:10 GMT [random
>>> time in past 22.32455 days] Expires: Sun, 01 Nov 2015 19:12:45
>>> GMT Content-Type: image/jpeg
>> 
>>> Content-Disposition: inline;filename="resized_2_33068.jpg"; 
>>> filename*=UTF-8''resized_2_33068.jpg
>> 
>> isn't that a giveaway still ?
> 
> It gives some random information for someone to chew on, until they
> find this email:
> 
> "resized_" + rand.nextInt(7) + "_" + rand.nextInt(10) + ".jpg"

Why bother sending-back a filename *at all*? There's no need to
specify the filename in the response: just dump the bytes and call it
a day.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWD+GlAAoJEBzwKT+lPKRYAG0QAKtDNPqLWSPYcm2m8o9YMDr7
dEBQWe5kY+TStT7zz8cpRPXKI/d4+TIbRPoKQubv5kMRkXFvoHGJVA3HhDAxWOi5
NUHGiQsiI5R2+D6yRmmP+SeYCWO6X5y61pMPbmE+8uavi78NSWXMbkuIqnaG90FJ
60S4z6+2AJUPfunfZKxLH5ayuHGM5W8JKsmP0PwvxoOmpoKF2YxzWNedvWfP4RTL
GgMZSpzs0S515JNbL0aSJMJBUTirpCu/0xE+GXJMF/1+DpMduvBibTcgXZWImESy
d/BkmAmkQ49Ffc6IEJGekrLgA7cL56OvKKG1M+HbLnOs8zdpxYB/7CO4ckXCNTjV
3+Ceoo8KHAZCF8PD30Pb1C1y+0Xq5r2Cd48kfUluO2/2kCw0rmrvpuFEJgydGgZG
XTnxP3NcB3Q18rytEvAOBCH6ODbDZHkq5xXPPO9racmF9GB+rFMo4gGw2fkJE9hQ
YdCPx3RAf12NnVI/QhyeurMFwasvekm5N3qThp9K2F2Zs0ou16QKBTnkpMnEXhcf
eHdmcCg77faEW/fUO7ugeHUvH/CRSHDYOTs/tkZZU0kxgA0P82/qcaVPTQBmYyc5
Lhnme4FpHeoEyxJVtRby3DUDXqCdzdK+aFM32GTvA1zPJoL16wKBhF4APJe10PqL
nFZVY2jw9AthSl/pDlKV
=9j5Y
-END PGP SIGNATURE-

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

Re: [OT] loading images through a Servlet

[tomcat]

On 02.10.2015 12:44, Bill Ross wrote:

Whether or not I have masked the file name in the header properly, which I 
can't verify easily


Oh yes you can.
Mozilla Firefox, plugins, Web Developer, HttpFox.
click and open in its own window.
click start

then get your page (in the main window)

then go back to the HttpFox window, click on a line and use the various views available to 
see exactly what the browser has sent, and what the server returned (headers and all).



 but believe is working, I have definitely masked the name in the URL and protected 
myself against later downloads:


HTTP ERROR 404

Problem accessing /images/_ewjMC3. Reason:

 Not Found

While on the server side:

...TagResourceServlet - DANGER OLD HASH ATTACK ...

Will the fame and money just arrive? I'll settle for 6 month's salary (that's 
how long I've been working on my own unpaid :-)



You may want to refine your scheme a tad, thinking of the robots (Google etc) which will 
be exploring your site.  You don't want to be swamped by DANGER messages above for trivial 
cases (nor communicate their IP to the XXX sites).


Other than that, your scheme looks nice to me so far.





 Original message From: "André Warnier (tomcat)" <a...@ice-sa.com> 
Date:10/02/2015  2:46 AM  (GMT-08:00) To: users@tomcat.apache.org Subject: Re:[OT] loading 
images through a Servlet 
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

 Original message From: Bill Ross <r...@cgl.ucsf.edu> Date:10/02/2015  2:04 AM 
 (GMT-08:00) To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: loading images through a 
Servlet 
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 = ne

Re: loading images through a Servlet

[tomcat]

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.

Since you are asking nicely, 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.  (So in a way, you would be creating your own little internal HTTP forward proxy 
server).


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, 
basic principle above.




One motivation is to reduce the round trips to the server for faster response 
time.


You still have to retrieve each image from the server, which in HTTP 1.1, means one 
request/response per image.  So I do not believe that you can 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 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).


Maybe also read this : https://en.wikipedia.org/wiki/HTTP/2

(*) 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.


Basic principle again.  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 ?
(but then again, HTTP 2 ?)

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.. ;-)

Re:[OT] loading images through a Servlet

[tomcat]

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

 Original message From: Bill Ross <r...@cgl.ucsf.edu> Date:10/02/2015  2:04 AM 
 (GMT-08:00) To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: loading images through a 
Servlet 
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 kidd

Re: loading images through a Servlet

[tomcat]

Chris, you're kind of breaking down an open door here.
Bill was already at the stage of congratulating himself and dreaming of his retirement 
plan, following his discovery of a brilliant and innovative solution.

Better to start from the beginning of the thread..

On 02.10.2015 16:30, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bill,

On 10/2/15 5:04 AM, Bill Ross wrote:

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.


Why not just use the DefaultServlet... that's what it's job already
is. Or, do you need an image from a database or whatever?


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.


You could do your security-checking, and then simply forward() to the
resource, then let the DefaultServlet actually serve the bytes. That
allows you to use range-requests, etags, if-modified-since, and all
that other good stuff.


So as far as I can see, the only thing not obfuscated is the image
itself and my ego, which is harmless here.


What do you need to obfuscate?


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.


Do you need the image to be in an Image object, or do you want to put
it into an  on the screen? If the latter, just change the value
of the 'src' of the  and the browser will re-load the image from
the server.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWDpT2AAoJEBzwKT+lPKRYdj0P/iTqUq5FTYeTgVjJtLXEMile
74ql5SalOtbERrTvyY72d4wHjlnWUYJCJeJOTWyDU3grJsG7OBxHpiWEQEI5c9GV
xEhhGrlI1vOIdJ3gZRCgnrPDV8pdXTS4Sg8zEuLpW5ITRLEJsnHQz6yJDkbLofYz
w9ACt/Dllv/kcJPHrIu9+J5xgLAEUPKIHuu1mM9TkTWeSYepuR8grm3A2GFO999D
+5MIkd/XpkfTK88/yGP6Q2xtXgXAtnI5Ug0e5S72gkGFRsHYV5iWb9yBRoji7W09
G1uOJPm3xiCED2bLsiFBZmhgv/YrmCoVx4EbLnsYO/92tkHT1+2zly2bmKZc/AoC
LXoWI/trEiE2MUWvYlwftyEZvBLsJQCqrHfo6MOwPNwY2YFhv+GYl7E5N+QcQZf5
eCu/vzCvsDZHz7QrVHwInDKXeD2iZ3JxMRVPFT7kIfD/aTzrlFEGqZ+hG/pYsjWh
Gv1l2vmfQkPu7/wmhoCscdcqwk9SMCYOWvK7/5ehSyZl/j/4J/zkqnkbU10HlxO+
wVjt+cVYtrCHf7UXWInF86N5ZHSu9KVsmWdoMUUOxIFbGRQbSIvCVBzFPv+WIoR/
G/hURioQXqcICmslbbhw9QwINuRWz7gpcp+Ll7Jj+3furtxYQwv6IB/qJSWSi/Ih
lvNUQAkYta9Y+ZUGYAfE
=5ruo
-END PGP SIGNATURE-

-
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

Re: loading images through a Servlet

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bill,

On 10/2/15 5:04 AM, Bill Ross wrote:
> 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.

Why not just use the DefaultServlet... that's what it's job already
is. Or, do you need an image from a database or whatever?

> 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.

You could do your security-checking, and then simply forward() to the
resource, then let the DefaultServlet actually serve the bytes. That
allows you to use range-requests, etags, if-modified-since, and all
that other good stuff.

> So as far as I can see, the only thing not obfuscated is the image 
> itself and my ego, which is harmless here.

What do you need to obfuscate?

>> 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.

Do you need the image to be in an Image object, or do you want to put
it into an  on the screen? If the latter, just change the value
of the 'src' of the  and the browser will re-load the image from
the server.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWDpT2AAoJEBzwKT+lPKRYdj0P/iTqUq5FTYeTgVjJtLXEMile
74ql5SalOtbERrTvyY72d4wHjlnWUYJCJeJOTWyDU3grJsG7OBxHpiWEQEI5c9GV
xEhhGrlI1vOIdJ3gZRCgnrPDV8pdXTS4Sg8zEuLpW5ITRLEJsnHQz6yJDkbLofYz
w9ACt/Dllv/kcJPHrIu9+J5xgLAEUPKIHuu1mM9TkTWeSYepuR8grm3A2GFO999D
+5MIkd/XpkfTK88/yGP6Q2xtXgXAtnI5Ug0e5S72gkGFRsHYV5iWb9yBRoji7W09
G1uOJPm3xiCED2bLsiFBZmhgv/YrmCoVx4EbLnsYO/92tkHT1+2zly2bmKZc/AoC
LXoWI/trEiE2MUWvYlwftyEZvBLsJQCqrHfo6MOwPNwY2YFhv+GYl7E5N+QcQZf5
eCu/vzCvsDZHz7QrVHwInDKXeD2iZ3JxMRVPFT7kIfD/aTzrlFEGqZ+hG/pYsjWh
Gv1l2vmfQkPu7/wmhoCscdcqwk9SMCYOWvK7/5ehSyZl/j/4J/zkqnkbU10HlxO+
wVjt+cVYtrCHf7UXWInF86N5ZHSu9KVsmWdoMUUOxIFbGRQbSIvCVBzFPv+WIoR/
G/hURioQXqcICmslbbhw9QwINuRWz7gpcp+Ll7Jj+3furtxYQwv6IB/qJSWSi/Ih
lvNUQAkYta9Y+ZUGYAfE
=5ruo
-END PGP SIGNATURE-

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

Re: loading images through a Servlet

[Bill Ross]

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

 Original message From: Bill Ross 
<r...@cgl.ucsf.edu> Date:10/02/2015  2:04 AM  (GMT-08:00) 
To: Tomcat Users List <users@tomcat.apache.org> Subject: 
Re: loading images through a Servlet 
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 i

Re: loading images through a Servlet

[Bill Ross]

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 

Re:[OT] loading images through a Servlet

[Bill Ross]

Whether or not I have masked the file name in the header properly, which I 
can't verify easily but believe is working, I have definitely masked the name 
in the URL and protected myself against later downloads:

HTTP ERROR 404

Problem accessing /images/_ewjMC3. Reason:

    Not Found

While on the server side:

...TagResourceServlet - DANGER OLD HASH ATTACK ...

Will the fame and money just arrive? I'll settle for 6 month's salary (that's 
how long I've been working on my own unpaid :-)



 Original message From: "André Warnier 
(tomcat)" <a...@ice-sa.com> Date:10/02/2015  2:46 AM  (GMT-08:00) 
To: users@tomcat.apache.org Subject: Re:[OT] loading 
images through a Servlet 
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
>
>  Original message From: Bill Ross 
> <r...@cgl.ucsf.edu> Date:10/02/2015  2:04 AM  (GMT-08:00) 
> To: Tomcat Users List <users@tomcat.apache.org> 
> Subject: Re: loading images through a Servlet 
> 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

Re: loading images through a Servlet

[tomcat]

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

Re: loading images through a Servlet

[tomcat]

On 02.10.2015 17:04, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 10/2/15 10:38 AM, André Warnier (tomcat) wrote:

Chris, you're kind of breaking down an open door here. Bill was
already at the stage of congratulating himself and dreaming of his
retirement plan, following his discovery of a brilliant and
innovative solution. Better to start from the beginning of the
thread..


Yep, I read the whole thread.

I don't think this is a million-dollar idea. If it was, I would never
have gone to college, having written one of these for a client while I
was in high school. In my case, it was a CGI that counted hits to an
image whilst simultaneously serving that image. No security or
anything like that, but the "security" in Bill's case is just a proxy
for "do something first, then serve an image".



It is a bit more than that, though : a user cannot, for example, save the html page 
containing the images, and then reload it later, and still see get the images with the 
same image links, because they will have "expired". Neither can one of these image links 
simply be copied to a friend in an email, and still work for the friend.


He also gets a specific action triggered when someone attempts this.

It is not something infinitely scaleable (the server-side hashtable would get quite 
large), but it is a relatively simple scheme, usable in quite a number of scenarios.



I'm suggesting that Bill can focus on his "do something first" task
and delegate the serving of bytes to a tool more appropriate for the
task: the DefaultServlet.



I would agree with you, except that at some point Bill mentioned serving the image content 
out of a database blob.

That's something the Default Servlet couldn't do.



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

Re: loading images through a Servlet

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 10/2/15 10:38 AM, André Warnier (tomcat) wrote:
> Chris, you're kind of breaking down an open door here. Bill was
> already at the stage of congratulating himself and dreaming of his
> retirement plan, following his discovery of a brilliant and 
> innovative solution. Better to start from the beginning of the
> thread..

Yep, I read the whole thread.

I don't think this is a million-dollar idea. If it was, I would never
have gone to college, having written one of these for a client while I
was in high school. In my case, it was a CGI that counted hits to an
image whilst simultaneously serving that image. No security or
anything like that, but the "security" in Bill's case is just a proxy
for "do something first, then serve an image".

I'm suggesting that Bill can focus on his "do something first" task
and delegate the serving of bytes to a tool more appropriate for the
task: the DefaultServlet.

- -chris

> On 02.10.2015 16:30, Christopher Schultz wrote: Bill,
> 
> On 10/2/15 5:04 AM, Bill Ross wrote:
 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.
> 
> Why not just use the DefaultServlet... that's what it's job
> already is. Or, do you need an image from a database or whatever?
> 
 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.
> 
> You could do your security-checking, and then simply forward() to
> the resource, then let the DefaultServlet actually serve the bytes.
> That allows you to use range-requests, etags, if-modified-since,
> and all that other good stuff.
> 
 So as far as I can see, the only thing not obfuscated is the
 image itself and my ego, which is harmless here.
> 
> What do you need to obfuscate?
> 
> 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.
> 
> Do you need the image to be in an Image object, or do you want to
> put it into an  on the screen? If the latter, just change the
> value of the 'src' of the  and the browser will re-load the
> image from the server.
> 
> -chris
>> 
>> -
>>
>> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWDpzkAAoJEBzwKT+lPKRYSfMP/iGY3efmf9a4KQFbVj48vCT5
ual5F5U/wTtwnzHPoOV7sRVX+kkc1vrzvE+crU8yqwjfxzfulgIY+CY4x8udyd1x
lZvw8skRmOXmLve1EF9298YS7/xS0mwvk6BtxjLxKvpyJ5y4/cqeAfFiDR8k8P8o
foXNud5D8BqeScRIt8C2wBm8AWeodwZXsd3nhoa98q9n3ZbO+fIWKYS4JNKQOTGa
QZ4LOa8iUK215N5vgNoQSUeJcNvkZg5KjYwM637HyF4ro4OnKmqTrws9JjffUFaF
wcZMCc0113okWUx9tcrW9XnbbnA1qBkVtRmlYV4EcI+Ct267wR3jl6sthlSW7YMX
UJKtz3y6umZZckQpjLOqhM7Lwp0hi8lCPt2POVZEP+dYrO5OAG5f0ZidmPUc+GaH
DU810av0rbEBE1Cbydm3wF8m3NAcnmRxmTdx/UIOS/O/PJnO4N6bN4DQ3tm/h6aA
qnRDNGC9b6B6fXGqjHPW9bvrXl6bFkk1NhG8YeWLD9qdIlLrImcOwGzzQrFwBpw0
KhZp4u7I4fG02tA3R56tweNM26lCy2EVtA59G6yoOVuiir47KFdPFb7S5cJMVA/w
3LBbMSwqV4GC6+ejAL7tUHacZOlv2EGGH+EiJTroLGHj4I7371qV2lPidHY4Bp+n
EGQeBtgkbd4/2IiDMCcv
=WBGN
-END PGP SIGNATURE-

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

Re: loading images through a Servlet

[Bill Ross]

I agree it's not a million-dollar idea - I will settle for half! :-) 

Nowadays a lawyer might try for a patent.

Bill

 Original message From: "André Warnier 
(tomcat)" <a...@ice-sa.com> Date:10/02/2015  8:26 AM  (GMT-08:00) 
To: users@tomcat.apache.org Subject: Re: loading images 
through a Servlet 
On 02.10.2015 17:04, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> André,
>
> On 10/2/15 10:38 AM, André Warnier (tomcat) wrote:
>> Chris, you're kind of breaking down an open door here. Bill was
>> already at the stage of congratulating himself and dreaming of his
>> retirement plan, following his discovery of a brilliant and
>> innovative solution. Better to start from the beginning of the
>> thread..
>
> Yep, I read the whole thread.
>
> I don't think this is a million-dollar idea. If it was, I would never
> have gone to college, having written one of these for a client while I
> was in high school. In my case, it was a CGI that counted hits to an
> image whilst simultaneously serving that image. No security or
> anything like that, but the "security" in Bill's case is just a proxy
> for "do something first, then serve an image".
>

It is a bit more than that, though : a user cannot, for example, save the html 
page 
containing the images, and then reload it later, and still see get the images 
with the 
same image links, because they will have "expired". Neither can one of these 
image links 
simply be copied to a friend in an email, and still work for the friend.

He also gets a specific action triggered when someone attempts this.

It is not something infinitely scaleable (the server-side hashtable would get 
quite 
large), but it is a relatively simple scheme, usable in quite a number of 
scenarios.

> I'm suggesting that Bill can focus on his "do something first" task
> and delegate the serving of bytes to a tool more appropriate for the
> task: the DefaultServlet.
>

I would agree with you, except that at some point Bill mentioned serving the 
image content 
out of a database blob.
That's something the Default Servlet couldn't do.



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

Re: loading images through a Servlet

[Bill Ross]

All you need to control the hashtable size (actually DB) is delete every so 
often. But on the other hand I have a record for each showing anyway, so it's 
not introducing a new level of scale to the db.

 Original message From: "André Warnier 
(tomcat)" <a...@ice-sa.com> Date:10/02/2015  8:26 AM  (GMT-08:00) 
To: users@tomcat.apache.org Subject: Re: loading images 
through a Servlet 
On 02.10.2015 17:04, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> André,
>
> On 10/2/15 10:38 AM, André Warnier (tomcat) wrote:
>> Chris, you're kind of breaking down an open door here. Bill was
>> already at the stage of congratulating himself and dreaming of his
>> retirement plan, following his discovery of a brilliant and
>> innovative solution. Better to start from the beginning of the
>> thread..
>
> Yep, I read the whole thread.
>
> I don't think this is a million-dollar idea. If it was, I would never
> have gone to college, having written one of these for a client while I
> was in high school. In my case, it was a CGI that counted hits to an
> image whilst simultaneously serving that image. No security or
> anything like that, but the "security" in Bill's case is just a proxy
> for "do something first, then serve an image".
>

It is a bit more than that, though : a user cannot, for example, save the html 
page 
containing the images, and then reload it later, and still see get the images 
with the 
same image links, because they will have "expired". Neither can one of these 
image links 
simply be copied to a friend in an email, and still work for the friend.

He also gets a specific action triggered when someone attempts this.

It is not something infinitely scaleable (the server-side hashtable would get 
quite 
large), but it is a relatively simple scheme, usable in quite a number of 
scenarios.

> I'm suggesting that Bill can focus on his "do something first" task
> and delegate the serving of bytes to a tool more appropriate for the
> task: the DefaultServlet.
>

I would agree with you, except that at some point Bill mentioned serving the 
image content 
out of a database blob.
That's something the Default Servlet couldn't do.



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

Re: [OT] loading images through a Servlet

[Bill Ross]

Installed FF, HttpFox wasn't installed, installed it but it doesn't show 
up under developer tools, but I found something and here are my headers:


HTTP/1.1 200 OK
Etag: W/"resized_2_33068.jpg-1443146350159"
Last-Modified: Fri, 25 Sep 2015 01:59:10 GMT [random time in 
past 22.32455 days]

Expires: Sun, 01 Nov 2015 19:12:45 GMT
Content-Type: image/jpeg
Content-Disposition: inline;filename="resized_2_33068.jpg"; 
filename*=UTF-8''resized_2_33068.jpg

Content-Length: 157896
Server: Jetty(9.3.4-SNAPSHOT)

Bill

On 10/2/2015 7:17 AM, André Warnier (tomcat) wrote:

On 02.10.2015 12:44, Bill Ross wrote:
Whether or not I have masked the file name in the header properly, 
which I can't verify easily


Oh yes you can.
Mozilla Firefox, plugins, Web Developer, HttpFox.
click and open in its own window.
click start

then get your page (in the main window)

then go back to the HttpFox window, click on a line and use the 
various views available to see exactly what the browser has sent, and 
what the server returned (headers and all).



 but believe is working, I have definitely masked the name in the URL 
and protected myself against later downloads:


HTTP ERROR 404

Problem accessing /images/_ewjMC3. Reason:

 Not Found

While on the server side:

...TagResourceServlet - DANGER OLD HASH ATTACK ...

Will the fame and money just arrive? I'll settle for 6 month's salary 
(that's how long I've been working on my own unpaid :-)




You may want to refine your scheme a tad, thinking of the robots 
(Google etc) which will be exploring your site.  You don't want to be 
swamped by DANGER messages above for trivial cases (nor communicate 
their IP to the XXX sites).


Other than that, your scheme looks nice to me so far.





 Original message From: "André 
Warnier (tomcat)" <a...@ice-sa.com> Date:10/02/2015 2:46 AM  
(GMT-08:00) To: users@tomcat.apache.org 
Subject: Re:[OT] loading images through a Servlet 

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

 Original message From: Bill Ross 
<r...@cgl.ucsf.edu> Date:10/02/2015  2:04 AM  (GMT-08:00) 
To: Tomcat Users List <users@tomcat.apache.org> 
Subject: Re: loading images through a Servlet 
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 : i

Re: [OT] loading images through a Servlet

[tomcat]

On 02.10.2015 21:18, Bill Ross wrote:

Installed FF, HttpFox wasn't installed, installed it but it doesn't show up 
under
developer tools, but I found something and here are my headers:

HTTP/1.1 200 OK
Etag: W/"resized_2_33068.jpg-1443146350159"
Last-Modified: Fri, 25 Sep 2015 01:59:10 GMT [random time in past 
22.32455 days]
Expires: Sun, 01 Nov 2015 19:12:45 GMT
Content-Type: image/jpeg



Content-Disposition: inline;filename="resized_2_33068.jpg";
filename*=UTF-8''resized_2_33068.jpg


isn't that a giveaway still ?


Content-Length: 157896
Server: Jetty(9.3.4-SNAPSHOT)

Bill

On 10/2/2015 7:17 AM, André Warnier (tomcat) wrote:

On 02.10.2015 12:44, Bill Ross wrote:

Whether or not I have masked the file name in the header properly, which I 
can't verify
easily


Oh yes you can.
Mozilla Firefox, plugins, Web Developer, HttpFox.
click and open in its own window.
click start

then get your page (in the main window)

then go back to the HttpFox window, click on a line and use the various views 
available
to see exactly what the browser has sent, and what the server returned (headers 
and all).


 but believe is working, I have definitely masked the name in the URL and 
protected
myself against later downloads:


HTTP ERROR 404

Problem accessing /images/_ewjMC3. Reason:

 Not Found

While on the server side:

...TagResourceServlet - DANGER OLD HASH ATTACK ...

Will the fame and money just arrive? I'll settle for 6 month's salary (that's 
how long
I've been working on my own unpaid :-)



You may want to refine your scheme a tad, thinking of the robots (Google etc) 
which will
be exploring your site.  You don't want to be swamped by DANGER messages above 
for
trivial cases (nor communicate their IP to the XXX sites).

Other than that, your scheme looks nice to me so far.





 Original message From: "André Warnier (tomcat)"
<a...@ice-sa.com> Date:10/02/2015 2:46 AM (GMT-08:00) To:
users@tomcat.apache.org Subject: Re:[OT] loading images through a 
Servlet

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

 Original message From: Bill Ross 
<r...@cgl.ucsf.edu>
Date:10/02/2015  2:04 AM  (GMT-08:00) To: Tomcat Users 
List
<users@tomcat.apache.org> Subject: Re: loading images through a 
Servlet

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 

Re: [OT] loading images through a Servlet

[Bill Ross]

On 10/2/2015 1:55 PM, André Warnier (tomcat) wrote:

On 02.10.2015 21:18, Bill Ross wrote:
Installed FF, HttpFox wasn't installed, installed it but it doesn't 
show up under

developer tools, but I found something and here are my headers:

HTTP/1.1 200 OK
Etag: W/"resized_2_33068.jpg-1443146350159"
Last-Modified: Fri, 25 Sep 2015 01:59:10 GMT [random time in 
past 22.32455 days]

Expires: Sun, 01 Nov 2015 19:12:45 GMT
Content-Type: image/jpeg



Content-Disposition: inline;filename="resized_2_33068.jpg";
filename*=UTF-8''resized_2_33068.jpg


isn't that a giveaway still ?


It gives some random information for someone to chew on, until they find 
this email:


 "resized_" + rand.nextInt(7) + "_" + rand.nextInt(10) + ".jpg"





Content-Length: 157896
Server: Jetty(9.3.4-SNAPSHOT)

Bill

On 10/2/2015 7:17 AM, André Warnier (tomcat) wrote:

On 02.10.2015 12:44, Bill Ross wrote:
Whether or not I have masked the file name in the header properly, 
which I can't verify

easily


Oh yes you can.
Mozilla Firefox, plugins, Web Developer, HttpFox.
click and open in its own window.
click start

then get your page (in the main window)

then go back to the HttpFox window, click on a line and use the 
various views available
to see exactly what the browser has sent, and what the server 
returned (headers and all).



 but believe is working, I have definitely masked the name in the 
URL and protected

myself against later downloads:


HTTP ERROR 404

Problem accessing /images/_ewjMC3. Reason:

 Not Found

While on the server side:

...TagResourceServlet - DANGER OLD HASH ATTACK ...

Will the fame and money just arrive? I'll settle for 6 month's 
salary (that's how long

I've been working on my own unpaid :-)



You may want to refine your scheme a tad, thinking of the robots 
(Google etc) which will
be exploring your site.  You don't want to be swamped by DANGER 
messages above for

trivial cases (nor communicate their IP to the XXX sites).

Other than that, your scheme looks nice to me so far.





 Original message From: "André 
Warnier (tomcat)"
<a...@ice-sa.com> Date:10/02/2015 2:46 AM (GMT-08:00) 
To:
users@tomcat.apache.org Subject: Re:[OT] loading images 
through a Servlet


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

 Original message From: Bill Ross 
<r...@cgl.ucsf.edu>
Date:10/02/2015  2:04 AM (GMT-08:00) To: 
Tomcat Users List
<users@tomcat.apache.org> Subject: Re: loading images 
through a Servlet


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

loading images through a Servlet

[Bill Ross]

Please let me know if there is a better place to ask Servlet/javascript 
interface questions.


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 - ?).


One motivation is to reduce the round trips to the server for faster 
response time.

Another motivation is to keep the filename from the user.

Thanks,
Bill

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

Re: loading images through a Servlet

[Thad Humphries]

The servlet that gets the image is the src for the image. The servlet
should return the correct MIME type for the image (image/jpeg, image/png,
etc). Update the src attribute and the image should update. That's how I do
it. However I'm not writing straight JavaScript. You should put your
question to Stackoverflow.

On Thu, Oct 1, 2015 at 5:52 PM, Bill Ross  wrote:

> Please let me know if there is a better place to ask Servlet/javascript
> interface questions.
>
> 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 - ?).
>
> One motivation is to reduce the round trips to the server for faster
> response time.
> Another motivation is to keep the filename from the user.
>
> Thanks,
> Bill
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 121-24)