hi Alex On Jan 14, 2015, at 4:14 AM, Alexander Klimetschek <[email protected]> wrote:
> The use case is SLING-3829 - does this necessarily require the change? It > could be a normal servlet filter that checks the paths itself, right? true, this can be done and it is was many other filter have been doing. That is why would be good to handle this boilerplate out of the box (IMHO). At the end of the day this is already possible for Apache Felix filters. > > From the use case description in http://markmail.org/message/czrlmikxe2fj6sx4 > you refer to uploaded files... I could imagine the configurable evolves to > something other than just path patterns, where you'd have to check these in > the filter anyway. a resource type based filter has been also proposed and could also be added (and it makes also sense if you ask me :))/ > > And why does it require a servlet filter and is not a feature of the default > Sling GET servlet? To catch all servlets who provide a "download"? But what > if you have a custom servlet where you know you want a certain mime type and > not the force-download one? that is the point indeed. Under certain locations (e.g. where a user can upload his own content) you do not want to serve this content as is, hence the Content-Disposition attachment header. This must be true in all the cases being it a default Sling GET servlet or a custom servlet. A better solution would be to support sandbox domain for user generated content (e.g. http://foo.usercontent.com), since we do not have yet this feature (just yet..) the mitigation we can use here is the Content-Disposition attachment header mentioned in SLING-3829 regards antonio > > Cheers, > Alex > > >> On 13.01.2015, at 02:12, Antonio Sanso <[email protected]> wrote: >> >> hi *, >> >> I have tracked the issue and added a straw man patch in >> https://issues.apache.org/jira/browse/SLING-4294 >> >> WDYT? >> >> regards >> >> antonio >> >> On Dec 5, 2014, at 12:00 PM, Felix Meschberger <[email protected]> wrote: >> >>> Hi >>> >>> The point is that we should implement what we need and ignore what we don’t >>> need. >>> >>> For some use cases it would indeed be good to be simply able to filter on >>> the URL path (or resource path) like in the Servlet API itself. Consider >>> for example a content management system where you want to apply a filter to >>> all requests to user generated content which might live at /content/public. >>> >>> For other cases, being able to filter on a resource type is more >>> appropriate. Again, consider a content management system and you want to >>> apply the filter to all requests for web page resources of resource type >>> cms/webpage. >>> >>> Then there is a combination even, where you might have resources spread all >>> over but you want to apply the filter only to, say, web pages in user >>> generated content, so you filter on the /content/public location further >>> finer graining it to cms/webpage. >>> >>> These could be use cases. Do we need it ? I don’t know. For SLING-3829 it >>> would be use full to have it. >>> >>> Regards >>> Felix >>> >>>> Am 05.12.2014 um 11:07 schrieb Antonio Sanso <[email protected]>: >>>> >>>> hi Julian >>>> >>>> On Dec 5, 2014, at 10:31 AM, Julian Sedding <[email protected]> wrote: >>>> >>>>> Hi Antonio >>>>> >>>>> I agree with Justin that we should start with support for resource-types. >>>> >>>> as said I agree we should have support for both. >>>> E.g. sling.filter.pattern, sling.filter.resourceType >>>> >>>> >>>>> >>>>> Using path-based restrictions strongly couples configuration to >>>>> content, which IMO is not a good practice. >>>> >>>> At the end of the day is the developer choice to choose the one she needs. >>>> In my case for example I cannot use the resource type approach. >>>> See also https://issues.apache.org/jira/browse/SLING-3829 >>>> >>>> regards >>>> >>>> antonio >>>> >>>>> >>>>> Regards >>>>> Julian >>>>> >>>>> >>>>> On Thu, Dec 4, 2014 at 3:54 PM, Antonio Sanso <[email protected]> wrote: >>>>>> thanks Justin for your feedback, >>>>>> >>>>>> if you would not mind I would try to do the opposite :) >>>>>> The only reason is that I have already a Pocs for this that it actually >>>>>> requires really few modifications.. (Felix gave me some good hints on >>>>>> how to implement it :)) >>>>>> It would probably be the same for resource type though :) >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>> On Dec 4, 2014, at 2:29 PM, Justin Edelson <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Antonio, >>>>>>> I'd suggest starting with support for resource type and *then* add path >>>>>>> support. >>>>>>> >>>>>>> Justin >>>>>>> >>>>>>> On Thu, Dec 4, 2014 at 5:46 AM, Antonio Sanso <[email protected]> wrote: >>>>>>>> hi *, >>>>>>>> >>>>>>>> the current Sling Servlet Filter Support [0] allows to have scope >>>>>>>> dependent filter (e.g. REQUEST, INCLUDE, FORWARD, ERROR, COMPONENT). >>>>>>>> It would be nice to extend this support to have a specific filter >>>>>>>> being taken in consideration only for specific path (adding >>>>>>>> sling.filter.pattern) a bit like what currently can be done for Apache >>>>>>>> Felix filters. >>>>>>>> >>>>>>>> WDYT? >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> antonio >>>>>>>> >>>>>>>> [0] http://sling.apache.org/documentation/the-sling-engine/filters.html >>>>>> >>>> >>> >> >
