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?

[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.

[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

[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.

[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".

[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.

[eblot]

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.

[eblot]

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.