|
From: Dylan J. <dj...@pr...> - 2014-09-25 04:42:04
|
On 25 Sep 2014, at 11:17 am, Johannes Raggam <rag...@ad...> wrote: > I also run into this problem today and factored out gotcha's code > regarding https://dev.plone.org/ticket/13793 from > https://github.com/plone/Products.CMFPlone/tree/publication-through-explicit-acquisition > into a seperate package: > > https://github.com/collective/collective.explicitacquisition > > That's exactly his implementation as a separate package. Easy and > unobtrusive to include, and got no problems with it so far. > > Mauro, which problems with image scaling did you have? I didn't encouter > problems until now... I notice it doesn't also fix the case of dirs being acquired. For example news/item1 sub/news/item1 If sub/news was deleted from sub it's urls would still work and not raise a 404. Anyone see a reason not to extend this patch to disallow acquisition of any part of the path, not just the context? > > Cheers, Johannes > > On Thu, 2014-08-21 at 08:59 -0500, Nathan Van Gheem wrote: >> Wow, that'd be great if you looked into this! >> >> >> Does anyone know what happened to the zope4 branch work way back when >> before politics got involved(maybe I'm off base)? I'm not sure all >> that this branch did but I think it at least gave us a webob based >> request object. >> >> >> IMO, I'd like to see plone on pyramid or a forked zope2 that strips >> out a lot of the magic and is for plone specifically(maybe). *ducks* >> >> >> On Thu, Aug 21, 2014 at 4:09 AM, Mauro Amico <mau...@gm...> >> wrote: >> >> On Wed, Aug 20, 2014 at 10:06 AM, Dylan Jay >> <dj...@pr...> wrote: >> The fix mentioned by Steven is simpler than changing >> traversal and seems reasonable to me. >> Basically if you are going to publish something that >> has an acquisition url, then raise a 404 instead. >> >> https://github.com/plone/Products.CMFPlone/commit/e20ea907d2854ee7ad41e9953b64889ee7431b49 >> >> >> >> Looks good for me. >> >> But looking more depth I see that comparing pysicalpath and >> parents could be not ever so easy, at least I found that >> traverse for image scaling doesn't work as expected: >> >> >> http://localhost:8080/Plone/foo/@@images/da05bfd9-0fca-4c5f-b02d-f981b47a0788.jpeg >> >> >> >> request['PARENTS'] >> >> [<plone.namedfile.scaling.ImageScale object at 0xafd3292c>, >> <Products.Five.metaclass.ImageScaling object at 0xafd32aec>, >> <Image at /Plone/foo>, <PloneSite at /Plone>, <Application at >>> ] >> >> I don't know if the problem is only for some or all custom >> traverser, and if it could be solved skipping not contentish >> items from parents. >> >> >> I agree with Martin and Nathan that "hacking" traversal could >> be risky and for sure I trust your experience, but I think >> that is a really annoying problem for many people using Plone >> at this moment. For sure it is for me... >> >> >> I'm thinking to create an experimental package, probably >> starting from Godefroid code, so people can starts to testing >> it also before "publication-through-explicit-acquisition" >> merge. >> >> IMHO a full rewriting of publisher could be for next major >> Plone release (6 ?). I'm happy to help for that, if needed. >> >> >> Mauro. >> >> >> >> >> >> >> On 20 Aug 2014, at 2:52 pm, Martin Aspeli >> <opt...@gm...> wrote: >> >>> I once had a burning desire to clean up the mess >> that is the publisher. I spend a long time trying to >> just document what it does and how it works. The >> results are here: >>> >>> http://docs.zope.org/zope_secrets/ >>> >>> I suggest you sit down. >>> >>> I don't think it's possible to make it much better >> without braking some backward compatibility. There are >> a million old hooks used in one or two places that >> just need to go. >>> >>> If we are to clean it up, I'd look at repoze.zope2 >> as a starting point. That code is much better and much >> better tested, although now slightly out of date. >>> >>> Martin >>> — >>> Sent from Mailbox >>> >>> >>> On Wed, Aug 20, 2014 at 12:55 AM, Nathan Van Gheem >> <na...@va...> wrote: >>> >>> Okay, I'll take a short crack on this with some >> thoughts. >>> >>> - The traversal side affects shouldn't matter unless >> you're directly linking to them? How come your links >> are getting messed up? >>> - Changing zope2 traversal will likely have a lot of >> side affects. That being said, it's unpredictable and >> unusual behavior for most people. There is a lot of >> history and a lot of code that perhaps depends on it. >> Shooting from the hip, tightening up traversal is >> something that may be possible in the next major >> release of Plone(6). However, maybe by then we have >> some ideas on moving the traversal over to pyramid? :) >>> - some people find acquisition powerful and use it >> to solve problems in some wonky ways... >>> - I would think any changes like this to traversal >> are potentially very high risk with low benefits. This >> might not be an important problem to tackle for you >> right now :( >>> >>> Anyways, just some thoughts... >>> >>> >>> -Nathan >>> >>> >>> On Tue, Aug 19, 2014 at 4:02 AM, Mauro Amico >> <mau...@gm...> wrote: >>> I want to share a problem that I have with >> ''publishTraverse'' and ''acquisition''. >>> >>> The Problem >>> ----------- >>> >>> My problem with “acquisition” and publishTraverse is >> that the current method returns too many different >> URLs for the same content. For instance here is some >> potential url for the “kb” page of the plone.org >> website >>> >>> https://plone.org/documentation/kb >>> https://plone.org/documentation/manual/kb >>> https://plone.org/documentation/kb/manual/kb >>> >> https://plone.org/documentation/manual/spinner.gif/kb >>> ... >>> >>> and here is a generic "Plone" site with two content >> items "a" and "b" (folderish or not) >>> >>> http://example.com/Plone/a >>> http://example.com/Plone/a/b/a >>> http://example.com/Plone/a >>> http://example.com/Plone/b/a >>> ... >>> >>> All the urls above returns 200 with the same >> content, while I would like the "canonical url" to >> return 200 and the other to return 404. >>> >>> The behaviour described above constitute a problem >> because: >>> >>> * multiple url for the same content is a problem for >> SEO and is confusing to >>> people. For SEO, in the latest versions Plone >> introduced the canonical META, >>> but IMHO it's just a workaround. People are >> confused. For example: sometimes >>> some of my editors ask me: "I can't remove the >> http://example.com/Plone/a/b/a/ >>> page. Can you do it for me?" >>> >>> * the page doesn’t seem really the same on all urls: >> if you open >>> https://plone.org/documentation/kb and >>> https://plone.org/documentation/manual/kb the >> second has a >>> portlet that the first is missing >>> >>> * removing page from external cache (varnish or >> squid), for example after a >>> content modification, will be a pain, because for >> the same content there >>> could be multiple urls without any control or >> rules (collective.purgebyid >>> solve this) >>> >>> * when using subsite (or multiple plone site on the >> same zope app) the problem is >>> even more annoying: suppose that "a" is a subsite >> (marked with >>> INavigationRoot) for http://a.example.org and "b" >> for http://b.example.org, >>> opening the url http://a.example.org/b will >> probably show the homepage of site >>> "a" inside the "b" site (collective.siteisolation >> and probably collective.lineage do >>> something to isolate subsite, but IMHO again are >> only workarounds) >>> >>> Are there other people with the same doubts and >> problems? >>> >>> Does anybody have a good and stable solution for >> that? >>> >>> My analysis >>> ----------------- >>> >>> I tried to look in depth and identified a possible >> source of the problem mentioned in: >>> >>> >> https://github.com/zopefoundation/Zope/blob/2.13.21/src/ZPublisher/BaseRequest.py#L122 >>> >>> # And lastly, of there is no view, >> try acquired attributes, but >>> # only if there is no >> __bobo_traverse__: >>> try: >>> subobject=getattr(object, name) >>> # Again, clear any error status >> created by __bobo_traverse__ >>> # because we actually found >> something: >>> request.response.setStatus(200) >>> except AttributeError: >>> pass >>> >>> >>> I found many solutions (like >> collective.siteisolation) that work on higher level >>> with IPublishTraverse adapter, but in my opinion the >> problem is with all traversing >>> (e.g. >> https://plone.org/documentation/manual/spinner.gif/kb), so I think that at the end the best solution could be to modify the default traverser (or something >>> like that). >>> >>> In a site in production using Plone 4.2, all content >> are Dexterity, no >>> portlet, I added a log: >>> >>> + import logging >>> + logger = >> logging.getLogger('analyze.publishTraverse') >>> >>> ... >>> # And lastly, of there is no view, >> try acquired attributes, but >>> # only if there is no >> __bobo_traverse__: >>> try: >>> subobject=getattr(object, name) >>> + logger.warning("obj:%r name:%r >> meta_type:%r", >>> + object, name, >> getattr(aq_base(subobject), 'meta_type, '-') >>> + ) >>> # Again, clear any error status >> created by __bobo_traverse__ >>> # because we actually found >> something: >>> request.response.setStatus(200) >>> except AttributeError: >>> pass >>> >>> After three weeks I checked the logs: some wrong >> urls that I preferred they responded 404 and many >> "false positive", which were fortunately all well >> known: portal_skins object("FileSystem Script", ...), >> Registry object ("portal_css", >> "portal_javascript", ...) and the "Virtual Host >> Monster" object. >>> >>> Probably I will extend logging period up to the >> second week of September, after that I'm thinking to >> monkey patch the method with something like: >>> >>> # And lastly, of there is no view, >> try acquired attributes, but >>> # only if there is no >> __bobo_traverse__: >>> try: >>> subobject=getattr(object, name) >>> + meta_type = >> getattr(aq_base(subobject), 'meta_type, None) >>> + if >> meta_type.startswith('Dexterity ') or meta_type == >> 'Plone Site': >>> + subobject = None >>> + raise AttributeError >>> # Again, clear any error status >> created by __bobo_traverse__ >>> # because we actually found >> something: >>> request.response.setStatus(200) >>> except AttributeError: >>> pass >>> >>> Or >>> >>> # And lastly, of there is no view, >> try acquired attributes, but >>> # only if there is no >> __bobo_traverse__: >>> try: >>> subobject=getattr(object, name) >>> + meta_type = >> getattr(aq_base(subobject), 'meta_type, None) >>> + if >> meta_type.startswith('Filesystem '): >>> + pass # e.g. object inside >> portal_skins >>> + if meta_type.endswith(' >> Registry'): >>> + pass # e.g. portal_css >>> + if meta_type == 'Virtual Host >> Monster: >>> + pass # e.g. VHM >>> + else: >>> + subobject = None >>> + raise AttributeError >>> # Again, clear any error status >> created by __bobo_traverse__ >>> # because we actually found >> something: >>> request.response.setStatus(200) >>> except AttributeError: >>> pass >>> >>> >>> Opinions? >>> Ideas? >>> Better solutions (I really don’t like monkey patch >> Zope2’s ZPublisher)? >>> >>> Thanks for the patience to read until here. >>> >>> >>> >> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Plone-developers mailing list >>> Plo...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/plone-developers >>> >>> >>> >>> >>> -- >>> Nathan Van Gheem >>> Solutions Architect >>> Wildcard Corp >>> >> >>> >> ------------------------------------------------------------------------------ >>> Slashdot TV. >>> Video for Nerds. Stuff that matters. >>> >> http://tv.slashdot.org/_______________________________________________ >> >>> Plone-developers mailing list >>> Plo...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/plone-developers >> >> >> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> >> _______________________________________________ >> Plone-developers mailing list >> Plo...@li... >> https://lists.sourceforge.net/lists/listinfo/plone-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> Plone-developers mailing list >> Plo...@li... >> https://lists.sourceforge.net/lists/listinfo/plone-developers >> >> >> >> >> >> -- >> Nathan Van Gheem >> Solutions Architect >> Wildcard Corp >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> Plone-developers mailing list >> Plo...@li... >> https://lists.sourceforge.net/lists/listinfo/plone-developers > > -- > programmatic web development > di(fh) johannes raggam / thet > python plone zope development > plone framework team member > mail: of...@pr... > web: http://programmatic.pro > http://bluedynamics.com > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________ > Plone-developers mailing list > Plo...@li... > https://lists.sourceforge.net/lists/listinfo/plone-developers |