Wiki Preview and Wiki Submit problems with IE 7.

[adam.durling@…]

A couple of our users are beta testing Internet Explorer 7 (beta2) and have come accross an issue where they are unable to preview and submit wiki pages. Rather than seeing the preview page or configuration of the submit, they see a "Create" page, which asks them to create the page they have just edited.

[hyugaricdeau@…]

We currently have two deployments of Trac 0.9.5 which are having this problem. Actually, the problem extends far beyond what the original ticket suggests: First of all, we are having this problem in IE6 as well. We've also tested it on Firefox 1.5.0.2 and Opera 8.5, but it just seems to be an IE thing.

Also, it applies not only to wiki pages, but to *everything* in Trac, including plug-ins. In fact, by capturing network communications, we've been able to determine that IE is simply not sending HTTP POST variables. This is only happening in Trac, so it shouldn't be a problem with our IE configuration either.

We also have a server using Trac 0.8.4, which does not have this issue. We haven't tested it on any other versions.

[hyugaricdeau@…]

Well, now I'm not certain whether or not our problem was related to the original ticket. It turns out that the problem we were having was with our NTLM authentication scheme, which was apparently making IE barf (and yet other browsers that support NTLM worked fine—IE's NTLM scheme is rather poorly documented). So this is not a default in trac itself, I don't think.

[Emmanuel Blot]

See also #1168 and/or search for SSPI on this web site.

If you think the trouble does not come from Trac, please close this bug as "worksforme".

[adam.durling@…]

We are still seeing this issue (although with RC1 of IE7 now)… even though we have set SSPIBasicPrefered On as suggested in the referenced ticket.

The problem does not exist for us in IE6… only IE7. We don't use ticketing - we just use the Wiki and Svn Browser… although I suspect we would see similar behaviour with ticketing if we switched it on.

I'm posting this ticket using IE7… I wonder if it will work? Well - preview does. I don't know if this issue has been addressed in a later version - I'm reluctant to upgrade at the moment (got plenty of other things to worry about) but I'd consider a fix to this problem a good reason to upgrade.

I've had a quick look - but can't find anything that doesn't say "SSPIBasicPreferred On works for me".

[richard.grace@…]

I am having a similar problem with sspi and IE7, which I think is probably related and may help with the resolution.

I used have to type my in my login in IE6, which then triggered all my top menu changes and allowed me to add tickets etc according to my permissions.

Now I get automatically logged in but the menu does not change and the ability to create new tickets/documents does not get enable.

[Christian Boos]

See also #4561, which might be related.

[Christian Boos]

#2795 was marked as duplicate.

[osimons]

Is this currently an issue for Trac? 'worksforme'?

[adurling]

It seems this is more an apache issue than a trac issue. This also works for me now - after altering my apache configuration.

Here is the relevant section of my httpd.conf file if it helps.

<VirtualHost *:80>
    ServerAdmin whatever@whatever.com
    ServerName trac.whatever.com
    ServerAlias trac
    ErrorLog logs/trac-error_log
    CustomLog logs/trac-access_log common

    <Location />
      SetHandler mod_python
      PythonHandler trac.web.modpython_frontend 
      PythonOption TracEnvParentDir e:\trac
      PythonOption TracUriRoot /
      SetEnv PYTHON_EGG_CACHE c:\python23\cache
    </Location>

    <LocationMatch "/[^/]+/login">
      #NT Domain auth config
      AuthType SSPI
      SSPIAuth On
      SSPIAuthoritative On
      SSPIOfferBasic On 
      SSPIOmitDomain On
      SSPIDomain server.whatever.com
      # following line squishes bug #1168 if IE has troubles editing wiki pages.   
      SSPIBasicPreferred On 
      SSPIOfferSSPI off
      SSPIUsernameCase upper
      AuthName "Trac"
      Require valid-user
    </LocationMatch>

</VirtualHost>

I'm no apache guru - so I appologise if there are any undesirable settings in this example - but hopefully it will give a clue to someone having this problem about how to fix it.

From recollection this was to do with username / password case.

Adam.