You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Russell Edwards <Ru...@csiro.au> on 2004/11/18 06:27:20 UTC
Necessity of IAsset.getResourceAsStream() ?
Hi,
I'm about to write a custom service for sending out small images
stored in a database (or images with filesystem paths stored in the
db). These are still conceptually assets so I figured I'd make a
corresponding DBImageAsset class which constructs a URL that invokes
the new service "dbimage". However I was suprised to see the existence
of IAsset.getResourceAsStream() . I grepped around in the code and it
looks like the only place it's used is in getting templates and other
config file type things. It seems to me that these things are
conceptually different to assets that will be streamed to a user as-is,
so the use of the same Implementation is confusing to me. Is this a
fair statement? And, am I right in thinking I could just give "return
null" as my implementation of getResourceAsStream() in my case?
Russell
P.S. While I have your attention, on a similar topic, has there been
any update on the gaping security hole of sucking .class files through
AssetService, mentioned on this list some 2 years ago?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Necessity of IAsset.getResourceAsStream() ?
Posted by Markus Wiederkehr <ma...@gmail.com>.
I did exactly the same thing as you and ran into exactly the same
problem. IAsset has two flaws: 1) it is rarely documented and 2) it
contains methods that should be in a separate interface.
If you want to serve images the only method that actually has to be
implemented is buildURL(). Look into ChartAsset and CharService of the
Workbench example that comes with Tapestry. The ChartAsset was written
by Howard, so I think it is reliable.
Markus
On Thu, 18 Nov 2004 16:27:20 +1100, Russell Edwards
<ru...@csiro.au> wrote:
> Hi,
>
> I'm about to write a custom service for sending out small images
> stored in a database (or images with filesystem paths stored in the
> db). These are still conceptually assets so I figured I'd make a
> corresponding DBImageAsset class which constructs a URL that invokes
> the new service "dbimage". However I was suprised to see the existence
> of IAsset.getResourceAsStream() . I grepped around in the code and it
> looks like the only place it's used is in getting templates and other
> config file type things. It seems to me that these things are
> conceptually different to assets that will be streamed to a user as-is,
> so the use of the same Implementation is confusing to me. Is this a
> fair statement? And, am I right in thinking I could just give "return
> null" as my implementation of getResourceAsStream() in my case?
>
> Russell
> P.S. While I have your attention, on a similar topic, has there been
> any update on the gaping security hole of sucking .class files through
> AssetService, mentioned on this list some 2 years ago?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Necessity of IAsset.getResourceAsStream() ?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Nov 17, 2004, at 9:27 PM, Russell Edwards wrote:
> P.S. While I have your attention, on a similar topic, has there been
> any update on the gaping security hole of sucking .class files through
> AssetService, mentioned on this list some 2 years ago?
I haven't looked at the main issue of your post.
As for the gaping security hole - it still exists. There are
workarounds such as using a servlet filter or web server configuration
to prevent all but a certain pattern of asset service URL's to pass
through to the application server.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org