There's just one question: how to prevent XSS for JSONP ? Regards Felix
On 09.04.2010 23:06, Felix Meschberger wrote: > Hi, > > On 09.04.2010 22:45, Justin Edelson wrote: >> On 4/9/10 3:58 PM, Felix Meschberger wrote: >>> Hi, >>> >>> On 09.04.2010 21:32, Justin Edelson wrote: >>>> Hmmm. You're right - I conflated extension with suffix. >>>> >>>> On 4/9/10 3:10 PM, Luca Masini wrote: >>>>> Great, I never considered RequestDispatcherOptions and I think it's a >>>>> good idea. >>>>> >>>>> But with replaceSuffix I go into an infinity cycle, because the servlet >>>>> is choosen by the "jsonp" extension and not as a suffix: >>>>> >>>>> req.getRequestDispatcher(req.getResource().getPath(), new >>>>> RequestDispatcherOptions("replaceSuffix=json")).include(req, resp); >>>>> >>>>> >>>>> What is wrong with me ??? >>>>> >>>>> Also, how can I associate a script like the one you showed to an >>>>> extension ?? >>>> Create it at /apps/sling/servlet/default/jsonp.esp >>>> >>>> It doesn't look like there's a way to override the extension via >>>> RequestDispatcherOptions. I guess what you can do is just hack the last >>>> letter off the path (assuming you're using jsonp as the extension). But >>>> now I have a bad taste... >>>> >>>> I can't think of a good reason why this is the case. It seems like there >>>> should be a replaceExtension=json option. >>> >>> You could to >>> >>> req.getRequestDispatcher(req.getResource.getPath()+".jsonp").... >> AFAICT, this won't work (and would need to be ".json" anyway) because >> you lose all the selectors. i.e. > > Sure, this was just a no-brainer example ;-) > >> >> /foo/bar/res.tidy.jsonp (resource path = /foo/bar) >> should be a padded version of >> /foo/bar/res.tidy.json >> >> but if you just replace tack on the extension to the resource path, it >> would be /foo/bar/res.json. >> >> Obviously you could recreate the selectors if you needed to, but this is >> why it seems to me that replaceExtension would be useful. I see a typo >> in what I wrote... it should be: >> <%= request.getParameter("jsonp") %>(<% sling.include(resource, >> "replaceExtension=json") %>) >> >>> >>> to overwrite the request extension. >>> >>> But: we didn't do this by intent: Since we assume an expected content >>> type from the request extension changing the extension for request >>> processing might interfere with these expectations. >> >> Maybe I'm missing something, but how could it interfere? >> >> If I have html.esp, what is the harm in being able to include the result >> of txt.esp or json.esp? The response content type is still text/html. I >> agree that this probably wouldn't be very common, but I don't see the harm. >> >>> >>> Now, what would hinder use to add support for JSONP in our JSON servlets >>> ? We could, for example add JSONP servlets to the Default GET Servlet >>> bundle which internally use the existing servlets but add the padding. >> >> Time ;) > > Hehe. > > Well, for the JsonQueryServlet it is probably even simpler (and amounts > to a four-some liner: > > if (request.getParameter("padding") != null) { > response.write("padding("); > } > ... do the rest > if (request.getParameter("padding") != null) { > response.write(");"); > } > > For the JsonRenderer, we might consider using a suffix or also a request > parameter. > > Regards > Felix > >> >> Justin >> >>> >>> Regards >>> Felix >>> >>>> >>>> Justin >>>> >>>> >>>> >>>>> >>>>> Thank you for your help. >>>>> >>>>> On Fri, Apr 9, 2010 at 8:05 PM, Justin Edelson <justinedel...@gmail.com >>>>> <mailto:justinedel...@gmail.com>> wrote: >>>>> >>>>> These two servlets are used in different contexts, so it makes sense >>>>> that you'd use different patterns for each of them. Your approach to >>>>> the >>>>> JsonQueryServlet looks fine to me. For the renderer servlet, I would >>>>> be >>>>> more inclined to create a script registered with the "jsonp" extension >>>>> which is basically this: >>>>> >>>>> <%= request.getParameter("jsonp") %>(<% >>>>> sling.include(resource.getPath(), "replaceSuffix=json") %>) >>>>> >>>>> Justin >>>>> >>>>> On 4/7/10 4:52 PM, Luca Masini wrote: >>>>> > Yes, that can be great, but I don't want to change Sling sources, >>>>> only >>>>> > reuse them, that's why I asked about best practices. >>>>> > >>>>> > On Wed, Apr 7, 2010 at 9:58 PM, Justin Edelson >>>>> <justinedel...@gmail.com <mailto:justinedel...@gmail.com> >>>>> > <mailto:justinedel...@gmail.com <mailto:justinedel...@gmail.com>>> >>>>> wrote: >>>>> > >>>>> > We should probably just support jsonp natively in these >>>>> servlets. >>>>> > >>>>> > >>>>> > On 4/7/10 2:05 PM, Luca Masini wrote: >>>>> > > Hi guys, I need an advice from Sling experts. >>>>> > > >>>>> > > I need a JSONP renderer for Sling, initially I thought I had >>>>> to >>>>> > develop only >>>>> > > one, but after I discovered that in effect Sling has two >>>>> renderer >>>>> > for JSON, >>>>> > > one for plain resources and one for query. >>>>> > > >>>>> > > These two renderer are in private packages in a Sling >>>>> Bundle, and >>>>> > because >>>>> > > JSONP and JSON are quite equals and I wanted to reuse as much >>>>> as >>>>> > possible, I >>>>> > > started thinking about strategies to call them. >>>>> > > >>>>> > > The JsonQueryServlet is deployed as an OSGi Component, so I >>>>> was >>>>> > able to >>>>> > > inject it using Felix SCR Annotation (querying for his >>>>> > properties), and then >>>>> > > I called his service() method inside my doGet: >>>>> > > >>>>> > > servlet.service(req, resp); >>>>> > > >>>>> > > For the JsonRendererServlet instead I used another strategy. >>>>> > > >>>>> > > I extracted the RequestPathInfo from the >>>>> SlingHttpServletRequest >>>>> > and the I >>>>> > > included it using RequestDispatcher: >>>>> > > >>>>> > > String jsonPath = calculateIt(req); >>>>> > > >>>>> > > req.getRequestDispatcher(jsonPath).include(req, resp); >>>>> > > >>>>> > > Now both of these two are working, but I have a bad taste. >>>>> > > >>>>> > > Which of this is the best approach ?? The first ?? The second >>>>> ?? >>>>> > None of >>>>> > > them ??? >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > **************************************** >>>>> > http://www.lucamasini.net >>>>> > http://twitter.com/lmasini >>>>> > http://www.linkedin.com/pub/luca-masini/7/10/2b9 >>>>> > **************************************** >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> **************************************** >>>>> http://www.lucamasini.net >>>>> http://twitter.com/lmasini >>>>> http://www.linkedin.com/pub/luca-masini/7/10/2b9 >>>>> **************************************** >>>> >>>> >> >>