Re: publishTraverse, acquisition and multiple urls for the same content

Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]>
Newsgroups gmane.comp.web.zope.plone.devel
Message-ID <[email protected]>
On 25 Sep 2014, at 11:17 am, Johannes Raggam <[email protected]> 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 <[email protected]>
>> wrote:
>> 
>>        On Wed, Aug 20, 2014 at 10:06 AM, Dylan Jay
>>        <djay-n0pU0XVUApFWk0Htik3J/[email protected]> 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
>>                <[email protected]> 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
>>                <[email protected]> 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
>>                <[email protected]> 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
>>> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> 
>>                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
>>> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> 
>>                https://lists.sourceforge.net/lists/listinfo/plone-developers
>> 
>> 
>> 
>>                ------------------------------------------------------------------------------
>>                Slashdot TV.
>>                Video for Nerds.  Stuff that matters.
>>                http://tv.slashdot.org/
>> 
>>                _______________________________________________
>>                Plone-developers mailing list
>>                Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>                https://lists.sourceforge.net/lists/listinfo/plone-developers
>> 
>> 
>> 
>> 
>>        ------------------------------------------------------------------------------
>>        Slashdot TV.
>>        Video for Nerds.  Stuff that matters.
>>        http://tv.slashdot.org/
>>        _______________________________________________
>>        Plone-developers mailing list
>>        Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>        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
>> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> 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: office-//[email protected]
> 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
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
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
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers
signature.asc (application/pgp-signature, 495 B)
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJUI50HAAoJEArtmGaudi+Q02YH/2of1Akfd2+zCtScv6/uyeJ5
Wfu+t4/9vzTSlfbfCq88t95D/zDtfnAGiE7fzEjiQIAClD00fMaQ6d+FuuGwWEng
m871hUiXv+DBMcumss9PmcggAmTpXum6YAIgx37ayitQ6vcFYIlS6e2VL5Uf/BP2
QLEbDWAsWNlRcIWScIaqIa3BWZmAUk0NfEMario48WpG5cAb4QxGP0MmyhaB3ZRx
G6xqBxz61WazoR78uWqxO9V+fTXHsImCNEEx2pv5RXBuB9dJkM29ev7GecdB4wva
gXrK7lj3pmpU2/aZf27R5I/jv+C3VSno+SAUmRZSNFXbybppYDuu6WPkdwmDf8E=
=fCl9
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.