see all these kinds of questions start coming up, that is why download link is made the way it is. you have none of these worries and it is very secure by default. so i think when it comes to these issues what i will be concentrating on is making downloadlink not block. whether it will be for 1.3 or for 1.4
-igor On 8/27/07, Thomas Singer <[EMAIL PROTECTED]> wrote: > > > 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] > >
