[ZCM] [ZC] 773/ 7 Comment "Also, an error occurred while attempting to render the standard error message."

[Collector: Zope Bugs, Features, and Patches ...]

Issue #773 Update (Comment) "Also, an error occurred while attempting to render the standard error message."
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/773

==============================================================
= Comment - Entry #7 by dland on Oct 6, 2004 1:12 pm

This problem seems to also exist under Plone 2.0/Zope 2.7.0/Solaris 9/Intel. Any suggestions?
________________________________________
= Comment - Entry #6 by camil7 on Aug 3, 2004 4:39 am

I should have been more explicit in my message
(Entry #4):

I cannot reproduce the reported bug. The only setup
where get a similar error message is obviously 
completely correct behaviour.

I feel my setup should have reflected your setup
close enough, so it should have been able to reproduce
the bug, but it did not show up.

Either I have misread the bug description, or the
description is not detailled enough to reproduce the 
bug.

So please tell details about a setup to reproduce the 
error ... maybe just the missing piece why my setup
did not work to produce the bug.

________________________________________
= Comment - Entry #5 by febb on Aug 2, 2004 3:21 pm

I believe you did NOT, in fact, reproduced the error. 
You actually got an appropriate error message to what you actually did. The reproduction of my original "bug" was not accomplished by your test.


>Things are different if I do not inherit "View" >permissions in /folder from "/", but grant it to >"Authenticated" only.
>  In this case I can reproduce the issue -- however the >error message is correct, the anonymous user is not >allowed to view the error page (which is inside /folder).
>
> Giving "Anonymous" the permission "View" in the
>Security tab "/folder/standard_error_message" fixes this.
________________________________________
= Comment - Entry #4 by camil7 on Aug 2, 2004 3:03 pm

I tried to reproduce the issue, but I couldn't.
Setup:

 - /folder/standard_error_message  
    is some page template saying not much more than "sorry"

 - /folder/subfolder has Permission "View" restricted to 
    the "Authenticated" role, acquiring the other 
    permissions

 - /folder inherits all permissions from the root, 
   where "View" permission is granted to "Unauthorized"
   and "Manager"


If I visit /folder/subfolder as anonymous and cancel the HTPP authorization dialog box, I get the /folder/standard_error_message


 Things are different if I do not inherit "View" permissions in /folder from "/", but grant it to "Authenticated" only.
  In this case I can reproduce the issue -- however the error message is correct, the anonymous user is not allowed to view the error page (which is inside /folder).

 Giving "Anonymous" the permission "View" in the
Security tab "/folder/standard_error_message" fixes this.



(actually tried with Zope 2.6.4, python 2.1.3, C-security implemetation; i.e. ZOPE_SECURITY_POLICY=PYTHON not set)

________________________________________
= Comment - Entry #3 by gsudha on Aug 2, 2004 12:25 am

Is there a fix to this issue? I am using Plone 2.0.3 on Zope 2.7.1 and get the same problem using mysqlUserFolder for User Management Error page content shown below:

------------------------------------------
Site Error
An error was encountered while publishing this resource. 

Forbidden

Sorry, a site error occurred.

Traceback (innermost last): 

Module ZPublisher.Publish, line 163, in publish_module_standard 
Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish 
Module ZPublisher.Publish, line 127, in publish 
Module Zope.App.startup, line 203, in zpublisher_exception_hook 
Module ZPublisher.Publish, line 91, in publish 
Module ZPublisher.BaseRequest, line 423, in traverse 
Module Products.mysqlUserFolder.mysqlUserFolder, line 745, in validate 
Forbidden: You are not authorized to access this document. (Also, an error occurred while attempting to render the standard error message.) 


--------------------------------------------------------------------------------

Troubleshooting Suggestions

The URL may be incorrect. 
The parameters passed to this resource may be incorrect. 
A resource that this resource relies on may be encountering an error. 
For more detailed information about the error, please refer to error log. 

If the error persists please contact the site maintainer. Thank you for your patience. 
----------------------------------------------
________________________________________
= Comment - Entry #2 by KuznetV on May 11, 2004 10:46 am

I have the same issue with Zope 2.7.0 on W2k
________________________________________
= Request - Entry #1 by Anonymous User on Jan 17, 2003 1:25 am

Having a password protected section of a site, with the
 usual acl_users entry, role and permission 
 settings, when  hitting CANCEL at the HTTP 
 authentication pop up window (where 
 username/password get keyed in), the  following error 
 comes from Zope:
 
   You are not authorized to access this resouce
   Username and password are not correct
 
  (Also, an error occurred while attempting to render
  the standard error message.)

The "Also..." part seems to be related to secondary error exceptions, that is, an error triggered by a bug or typo in the actual standard_error_message that is supposed to be rendered (traversal taken into account already, so we are dealing with the correct standard_error_message object).

The standard_error_message is left with nothing but the minimum HTML tags to print out something and still the above error message gets rendered in the browser (including the irrelevant not authorized part, of course). So there are no bugs or even code in the standard_error_message

While logged as manage and editing the standard_error_message, hitting the VIEW management tab 
renders and correctly displays the standard_error_message.

This behavior started happening on 2.6.0, the application used to run and render the application's customized standard_error_messages perfectly in 2.5.1. When migrated to the new 2.6.0 the above described scenario started happening. 

==============================================================