you will be creating a ton of shared resources - one per file which isnt the
greatest
Why you think it is not good? We don't have too much available files (< 20).
Would it be better to give each file resource a unique name instead of the
empty string?
while being a bit more secure iin terms of what files are available for
download it still allows any user to download them and the urls are still
stable.
Well, how do you suggest to work around that problem? My only idea was to
check the session state within the resource (license agreement accepted),
but I'm not sure what to do when the session state does not allow the
download. But this problem also occurs when making your suggested
implementation save by passing just relative paths (relative to the common
download directory on the server) rejecting invalid (e.g. with "../"
starting) FILE_PARAM values.
--
Cheers,
Tom
Igor Vaynberg wrote:
i thought about that, two drawbacks
you will be creating a ton of shared resources - one per file which isnt the
greatest
while being a bit more secure iin terms of what files are available for
download it still allows any user to download them and the urls are still
stable. so if you are selling downloads this is obviously not going to work
for you.
-igor
On 8/27/07, Thomas Singer <[EMAIL PROTECTED]> wrote:
What do you think about passing the file as constructor parameter in the
FileResourceReference to avoid the security hole (passing the file name as
request parameter)?
--
Cheers,
Tom
Igor Vaynberg wrote:
here is a download link that doesnt block. notice that unlike the
original
it has no security - it's urls are stable and it will stream any file
off
your harddrisk. you can use it as a starting point to build a download
link
suited for your app.
-igor
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version
2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.wicket.markup.html.link;
import java.io.File;
import org.apache.wicket.Resource;
import org.apache.wicket.ResourceReference;
import org.apache.wicket.Response;
import org.apache.wicket.markup.ComponentTag;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.model.IModel;
import org.apache.wicket.protocol.http.WebResponse;
import org.apache.wicket.util.resource.FileResourceStream;
import org.apache.wicket.util.resource.IResourceStream;
import org.apache.wicket.util.value.ValueMap;
/**
* @author Igor Vaynberg (ivaynberg)
*/
public class DownloadLink extends WebMarkupContainer
{
private static final String FILE_PARAM = "file";
private static final long serialVersionUID = 1L;
public DownloadLink(String id, IModel model)
{
super(id, model);
}
protected void onComponentTag(ComponentTag tag)
{
super.onComponentTag(tag);
checkComponentTag(tag, "a");
File file = (File)getModelObject();
FileResourceReference ref = new FileResourceReference();
ValueMap params = new ValueMap();
params.put(FILE_PARAM, file.getAbsolutePath());
tag.put("href", getRequestCycle().urlFor(ref, params));
}
/**
*
* @see org.apache.wicket.markup.html.link.Link#onClick()
*/
private static class FileResourceReference extends ResourceReference
{
public FileResourceReference()
{
super(DownloadLink.class, "");
}
private static final long serialVersionUID = 1L;
protected Resource newResource()
{
return new Resource()
{
private static final long serialVersionUID = 1L;
public IResourceStream getResourceStream()
{
return new FileResourceStream(getFile());
}
protected void configureResponse(Response response)
{
((WebResponse)response).setAttachmentHeader(getFile().getName());
}
private File getFile()
{
return new
File(getParameters().getString(FILE_PARAM));
}
};
}
}
}
On 8/27/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
The blocking is necessary in order not to corrupt session state. We
have
as
fine grained locking as possible (under the circumstances). Web
applications
are by nature multi-threaded. If you don't synchronize the access to
certain
resources (sessions) you can get bugs that are very difficult to trace.
If you need download link, there are alternatives that don't block such
as
shared resource.
-Matej
On 8/27/07, Thomas Singer <[EMAIL PROTECTED]> wrote:
I think the email address is quite obvious.
I'm talking about real addresses. But as Eelco already stated, it
might
be
hard to list them because you are scattered over the world. I'll
accept
that.
Ever heard of open source? Just think about it a little. You have a
product
that a group of people spend lot of time developing and they are
giving
it
to you for free.
Sure, I know the advantages (and disadvantages) of Open Source. I
thank
you
for making Wicket freely available and try to spread good words about
it
(if
possible).
So now just because your problem haven't been fixed in 10
hours, you feel "sick" about it?
No, I just feel (a little bit!) sick, that we've found such a IMHO
major
problem after having invested a couple of weeks work.
It blocks only if that is a component request (it blocks on pagemap).
If
you
have large files you need to use shared resources that don't block.
Also
the
block is only one pagemap only (thus one session) and it lasts only
for
a
minute. No need to restart tomcat server.
Most likely I don't understand the reasons behind the blocking, but
from
a
user's point of view, a *download* never should block the application.
The
timeout (from the server side!) is also not very good for raising the
website-user's trust.
I know we are ab-using Wicket a little bit for a web*site*, but when I
think
on a web*application* like JIRA, I also can't imagine at least one
usecase
(always from my user's point of view) which accepts a timeout or
blocking
when downloading a larger file.
--
Cheers,
Tom
Matej Knopp wrote:
On 8/27/07, Thomas Singer <[EMAIL PROTECTED]> wrote:
Your best bet on getting quick support is to fix it yourself and
send
in a patch.
Well, if that would be possible, I would have done that or worked
around
it
myself (like done with some own components).
http://www.wicket-support.com/
Sorry to say, but I hate websites where you can't find an address on
it.
I think the email address is quite obvious.
What Wicket core developer can provide support (e.g. because (s)he is
working in the mentioned companies)? Or are you "only" working in
your
spare-time on Wicket?
Please understand me: I had a good feeling about Wicket, but this
show-stopper problem makes me feel a little bit sick, because I
don't
know
whether there are other such problems which prevent using Wicket for
our
website at all.
Ever heard of open source? Just think about it a little. You have a
product
that a group of people spend lot of time developing and they are
giving
it
to you for free. So now just because your problem haven't been fixed
in
10
hours, you feel "sick" about it?
BTW, I still have the feeling, that if Wicket provides a feature to
download
something large (except normal pages), it must not block until this
file
is
downloaded. My co-worker told me (I haven't verified), that he
stopped
the
download and this also blocked Wicket. He had to restart Tomcat!
It blocks only if that is a component request (it blocks on pagemap).
If
you
have large files you need to use shared resources that don't block.
Also
the
block is only one pagemap only (thus one session) and it lasts only
for
a
minute. No need to restart tomcat server.
-Matej
--
Best regards,
Thomas Singer
_____________
SyntEvo GmbH
Brunnfeld 11
83404 Ainring
Germany
www.syntevo.com
Eelco Hillenius wrote:
On 8/27/07, Thomas Singer <[EMAIL PROTECTED]> wrote:
Isn't fixing bugs the task of the Wicket developers? We don't have
a
problem
ordering support, but I could not find information where to get
it.
It's unfortunate you have an urgent problem. Sorry about that.
However, everyone of the development team does most of the working
on
Wicket, including following this very time consuming mailing list,
in
their spare time.
Some of us joined in a support initiative:
http://www.wicket-support.com/, and you might be able to get some
very
direct support there. For all I know they are pretty busy right
now.
As long as Wicket doesn't have the same number of users as Spring
of
JBoss, it's going to be very hard to build support that's always
available. And there are the companies listed at
http://cwiki.apache.org/WICKET/companies-that-provide-services.html
like Gerolf said.
Your best bet on getting quick support is to fix it yourself and
send
in a patch. This is not because we're lazy, but because we're very
short on spare time. It may be easier than you think to provide a
patch, and maybe you get hire a wizard programmer somewhere who
knows
his or her way around Wicket.
Regards,
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
