On a side note, both of my options (using the User object and using a
persisted field) will result in only being able to show one
StreamResponse at a time (otherwise they would both show the same). I
could extend this by having some kind of data structure (hashmap?) in
the User object and passing a token which is valid only to that user
as a parameter, but I think i'm so far off the mark.. there must be an
easier way.
On 24 October 2013 16:32, Steve <steves...@gmail.com> wrote:
> Hi,
>
> I think I am doing something very, very wrong. What I have currently
> works - but I get a feeling that it's not the best way of doing it.
> I'm hoping for a little bit of advice again (sorry to ask so many
> questions recently, and sorry this is a long one).
>
> This is the issue:
> I have some dynamic files with file paths which depend on the user.
> Previously, all of those files existed on the context which was bad
> news because it meant if a user knew the URL, they could download any
> file. Without going into S3 servers for now (I can't unfortunately as
> I have a monstrously huge pile of ethics forms to fill out if I want
> to do that), I want to be able to embed these files on the page for a
> user to see once they have logged in.
>
> My solution has been to create a page named "FileStreamResponse" which
> returns a StreamResponse from the onActivate method. I then can do the
> following from another page class to get a link to that file.
>
> @Inject ComponentResources resources;
> public Link getStaticFileLink() {
> return resources.createPageLink("util/FileStreamResponse", true);
> }
>
> In the TML, I can use that link to embed it. This works for one file,
> which I have tested as "C:/file.xml" for now, but of course if anyone
> visits the link for /util/FileStreamResponse they get the same file.
> However, what I should be able to do is pass a parameter containing
> information about which file to show to the FileStreamResponse page.
>
> For my first attempt is to pass a parameter, I tried this:
> return resources.createPageLink("util/FileStreamResponse", true,
> "C:/file.xml");
>
> This creates a link like this:
> http://localhost:8080/xyz/util/filestreamresponse/C:$002ffile.xml
>
> If I pick that up in the onActivate for the page it works.
>
> However, this isn't good because the the param is passed in the URL
> which again means anyone can view that link, unless I put a lot of
> permissions logic in that filestreamresponse class which already
> exists elsewhere then i'm a little stuck.
>
> So I know of one more solution to passing this parameter but it seems
> like a bit too much of a "hack" for even me.
> I create a setup method in the filestreamresponse page which takes in
> a filename and sets it. It persists the property. Then I just use the
> link to that page and it should show the correct file. Like this:
>
> @InjectPage
> private FileStreamResponse fsr;
> @Inject ComponentResources resources;
>
> public Link getStaticFileLink() {
> fsr.setup("C:/file.xml");
> return resources.createPageLink("util/FileStreamResponse", true);
> }
>
> I believe that now the user cannot change that parameter so it should
> be safe. However, this doesn't seem right to me. It seems very.. very
> bad and i'm sure someone will tell me exactly that. Another option is
> to have the file which is requested stored in the User object which I
> have in the sessionstate but again I don't think that is a good way to
> do it.
>
> If I put the logic for testing permissions in to the page class, I
> still need to pass something to that page class to tell it which file
> to show, and i'd rather that not show in the URL.
>
> I'm sure others have had a similar problem and there is a standard way
> to do this which I am missing, I would really appreciate any guidance.
> Perhaps what I am doing is perfectly OK, but I suspect not as it leads
> to issues such as, even if the user logs out, if the value is
> persisted then they would see that file if re-visiting the link.
> (Unless it is indeed stored in the User object).
>
>
> Thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
