Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It's possible to "kill" the server with a wrong URL #99

Closed
pysailor opened this issue Dec 13, 2013 · 8 comments
Closed

It's possible to "kill" the server with a wrong URL #99

pysailor opened this issue Dec 13, 2013 · 8 comments

Comments

@pysailor
Copy link
Member

This might only affect the OiRA site, but a Euphorie component is involved:
For OiRA we have 2 separate URLs, one for the "admin" side, one for the client. The client URL points via virtual hosting to the folder /client.

If you're working in the admin site, you might copy over your current URL (including the sectors folder) to the client, e.g. like this
https://client.oiratest.syslab.com/sectors/eu/private-security/

For the user, the request simply times out. The site remains unresponsive after that. In the zope log we get:

  [...]
  File "/home/oira/oira/eggs/Products.PluggableAuthService-1.9.0-py2.6.egg/Products/PluggableAuthService/PluggableAuthService.py", line 1091, in challenge
    if challenger.challenge(request, response):
  File "/home/oira/oira/eggs/Euphorie-6.1.4_slc-py2.6.egg/euphorie/client/authentication.py", line 197, in challenge
    context = request.PUBLISHED
  File "/home/oira/oira/eggs/Zope2-2.13.19-py2.6.egg/ZPublisher/HTTPRequest.py", line 1390, in __getattr__
    raise AttributeError, key
AttributeError: PUBLISHED

Maybe it would be enough to replace this line https://github.com/euphorie/Euphorie/blob/master/src/euphorie/client/authentication.py#L197
with

        context = getattr(request, 'PUBLISHED', None)
        if not context:
            return False
@wichert
Copy link
Contributor

wichert commented Dec 18, 2013

I would like to understand the root cause before we apply this workaround. In what situations will a request not have a PUBLISHED attribute?

@pysailor
Copy link
Member Author

The way I understand it, this happens when the "sectors" folder is called (via Acquisition) on the "client" folder. To reproduce, try a URL like
http://localhost:8080/Plone/client/sectors

@wichert
Copy link
Contributor

wichert commented Dec 18, 2013

The Zope publisher should still set a PUBLISHED attribute as far I know. I would like to know under what conditions it does not do that. Only then can we be sure we have the right fix.

@pysailor
Copy link
Member Author

I added a failing test to illustrate the problem.

@wichert
Copy link
Contributor

wichert commented Dec 20, 2013

Tracing Zope traversal logic what happens is this:

  • Request comes in for /plone/client/sectors.
  • Normal traversal happens, which ends up at <SectorContainer at /plone/sectors used for /plone/client> as expected.
  • An IBrowserPublisher adapter is consulted to view determine the view. This uses plone.dexterity.browser.traversal.DexterityPublishTraverse and returns (u'@@index_html',).
  • Traversal proceeds to get the @@index_html``view, which results in a``NotFound exception. This happens we only have a view for the NuPloneSkin layer, which is not present in the client. This is also why PUBLISHED is never set on the request.
  • The publisher's error logic kicks in and tried to find an error view. This finds euphorie.client.error.NotFound.
  • Trying to render the not-found view from the client results in an Unauthorized exception.

@wichert
Copy link
Contributor

wichert commented Dec 20, 2013

I think the right question to ask here is: why does the NotFound view generate an Unauthorized exception?

@wichert
Copy link
Contributor

wichert commented Dec 20, 2013

Poking around with pdb shows this:

You are not allowed to access '@@webhelpers' in this context

 - Expression: "nocall:context/@@webhelpers"
 - Filename:   ... Euphorie/src/euphorie/client/templates/error_notfound.pt
 - Location:   (line 10: col 58)
 - Source:     ... /client; webhelpers nocall:context/@@webhelpers">
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^

@wichert
Copy link
Contributor

wichert commented Dec 20, 2013

I fixed this problem by making the @@webhelpers view public, which makes it possible to render the not-found page for anonymous users. This is safe since webhelpers does not expose any non-public information.

wichert added a commit that referenced this issue Jan 2, 2014
This fixes errors trying to render the not-found page for anonymous
users.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants