Edgewall Software
Modify

Opened 17 years ago

Last modified 7 years ago

#4560 new defect

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

Reported by: anonymous Owned by:
Priority: normal Milestone:
Component: general Version: 0.10.3
Severity: major Keywords: iexplorer underscore sspi
Cc: karmadude@…, gt4329b@…, ewalstad@…, dfriberg23@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christian Boos)

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.

Attachments (1)

fixupsspi.py (1.4 KB ) - added by timesking+trac@… 16 years ago.
fixupsspi.py

Download all attachments as: .zip

Change History (57)

comment:1 by Emmanuel Blot, 17 years ago

Milestone: 0.10.4
Severity: blockercritical

comment:2 by jl, 17 years ago

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

comment:3 by jl, 17 years ago

Milestone: 0.10.4

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>

comment:4 by jl, 17 years ago

Resolution: fixed
Status: newclosed

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?

comment:5 by Emmanuel Blot, 17 years ago

Resolution: fixed
Status: closedreopened

comment:6 by Emmanuel Blot, 17 years ago

Milestone: 0.10.4
Resolution: wontfix
Status: reopenedclosed

comment:7 by Emmanuel Blot, 17 years ago

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.

in reply to:  7 ; comment:8 by anonymous, 17 years ago

Milestone: 0.10.4
Resolution: wontfix
Status: closedreopened

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.

in reply to:  8 comment:9 by Emmanuel Blot, 17 years ago

Milestone: 0.10.4

comment:10 by karmadude@…, 17 years ago

Milestone: 0.11

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

in reply to:  10 ; comment:11 by Emmanuel Blot, 17 years ago

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.

in reply to:  10 ; comment:12 by Emmanuel Blot, 17 years ago

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

in reply to:  11 comment:13 by anonymous, 17 years ago

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.

in reply to:  12 ; comment:14 by anonymous, 17 years ago

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.

comment:15 by Christian Boos, 17 years ago

Keywords: iexplorer7 added; IE7 removed

comment:16 by Christian Boos, 17 years ago

Description: modified (diff)
Milestone: 0.110.10.4
Priority: highesthigh
Severity: criticalmajor

in reply to:  14 ; comment:17 by Emmanuel Blot, 17 years ago

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.

in reply to:  17 ; comment:18 by anonymous, 17 years ago

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.

in reply to:  18 ; comment:19 by Emmanuel Blot, 17 years ago

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.

in reply to:  19 comment:20 by jl, 17 years ago

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

comment:21 by jl, 17 years ago

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.

comment:22 by jl, 17 years ago

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>

in reply to:  22 comment:23 by anonymous, 17 years ago

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.

comment:24 by techtonik <techtonik@…>, 17 years ago

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

comment:25 by anonymous, 17 years ago

Adding

SSPIOfferSSPI off

seems to have fixed this problem for me.

comment:26 by anonymous, 17 years ago

..at the cost of security.

in reply to:  26 comment:27 by cesar.payan@…, 16 years ago

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

by timesking+trac@…, 16 years ago

Attachment: fixupsspi.py added

fixupsspi.py

comment:28 by timesking+trac@…, 16 years ago

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

comment:29 by gt4329b, 16 years ago

Cc: gt4329b@… added

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

comment:30 by eric@…, 16 years ago

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.

comment:31 by ewalstad@…, 16 years ago

Cc: ewalstad@… added
Keywords: underscore _ added

comment:32 by anonymous, 16 years ago

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

in reply to:  32 comment:33 by anonymous, 16 years ago

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

comment:34 by anonymous, 16 years ago

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.

comment:35 by anonymous, 16 years ago

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

in reply to:  35 comment:36 by anonymous, 16 years ago

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

comment:37 by anonymous, 16 years ago

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.

comment:38 by Christian Boos, 15 years ago

Milestone: 0.10.60.11.6

in reply to:  37 comment:39 by anonymous, 14 years ago

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.

comment:40 by anonym, 14 years ago

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.

comment:41 by anonymous, 13 years ago

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?

comment:42 by Christian Boos, 13 years ago

Keywords: sspi added
Milestone: next-minor-0.12.xnot applicable

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

comment:43 by anonymous, 13 years ago

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.

comment:44 by anonymous, 13 years ago

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.

comment:45 by dfriberg23@…, 13 years ago

Cc: dfriberg23@… added

in reply to:  43 comment:46 by richard.lyders@…, 12 years ago

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.

comment:47 by anonymous, 12 years ago

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

comment:48 by Carsten Klein <carsten.klein@…>, 12 years ago

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/

in reply to:  48 comment:49 by Carsten Klein <carsten.klein@…>, 12 years ago

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: http://trac.edgewall.org/ticket/4084#comment:15

Version 0, edited 12 years ago by Carsten Klein <carsten.klein@…> (next)

comment:50 by Ryan J Ollos, 9 years ago

Milestone: not applicable
Resolution: wontfix
Status: reopenedclosed

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.

comment:51 by Daniel Baum <daniel.baum@…>, 9 years ago

Resolution: wontfix
Status: closedreopened

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

comment:52 by Ryan J Ollos, 9 years ago

Owner: Jonas Borgström removed
Status: reopenednew

comment:53 by anonymous, 9 years ago

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.

comment:54 by figaro, 9 years ago

Keywords: iexplorer added; iexplorer7 removed

Issue reported for other versions of IE.

comment:55 by Jun Omae, 9 years ago

Keywords: _ removed
Priority: highnormal

I don't think we could search _ keyword.

comment:56 by anonymous, 8 years ago

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.