IE7 Missing or invalid form token. Do you have cookies enabled?

[anonymous]

I am getting the following error while trying to submit settings on IE7

Missing or invalid form token. Do you have cookies enabled?

Works ok in firefox.

[jl]

Works also for me in IE6 (and Firefox) before. I use mod_sspi for authentication. May be this is the problem?

[jl]

Here my part of my Apache configuration

# Trac Testproject 
<LocationMatch "/trac/testproject/login"> 
  AuthType SSPI
  AuthName "Trac - TestProject"
  SSPIAuth On
  SSPIBasicPreferred On
  SSPIAuthoritative On
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On 
  SSPIOmitDomain On
  SSPIUsernameCase upper
  Require user SCM_ADMIN
  Require group DEVEL-NET\Extern VMT\Domänen-Benutzer
#  Require valid-user
</LocationMatch>

[jl]

The problem is coming from mod_auth_sspi 1.0.4. When I switch back to basic auth it works with all browsers. -there should be a problem with the POST sending. How or who can solve the problem?

[Emmanuel Blot]

Probable duplicate of #2826 / #2696 / #1168.

Error message has changed due to the implementation changes, but the root cause is probably the same: IE + SSPI.

[anonymous]

Replying to eblot:

Probable duplicate of #2826 / #2696 / #1168.

Error message has changed due to the implementation changes, but the root cause is probably the same: IE + SSPI.

Then why does it work with IE6? The problem is only with IE7. I have SSPIBasicPreferred On and that works ok in IE6. So I am still not hearing how to fix this issue or work around it. Any information would be very helpful, thanks.

[karmadude@…]

I think I have narrowed this issue down. It might be a case sensitivity issue with the username.

Example:

Domain: TESTDOMAIN username: johndoe username in database: testdomain\johndoe

in trac.ini I have ignore_auth_case = true

In the first test case I logged in as johndoe, and everything worked fine. The username displayed after login is testdomain\johndoe

In the second test case I logged in as TESTDOMAIN\johndoe, and this time I started getting the error when posting.

This is not an SSPI issue, there is some inherent username case sensitivity issue with the trac code. The reason this is showing up in IE7 is because IE7 by default will log you in automatically using your domain informaion. This domain information might be Uppercase or lowercase.

I feel trac should not be case sensitive when it comes to the same username. There needs to be a system wide check for this.

A similar bug exits in auth.py _do_Login

[Emmanuel Blot]

Replying to karmadude@gmail.com:

I think I have narrowed this issue down. It might be a case sensitivity issue with the username.

So this ticket should be closed as a dup of your ticket #4561, shouldn't it ?

See also #2310.

[Emmanuel Blot]

Replying to karmadude@gmail.com:

I feel trac should not be case sensitive when it comes to the same username. There needs to be a system wide check for this.

​RFC 2617, which deals with HTTP authentication, states that Userids might be case sensitive. (section 2)

Therefore, I do not think Trac should always be case-insensitive, especially if it is about creating just-another-Windows-workaround ;-)

It does not prevent from adding an option for such environment, but this should not be a hard-coded "feature".

[anonymous]

Replying to eblot:

Replying to karmadude@gmail.com:

I think I have narrowed this issue down. It might be a case sensitivity issue with the username.

So this ticket should be closed as a dup of your ticket #4561, shouldn't it ?

See also #2310.

Seems to be caused by the same problem, I will let you guys figure it out, unless you want to decide on my hunch!

I had a look at #2310, looks too hacked up, I rather have a elegant solution from you.

[anonymous]

Replying to eblot:

Replying to karmadude@gmail.com:

I feel trac should not be case sensitive when it comes to the same username. There needs to be a system wide check for this.

​RFC 2617, which deals with HTTP authentication, states that Userids might be case sensitive. (section 2)

Therefore, I do not think Trac should always be case-insensitive, especially if it is about creating just-another-Windows-workaround ;-)

It does not prevent from adding an option for such environment, but this should not be a hard-coded "feature".

That looks like a spec from 1999, pretty ancient from my perspective. Have you ever tried logging into like yahoo or gmail? The usernames are always case in-sensitive, while passwords are case sensitive.

It makes total sense for the password to be case-sensitive as it's state does not go beyond authentication. On the other hand, the username has more usage beyond authentication. So the spec does not take into consideration the usability of a username and the problems a case sensitive username causes. For a smart program, john doe, JOHN DOE, John Doe, is all the same user. That's the point I am trying to make, and trac should have the logic in place to make that distinction. It can still be case sensitive.

[Emmanuel Blot]

Replying to anonymous:

That looks like a spec from 1999, pretty ancient from my perspective.

It's not about being ancient, but being standard. TCP/IP is quite ancient, still valid though. RFC documents are the references for the various protocols used on the Internet, and even if a well-known vendor uses another way of doing stuff, it does not mean it is valid. I did not find a RFC document that supersedes 2617, but I might have missed one. As stated in the RFC, "Userids might be case sensitive" leaves a choice. There are some backends that are case-sensitive, so Trac should not remove the case information for these backends.

For a smart program, john doe, JOHN DOE, John Doe, is all the same user.

I will let you define what is a smart program and what is not, it's beyond my knowledge. Anyway user name are case-sensitive on Unix, I don't think it means Unix is dumb ;-)

It can still be case sensitive.

Agreed, this could be an site-wide option.

[anonymous]

Replying to eblot:

Replying to anonymous:

Just a small comment:

didn't you trac guys say "dont close a ticket without comment"?

So why did you simply set it to "wontfix" without comment why?

I ask because this is the stuff which frustrates people adding tickets (even if I didn't create this one), which cause them to stop submitting tickets. I did so for plone some time ago.

[Emmanuel Blot]

Replying to anonymous:

So why did you simply set it to "wontfix" without comment why?

Read the full history of the ticket: it has been closed by jl as fixed. As nothing has been changed in the source code, there is no fix. I simply reverted back the reason for closing the ticket to comply with our ticket policy.

Now why the ticket has been closed, ask jl. Fixing the reason for closing the ticket does not mean the ticket cannot be re-opened if the problem has not been addressed/still occurs.

Please let us now if there are some tickets that have been closed without a reason.

[jl]

Replying to eblot:

Read the full history of the ticket: it has been closed by jl as fixed. As nothing has been changed in the source code, there is no fix. I simply reverted back the reason for closing the ticket to comply with our ticket policy.

Sorry, I didn't see that I close the ticket. Just a mistake from my side

[jl]

I found out the following:

There are two different logon dialogs when using the IE7.

The first logon dialog, that opens only show that IE tries to logon to the server. When you now log in, you get the error describes above.

But when you type in a wrong password, you are asked again to log on and this time you see also, that the server needs a username and a password. And the

AuthName "Trac - TestProject"

from the httpd.conf also appears. When you now log into the server all things works fine. Can anybody confirm this?

PS: I wanted to attach screenshots (png) to this ticket, but it only throws an error.

[jl]

I think I found a workaround. After deactivating SSPIOfferSSPI it works for me. Here my actual configuration:

<LocationMatch "/trac/testproject/login"> 
  AuthType SSPI
  AuthName "Trac - TestProject"
  SSPIAuth On
  SSPIBasicPreferred On
  SSPIAuthoritative On
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On 
  SSPIOmitDomain On
  SSPIOfferSSPI off
  SSPIUsernameCase upper
  Require valid-user
</LocationMatch>

[anonymous]

Replying to jl:

I think I found a workaround. After deactivating SSPIOfferSSPI it works for me. Here my actual configuration:

<LocationMatch "/trac/testproject/login"> 
  AuthType SSPI
  AuthName "Trac - TestProject"
  SSPIAuth On
  SSPIBasicPreferred On
  SSPIAuthoritative On
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On 
  SSPIOmitDomain On
  SSPIOfferSSPI off
  SSPIUsernameCase upper
  Require valid-user
</LocationMatch>

Very cool, I just tested it it, and it looks like everything is working on IE7 now. Thanks for the workaround.

[techtonik <techtonik@…>]

It is a well-known issue with mod_auth_sspi 1.0.4. Seems like regression from 1.0.3. Can only by fixed by somebody with knowledge of C

​SourceForge Issue ​Forum Topic

Temporary solution (which may result in increased auth overhead) is to add:

    SSPIPerRequestAuth On

[anonymous]

Adding

SSPIOfferSSPI off

seems to have fixed this problem for me.

[anonymous]

..at the cost of security.

[cesar.payan@…]

Replying to anonymous:

..at the cost of security.

Hi

I have the same problem and this 2 fixed or workaround only work in windows XP for me, this is I have one trac working 0.11dev (running in XP) that have this problem I put the workaround and this configuration is working but now that I try the same configurations in windows 2003 server work only in IE7 and IE6 if you are in the same machine where apache is running and access the page as localhost not using the hostname, is any workaround for windows 2003 server, why is diferente? in the windows 2003 also I try with 10.3

P.D sorry for me english not me native language

[timesking+trac@…]

fixupsspi.py

[timesking+trac@…]

Hi, all.

I think I got one more gorgeous solution about this problem.
I find it by google. it comes from ​http://www.aminus.net//browser/fixupsspi.py. I only test on XP+apache2.2.4, it works well. So, if it was useful on Window 2000/2003 server, pls tell me.timesking+trac@…;)

• 1.save fixupsspi.py to your python24\Lib\site-packages\fixupsspi.py
• 2.config your http.conf as following:(pay attention on "PythonFixupHandler", SSPIOmitDomain and SSPIUsernameCase )

   <Location /tracproject>
       SetHandler mod_python
       PythonInterpreter main_interpreter
       PythonHandler trac.web.modpython_frontend 
       PythonOption TracEnv D:/tracproject
       PythonOption TracUriRoot /tracproject
       PythonFixupHandler fixupsspi::strip_domain fixupsspi::lcase_user
      AuthType SSPI  
      SSPIAuth On  
      SSPIAuthoritative On  
      SSPIDomain XXXX    
      SSPIOfferBasic On 
      AuthName "Trac - Project"  
      Require valid-user
  
      # SSPIOmitDomain Off
      # SSPIPerRequestAuth Off
      # SSPIBasicPreferred Off  
      # SSPIUsernameCase lower      
   </Location>
   <Location "/tracproject/login">  
      #NT Domain auth config  
      AuthType SSPI  
      SSPIAuth On  
      SSPIAuthoritative On  
      SSPIDomain XXXX    
      SSPIOfferBasic On 
      AuthName "Trac - Project"  
      Require valid-user
      
      # SSPIOmitDomain Off       
      # SSPIPerRequestAuth Off
      # SSPIBasicPreferred Off  
      # SSPIUsernameCase lower    
   </Location>
  

  file is here attachment:ticket:4560:fixupsspi.py​

[gt4329b]

Without this comment, I couldn't add my email to the CC field. Go SpamBayes! :D

[eric@…]

After migrating a couple trac instances from one machine to another, my IE users were getting this error. It turned out that the culprit was an underscore ( _ ) in my Apache Virtual hostname (foo_trac.example.com for example). Removing the underscore from the hostname solved the problem for me.

See also: ​Microsoft Knowledge Base article323759:

"Cookies on ASP pages are blocked if the server name contains characters that are not supported by Domain Name System (DNS). For example, you cannot use underscore characters (_) in the server name. This behavior is by design."

I'm really tempted to send MS an invoice for DAYS of my time tracking this down.

[anonymous]

The workaround only works with sspi 1.0.3, not the latest 1.0.4.

[anonymous]

Replying to anonymous: Will there be a fix for sspi 1.0.4?

[anonymous]

I recently encountered this problem. I am a Trac user only, so I have no experience with installing, running or hacking Trac.

After months of trouble free use, I am suddenly unable to login, or do anything on our Trac instalation which requires authorization.

I just wanted to comment that I have tried IE7, Firefox, and Opera from Windows Vista, as well as Firefox and elinks from Ubuntu Linux. I experience the same "bad request" error reported here. My administrator is able to login to my account from his computer.

[anonymous]

I've recently encountered this with Trac 0.11 + Apache 2.2 + mod_auth_sspi 1.0.4 at server side and IE 7 as a client. It doesn't affect Firefox. It seems for me that "SSPIOfferSSPI off" eliminates the issue. However it doesn't seem to be an elegant solution as falling to basic authentication seems compromising security. I think the issue requires a bit more attention as IE 7 becoming a typical version of IE (if haven't become yet).

[anonymous]

I have installed V. 011, and gives me the error IE7 Missing or invalid token form. Do you have cookies enabled?.

as it solves. I have little experience in trac.

thanks

[anonymous]

Just a note, I was getting the error "Missing or Invalid form token" on logins. We resolved this by switching "check_auth_ip" to false. My IP was changing randomly (Service Provider proxy IP) and the server was dropping the session.

[anonymous]

Replying to anonymous:

Just a note, I was getting the error "Missing or Invalid form token" on logins. We resolved this by switching "check_auth_ip" to false. My IP was changing randomly (Service Provider proxy IP) and the server was dropping the session.

I'm getting this error when I try to change the wiki/wikiStart page.

[anonym]

I am having the same issue, which is very annoying obviously.

Additional observation: The hack with using only Basic Authentication {{{SSPIOfferBasic On , SSPIOfferSSPI Off}}} works with one exception: the server where wiki:Trac is hosted can be accessed using the computer name (say WS0001[.mydomain.com]) and additional alias (say TRACSERVER[.mydomain.com]). It turns out that in the first case editing Wiki pages works just fine, whereas when trac is accessed via DNS alias (​http://TRACSERVER) the error mentioned in this ticket comes up.

Hope this give additional info helpful to the resolution.

[anonymous]

I have the same question, is there any way to enact the fixupsspi change on the new version of mod_auth_sspi as described above?

[Christian Boos]

Hm, someone should really write a summary of this issue, maybe in a TracOnWindows/SSPI page?

[anonymous]

I'm running into this with IE8. The issue is not related to case sensitivity (set ignore_auth_case to true in ini) or host name underscores (don't have those), so the python script above does not resolve it.

If I disable SSPIOfferSSPI (and am prompted for password) this error doesn't happen, but I don't want to be prompted for password.

I checked in IE dev toolbar, I can see the cookies, but they don't seem to be getting to dispatch() in main.py. The only thing that does get there is 'panel_id' = none.

Oddly enough, if I run Fiddler inbetween IE and my web server, everything works.

[anonymous]

Neglected to mention, I also tried mod_auth_sspi version 10.3, and 10.4, with both SSPIOffserSSPI enabled and then disabled. No difference in behavior between the two versions.

[richard.lyders@…]

Replying to anonymous:

Oddly enough, if I run Fiddler inbetween IE and my web server, everything works.

I too am seeing the "Missing or invalid form token. Do you have cookies enabled?" error also from IE7 and IE8 using Trac 0.12.3dev-r10842 (on Apache/2.2.21 RedHat Linux Fedora 15 2.6.40.3-0.fc15.i686) and interestingly, when I run Fiddler, then test IE7, I have no problems. I haven't done anything to configure Fiddler at all. I just installed it, then ran it, then ran IE7 and the problem goes away. Clearly I can't ask all the users to install Fiddler. The users aren't allowed to install Chrome or Firefox so they have no way to work around this error.

My issue is specifically related to the use of Apache2::AuthenNTLM. When I simply use AuthuserFile as in the following configuration excerpt, then I do *not* get the error:

  <Location /testenv/login>
    AuthType basic
    AuthName "Trac"
    require valid-user
    AuthUserFile /path/to/.htpasswd
    WSGIApplicationGroup trac
  </Location>

When I use Apache2::AuthenNTLM, then I *do* get the error. Here is an excerpt from httpd.conf using Apache2::AuthenNTLM

  <Location '/itr/login'>
    PerlAuthenHandler Apache2::AuthenNTLM
    AuthType ntlm,basic
    AuthName "Trac"
    require valid-user
    PerlAddVar ntdomain "MYDOMAIN MYDC01 MYDC02"
    PerlSetVar defaultdomain MYDOMAIN
    PerlSetVar splitdomainprefix 1
    PerlSetVar ntlmdebug 0

    WSGIApplicationGroup trac
  </Location>

On the client, I have "Every time I visit the webpage" selected for "Temporary Internet Files" in IE7 internet options.

I've tried various combinations of the following in httpd.conf with no success:

BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0

or…

BrowserMatch ".*MSIE [1-5].*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
BrowserMatch ".*MSIE [6-9].*" ssl-unclean-shutdown

or…

BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

As you might imagine, it has been frustrating to not have a resolution for this issue yet. The corporate policy disallowing any browser but IE7 might kill our use of Trac in this company.

Has anyone had any solid success configuring trac to use Apache2::AuthenNTLM without this error? I have not had any luck getting any of the posted "fixes" for this error to work so far.

[anonymous]

May be problem in domain name IE 7 ,8 reject cookies with underscore symbol in domain name ​http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies

[Carsten Klein <carsten.klein@…>]

Don't know if this solves you problem, according to the OP it works in their case:

​http://d-log.nebulagame.com/2009/10/trac-error-missing-or-invalid-form-token/

[Carsten Klein <carsten.klein@…>]

Replying to Carsten Klein <carsten.klein@…>:

Don't know if this solves you problem, according to the OP it works in their case:

​http://d-log.nebulagame.com/2009/10/trac-error-missing-or-invalid-form-token/

and actually comes from here: comment:15:ticket:4084.

[Ryan J Ollos]

I only skimmed over the ticket, but I see that IE7 and IE8 are discussed. I doubt anyone is going to fix the issue unless it can be reproduced with IE9 or later.

[Daniel Baum <daniel.baum@…>]

We can reproduce it with (Bitnami) Trac 1.0.2 and Internet Explorer 11 (11.0.9600.17633) on two machines.

[anonymous]

One user often receives this error this way:

• Open a new browser window (in his case Firefox)
• Open multiple Trac bookmarks in multiple tabs at once (Put bookmarks in a folder, right click the folder Open all in tabs)
• Submit a form. On most tabs this fails.

I suspect the problem in this case is:

• The browser sends multiple requests without a form token cookie.
• The server responds with new form token cookies.
• The browser receives these cookies, overwriting all but the last value.
• Only the form token of the last tab (overwriting the cookie last) will send the same token in the cookie as in the form parameter.

[figaro]

Issue reported for other versions of IE.

[Jun Omae]

I don't think we could search _ keyword.

[anonymous]

Has anybody a solution or workaround for this issue. In Chrome it's working perfectly. At the moment we are using basic authentication which it's not really the preferred solution.