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] > >
