loading images through a Servlet
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
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 motivatio
Re: loading images through a Servlet
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
Date:10/02/2015 2:04 AM (GMT-08:00)
To: Tomcat Users List 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
Re:[OT] loading images through a Servlet
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)" 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 > Date:10/02/2015 2:04 AM (GMT-08:00) > To: Tomcat Users List > 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
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)" 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
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)" 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
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)" 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 Date:10/02/2015 2:04 AM (GMT-08:00) To: Tomcat Users List 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
Re: [OT] loading images through a Servlet
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)" 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 Date:10/02/2015 2:04 AM (GMT-08:00) To: Tomcat Users List 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 bett
configuring login for static content and Servlets
Is it possible to set up a site so that you have to log in to access the site at all, either the static content or the servlet interface? I have in mind 10-100 users. It seems a simple setup like .htaccess (httpd only?) would be perfect if it existed and covered static and servlet. Is this doable in Tomcat? I have been struggling to get it working in Jetty, but it doesn't seem well-supported there. Thanks, Bill - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
