-----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 <img> on the screen? If the latter, just change the
> value of the 'src' of the <img> 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

Reply via email to