[Zope] [ANSWER] 500 error with IE on login

[Oliver Bleutgen]

Gregory Dudek wrote:
> This presents a longwindeded solution to a problem I posted here. I
> think I may not be unique in having this problem.
> 
> Problem: A while back I posted a question here regarding a problem I was
> having with login screens.  Specifically, users using
> MSIE on Windows were getting a "Server Error" page 
> saying "The page cannot be displayed" (error 500)
> instead of my login page. The login folder product I was using
> was the Generic User folder product (GUF)
> but I am almost certain the problem afflicts
> other user folder products like Extensible User Folder.
> I am running zope 2.4
> 
> It turns out the problem is unique to MSIE (Internet Explorer)
> on the windows platform.  As far as I know it does not occur with
> any other browser including mozilla, netscape (even on Windows)
> or even the Mac version of MSIE
> (Thanks due to complaw@hal-pc.org from this list in helping run tests).
> It seems to happen with version 5.5 and version 6.0 of MSIE but not on 
> every machine -- differences might be a subversion/patch issue.
> 
> Explanation (mainly due to Oliver Bleutgen via this list):
> the 500 error is generated by zope and appears in the page header.
> It's part of the mechanism for catching an access violation that
> leads to a request for login.  The problem is that when MSIE sees this
> error it does not display the rest the login page that follows, but
> substitutes it's own internally generated page instead.
> 
> Solutions / Work-around: There are 2 solutions, one based on users
> changing their preferences the second a code-hack to zope itself.
> 
> First the easy but sub-optimal work-around:
> If the user turns off "friendly" error messages in their browser the
> intercept by internally generated pages can be avoided.  Of course, forcing
> the user to do this is ugly.
> 
> For a page
> I made giving detailed user-level instructions, see the following:
>   http://abatonix.dyn.dhs.org/mudcritters/windowsLoginProblem
> 
> A once-only pointer to this message is generated by the following
> DTML on my home page ( http://www.mudcritters.com ):
> 
> <dtml-if "(AUTHENTICATED_USER.getUserName()=='Anonymous User')">
>        <dtml-if "(_.string.find(REQUEST.get('HTTP_USER_AGENT'),'Windows')>=0)
>               and (_.string.find(REQUEST.get('HTTP_USER_AGENT'),'MSIE')>=0)">
>     <center>
>     <dtml-if "REQUEST.has_key('MSIEwarning')">
>         <font  color=#FF7f30>
>     <dtml-else>
>         <font size=-1>(Once-only obnoxious mega-sized message.)</font><br>
>         <font size=+5 color="ff0000">
>         <dtml-call "RESPONSE.setCookie('MSIEwarning', AUTHENTICATED_USER, 
>                         expires=(ZopeTime() + 365).rfc822(),path='/' )"> 
>     </dtml-if>
>     WARNING:   As a user of Internet Explorer on Windows, to 
>     login properly <a href="windowsLoginProblem"> click here.</font>
>     </a>
>     </center>
> </dtml-if><dtml-else></dtml-if>
> 
> 
> Alternate solution: I modified zope not to give a 500 
> error as a default in such cases.  Then things work fine with all
> browsers and nobody has to muck with any preferences.
> I actually think the 500 error in inappropriate in this case so
> I removed it.  The code hack may have other
> side-effects although since most browsers ignore the 500 error I
> think it should be OK and it runs fine for me.
> 
>   In line 240 of lib/python/HTTPResponse.py (in the
> zope directory) change the lines:
>         if type(status) is types.StringType:
>             status=lower(status)
>         if status_codes.has_key(status): status=status_codes[status]
>         else: status = 500
>         self.status=status
> to read:
>         if type(status) is types.StringType:
>             status=lower(status)
>         if status_codes.has_key(status): status=status_codes[status]
>         else: status = 200
>         # GD changed above from 500 as a hack
>         self.status=status
> 
> Sorry this is so long, but I wanted to save the next poor soul
> who gets bitten by this.

Greg,

thanks for following up with a writeup.

You are quite right IMO in stating that a 500 Error for this special
case is wrong. But maybe there is a better solution for this problem 
than to disable Error 500 completly.
I just think that zope shouldn't send an error in this case, just an 
302(?) redirect to the login page.
Have you had a look at the user folder you use in order to see where it 
raises an exception (I guess that, but this might eventually lead to 
HTTPResponse tacking the error 500 to the response)?
Maybe it's possible to patch the user folder(s) to set a 302 header?

If it's the user folder can't be changed to do the right thing (which I 
doubt), I would say this is a bug in zope and should be added to the 
collector.


cheers,
oliver