Community
Participate
Working Groups
Build Identifier: SpringSource Tool Suite 2.6.1 with Mylyn 3.6.0.I20110518-1146 Note, I am able to create new tickets. I can synchronize repositories and receive updates. But I can't update those tickets through the Mylyn interface. This began happening with an upgrade to Bugzilla 4.0. The error message I receive is "Security token error (Reason = invalid_token) occurred during submission to [link to internal repository]. Synchronize task and re-submit changes." Note, if anybody has tips on how to get a more useful error message here, it would be much appreciated. I experimented with jvm options and wasn't able to get useful output. A quick google makes me think that this may be a cookie issue, but I wasn't able to find steps to resolve. Reproducible: Always Steps to Reproduce: 1.Create new ticket 2.Submit Ticket 3.Attempt to modify that ticket
(In reply to comment #0) > Build Identifier: SpringSource Tool Suite 2.6.1 with Mylyn 3.6.0.I20110518-1146 > > Note, I am able to create new tickets. I can synchronize repositories and > receive updates. But I can't update those tickets through the Mylyn interface. > > This began happening with an upgrade to Bugzilla 4.0. > > The error message I receive is "Security token error (Reason = invalid_token) > occurred during submission to [link to internal repository]. Synchronize task > and re-submit changes." Bugzilla has an hidden input field called token that is used to verify that submit is based on the previous date (from the show_bug.cgi). Mylyn use this field as an hidden attribute and get this from the ../show_bug.cgi?ctype=xml&id= call. The token was introduced with Bugzilla 3.2.1 I can not reproduce this! Can you give more information. What happens if you Synchronize the task and then try to submit? > > Note, if anybody has tips on how to get a more useful error message here, it > would be much appreciated. I experimented with jvm options and wasn't able to > get useful output. The output is generated by bugzilla > > A quick google makes me think that this may be a cookie issue, but I wasn't > able to find steps to resolve. No this is not stored in an cookie. > > > > > Reproducible: Always > > Steps to Reproduce: > 1.Create new ticket > 2.Submit Ticket > 3.Attempt to modify that ticket
Synchronize works in that the ticket is updated with any change that I make through the bugzilla web interface. But the behavior is the same after synchronization when I attempt to modify that ticket through the mylyn interface. I'm completely open to the idea that this is a server side configuration setting. But am stumped on how to debug or get enough information to forward to the team that maintains our bugzilla instance.
Frank, any chance this could be related to the domain setting in Bugzilla (don't remember the bug but I recall that there were problems when the configured domain didn't match the actual domain of the server's address)?
(In reply to comment #3) > Frank, any chance this could be related to the domain setting in Bugzilla > (don't remember the bug but I recall that there were problems when the > configured domain didn't match the actual domain of the server's address)? This is bug# 335533 A way that this can happen is: 1) open an editor. The task is updated to receive the latest changes from the Bugzilla. We get an new token. 2) we do some other action maybe we sync an Query and get an other token but this is not stored in the task. Thoughts?
Are Frank's questions directed to me? I as a user am not updating a query or intentionally doing anything other then attempting to add a comment (or change some other attribute). I did figure out one other detail if it's useful. While I can't modify any fields in a ticket - but I am able to upload documents through mylyn. Is there some more useful information that I can provide? I got stumped when trying to find logs. I'm willing to rtfm. I just need a point to tfm :)
Frank, do you know if there are cases in the framework where an updated token is not stored on the task? Can we fix that? Andrew, it sounds like you are always encountering this problem when submitting (even after synchronizing the task explicitly)?
Correct, whenever I attempt to modify any field other then attach documents in an existing tickets through mylyn, i receive the described error. This occurs whether I synchronize the ticket first or don't.
i have the same issue. Just for precision : the creation works, it's only the modification which doesn't work.
I did an test with my local 4.0.1 installation and can not reproduce this. Can I reach your bugzilla installation from public? If so please give my the url.
(In reply to comment #9) > I did an test with my local 4.0.1 installation and can not reproduce this. > > Can I reach your bugzilla installation from public? > > If so please give my the url. unfortunately it's private. But i just tested with the https://landfill.bugzilla.org/bugzilla-4.0-branch and it works
(In reply to comment #10) > (In reply to comment #9) > > I did an test with my local 4.0.1 installation and can not reproduce this. > > > > Can I reach your bugzilla installation from public? > > > > If so please give my the url. > > unfortunately it's private. > But i just tested with the https://landfill.bugzilla.org/bugzilla-4.0-branch > and it works Did you have changed the template file .../template/en/default/global/confirm-action.html.tmpl ore some other template files? When we get this error we remove the taken and resubmit the task. So I did not know why we get this error twice. Thougths?
Created attachment 200390 [details] mylyn/context/zip
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > I did an test with my local 4.0.1 installation and can not reproduce this. > > > > > > Can I reach your bugzilla installation from public? > > > > > > If so please give my the url. > > > > unfortunately it's private. > > But i just tested with the https://landfill.bugzilla.org/bugzilla-4.0-branch > > and it works > > > Did you have changed the template file > .../template/en/default/global/confirm-action.html.tmpl ore some other template > files? no, it's the standard templates.
i just found a workaround. it's the tag field at the bottom of the page, which allow to tag a bug, which add a token, so that the page contains two token : one for the bug form and one for this tag form. And Mylyn unfortunately take the last token on the page; the wrong one. You can disable this tag form in the user or admin preferences to solve the problem.
Disabling "Enable tags for bugs" from Administration > User Preferences in bugzilla eliminated the problem for me. Thanks dreddy
Thanks for posting the work-around! Frank, we should fix this for 3.6.1.
(In reply to comment #14) > i just found a workaround. > it's the tag field at the bottom of the page, which allow to tag a bug, which > add a token, so that the page contains two token : one for the bug form and one > for this tag form. > And Mylyn unfortunately take the last token on the page; the wrong one. > You can disable this tag form in the user or admin preferences to solve the > problem. (In reply to comment #15) > Disabling "Enable tags for bugs" from Administration > User Preferences in > bugzilla eliminated the problem for me. Thanks dreddy Sorry I can not reproduce this. Can I have an output of .../show_bug.cgi?id=1&ctype=xml? Is the <token> tag twice in this output?
(In reply to comment #17) > (In reply to comment #14) > > i just found a workaround. > > it's the tag field at the bottom of the page, which allow to tag a bug, which > > add a token, so that the page contains two token : one for the bug form and one > > for this tag form. > > And Mylyn unfortunately take the last token on the page; the wrong one. > > You can disable this tag form in the user or admin preferences to solve the > > problem. > > (In reply to comment #15) > > Disabling "Enable tags for bugs" from Administration > User Preferences in > > bugzilla eliminated the problem for me. Thanks dreddy > > Sorry I can not reproduce this. > > Can I have an output of .../show_bug.cgi?id=1&ctype=xml? > Is the <token> tag twice in this output? The token isn't a html tag, it's in a hidden input tag. Open the html source code with firebug and if you see two input tag named "token" in the output page, then Mylyn could not resolve the token. So you will have to disable the functionnality to make bugzilla output only one token on the page.
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #14) . . . > > The token isn't a html tag, it's in a hidden input tag. > Open the html source code with firebug and if you see two input tag named > "token" in the output page, then Mylyn could not resolve the token. > So you will have to disable the functionnality to make bugzilla output only one > token on the page. Mylyn use the token from .../show_bug.cgi?id=1&ctype=xml and not from the html output page. I see the two tokens in the html output on my local installation but can submit bugs without an error. Thoughts how to reproduce this?
i looked into the server log, and i'm sure mylyn load the html show_bug.cgi, when you want to edit a bug. Mylyn perhaps use the xml version to read data, but not for editing. Thus, there's no need for a token to read data.
(In reply to comment #20) > i looked into the server log, and i'm sure mylyn load the html show_bug.cgi, > when you want to edit a bug. > Mylyn perhaps use the xml version to read data, but not for editing. Thus, > there's no need for a token to read data. Here is how Mylyn works: 1) get the bugs from Bugzilla with .../show_bug.cgi?ctype=xml&id=XXX where XXX is the number of the bug. This xml file is parsed and the result is shown in the Editor 2) update of an bug is done with .../process_bug.cgi all fields are passed in form data 3) new bugs are submitted using .../post_bug.cgi all fields are passed in form data So we never use the HTML output of /show_bug.cgi. Please check if a <token> is present for every attachment and one more for the bug. By example for this bug we use https://bugs.eclipse.org/bugs/show_bug.cgi?id=346882&ctype=xml and get two tokens.
Moving back to inbox until we have verified the problem and steps to reproduce.
Are you still experiencing this problem with the latest Mylyn 3.6.2 release?
In 3.6.2 as well as the 3.7.0 snapshots.
Looking at the source of http://mylyn.org/bugs40/show_bug.cgi?id=1 I also see two forms and two hidden tokens elements but both have the same value. Andrew, if you look at the HTML source in your instance, do you get two different tokens? What is the exact version of Bugzilla that you are using?
Hey Steffan, The bugzilla version is version 4.0.2. I do see two tokens and they have different values. If I disable "Enable tags for bugs" in preferences, I only see one token. -Andy
I wonder why the tokens are different whereas in our setup they are the same. Frank, do you have any ideas?
Nevermind, they are not the same in our setup either and generating the xml format creates a new token anyways so that's not the cause of the problem.
I ran into the same problem and found that disabling the "Enablke tags for bugs" setting in Bugzilla 4.0.2 solved the issue. I was using Eclipse 371 with Mylyn 3.6.2, so is not resolved yet
Thanks for confirming this Maarten. Is that Bugzilla instance publicly accessible? I still haven't been able to setup Bugzilla in a way that reproduces the problem.
I manage a Bugzilla instance that is having this same problem. It's publicly accessible, but requires login. I can create an account for someone to test with (and probably have to create a dummy product and security group) - just let me know what email address should receive the account.
(In reply to comment #31) > I manage a Bugzilla instance that is having this same problem. It's publicly > accessible, but requires login. I can create an account for someone to test > with (and probably have to create a dummy product and security group) - just > let me know what email address should receive the account. Can you please create an account for me (Frank@Frank-Becker.de)
(In reply to comment #32) > (In reply to comment #31) > > I manage a Bugzilla instance that is having this same problem. It's publicly > > accessible, but requires login. I can create an account for someone to test > > with (and probably have to create a dummy product and security group) - just > > let me know what email address should receive the account. > > Can you please create an account for me (Frank@Frank-Becker.de) OK. I'll email you the login info.
Eric, i used the test bug and here is what I found: 1) we get the token with .../show_bug.cgi?ctype=xml&id=... 2) this token is used in .../process_bug.cgi as on of the form parameters. I think wh have here an bugzilla bug. The token is created in bugzilla template show.xml.tmpl but process_bug.cgi did not accept this token. I try to find more information so i can open an bug for the Bugzilla team.
Thanks for investigating this Frank! I have tentatively scheduled this for 3.7 to keep track of the bug.
I have created a patch that fix this problem. It is not an Bugzilla problem. In getPairsForExisting() we call getHtmlOnlyInformation() if we have groupSecurity enabled we did not test if we have the token from the correct form within the HTML source.
Patch in now commited with id =2f46636bfd6b9dc48e6485ec674ed57d86cc52e9 Should we backport this?
(In reply to comment #37) > Patch in now commited with id =2f46636bfd6b9dc48e6485ec674ed57d86cc52e9 > > Should we backport this? I think definitely. There's plenty of time for testing before Indigo SR1.
A new weekly build is now available from http://eclipse.org/mylyn/downloads/#weekly . Can someone confirm that this fixes the problem (or not)?
(In reply to comment #39) > A new weekly build is now available from > http://eclipse.org/mylyn/downloads/#weekly . Can someone confirm that this > fixes the problem (or not)? I've installed the weekly build and at least today the error mentioned in the first comment ("Security token error (Reason = invalid_token) occurred during submission to [link to internal repository]. Synchronize task and re-submit changes.") didn't show up. I'm not quite sure if this is directly releated to the bug - but instead I'm getting the error message "Submit failed: Unable to login to <bugzilla-url>. log in to bugzilla. Please validate credentials via Task Repositories view." on the first submit and the dialog "Properties for Task Repository" pops up. Validating the settings for the bugzilla repository works without an error (msg "Authentication credentials are valid.") but submitting still doesn't work. I'm using a proxy server configuration with proxy authentication. But just refreshing the attributes via the small button in the Attributes area in the bug tab itself - and afterwards the submit works without an error.
(In reply to comment #40) > I'm not quite sure if this is directly releated to the bug - but instead I'm > getting the error message "Submit failed: Unable to login to <bugzilla-url>. log > in to bugzilla. Please validate credentials via Task Repositories view." on the > first submit and the dialog "Properties for Task Repository" pops up. Validating > the settings for the bugzilla repository works without an error (msg > "Authentication credentials are valid.") but submitting still doesn't work. > I'm using a proxy server configuration with proxy authentication. > > But just refreshing the attributes via the small button in the Attributes area > in the bug tab itself - and afterwards the submit works without an error. Please create an new bug for this if you have more information. I mark this as resolved, please feel free to reopen if you found a problem!
Reopening as a reminder to backport. I have been getting security token errors on submission fairly frequently. I would like to watch this for a bit longer before we consider this fixed.
*** Bug 363110 has been marked as a duplicate of this bug. ***
This is happening on a significant percentage of my submissions now.
(In reply to comment #44) > This is happening on a significant percentage of my submissions now. Sam, what is the version of the https://live.tasktop.com/dev/bugs instance? is groupSecurityEnabled ? This means if you look in the taskData you find the attribute BugzillaAttribute.GROUP. Did you see the Token Attribute in the taskData?
It's Bugzilla 3.4.1. Yes, I see the group and token attributes.
Sam, can I have access to the https://live.tasktop.com/dev/bugs instance to see what the html output looks like. If not please send me an example so that I can see which forms and token are included.
Frank, I have responded to you by email .
Now I found the problem. My previous fix was only for Bugzilla >= 4.0. The form definition has changed I use the id attribute which was new in 4.0 and not the name id=6eb5af8d4da3a6069bb4840d5f18a9c9900eb9f1 has the fix. Sam, can you please apply the patch and test if it now work in your environment.
So far we have the following commits: 6eb5af8d4da3a6069bb4840d5f18a9c9900eb9f1 2f46636bfd6b9dc48e6485ec674ed57d86cc52e9
Where/how do I get these commits?
(In reply to comment #51) > Where/how do I get these commits? Steffen, did we have an weekly build where this is already included?
Yes, this is in the latest weekly build and in the current master branch.
Ok, I've updated. I'll let you know if I continue to have problems.
I just got this error for the first time since my last comment after trying to mark an attachment as obsolete.
It's valid that you get the error in case of a network problem, e.g. if the repository connection is interrupted unexpectedly.
It's hard to say if that happened, but I was able to modify the task just before and after the error.
I have cherry-picked these commits to the e_3_7_m_3_6_x branch: 2f46636bfd6b9dc48e6485ec674ed57d86cc52e9 6eb5af8d4da3a6069bb4840d5f18a9c9900eb9f1 The fix will be released in 3.6.5 and 3.7.
I am seeing this error happening if I create new Eclispe bugs with Report Bug or Enhancement. Is there any workaround?
The message "Synchronize task" is not applicable since it is a new task. Last action was to restore tasks from a 6 weeks old snapshot. Shall I create a new ticket?
OK, for new tasks the button "Refresh Attributes" in the top-right corner of the Attributes section does the job. Please, could you update the error message indicating to use "Refresh Attributes"? I guess it will also work in the other cases where the task already exists. If Mylyn could do this automatically it would be even better...
Using the latest Eclipse Kepler with Mylyn and Mylyn Bugzilla connector, I can create bugs, but cannot update them, even after refreshing attributes/synchronizing incoming changes/synchronize changed. This major bug is back. Versions : Kepler Service Release 1, build id: 20130919-0819 Mylyn bugzilla_feature : 3.9.1.v20130917-0100
(In reply to Alexandre B from comment #62) > Using the latest Eclipse Kepler with Mylyn and Mylyn Bugzilla connector, I > can create bugs, but cannot update them, even after refreshing > attributes/synchronizing incoming changes/synchronize changed. > > This major bug is back. > > Versions : > Kepler Service Release 1, build id: 20130919-0819 > Mylyn bugzilla_feature : 3.9.1.v20130917-0100 Do you have more information? What Bugzilla Version did you use? Do you have information in the error log?
I'm using the last stable Bugzilla version 4.4.1. I don't see anything special happening in the apache2 error.log when Mylyn displays this error. I'm using Apache v2.2.22-13.
(In reply to Alexandre B from comment #64) > I'm using the last stable Bugzilla version 4.4.1. > > I don't see anything special happening in the apache2 error.log when Mylyn > displays this error. > > I'm using Apache v2.2.22-13. This bug was about an problem with bugzilla 4.0 and not bugzilla 4.4. Please open a new bug if you have information in the eclipse error log. Maybe you can look in the .../show_bug.cgi?ctype=xml&id=... output. Here you must find the <token> attribute. Please look if you have a <group> attribute.
Frank, looks like there is a bug for this: 422353: security token error for all except add new bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=422353
