Closed
Bug 209376
Opened 21 years ago
Closed 21 years ago
Can access summary for secure bug if its been voted on.
Categories
(Bugzilla :: Creating/Changing Bugs, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.16
People
(Reporter: bbaetz, Assigned: gerv)
References
Details
(Whiteboard: [fixed in 2.16.4] [fixed in 2.17.5])
Attachments
(2 files, 2 obsolete files)
1.32 KB,
patch
|
bbaetz
:
review+
justdave
:
review+
|
Details | Diff | Splinter Review |
1.14 KB,
patch
|
justdave
:
review+
bbaetz
:
review+
|
Details | Diff | Splinter Review |
If someone has voted on a bug which is restricted in some way, we can look at their user's voting page and get teh summary of the bug. This is because the CanSeeBug check uses $who, but $who is the user we're looking at, not the current user. I noticed this while looking into bug 193575. You need to know the email of someone who has voted on the bug, though. I think the fix is to just grab the Bugzilla->user->id, but I'm not sure. Theres a lot of odd stuff in the code - the comment about # After DBNameToIdAndCheck is templatised and prints a Content-Type, # the above should revert to a call to that function, and this # special error handling should go away. looks really old, too. (I'm also not sure what all that LOCKing is about, but thats a separate bug) Gerv?
Assignee | ||
Comment 2•21 years ago
|
||
Good catch. Correct diagnosis, correct fix, and correct observation about converting to DBNameToIDAndCheck. Gerv
Assignee: myk → gerv
Assignee | ||
Comment 3•21 years ago
|
||
Fixes the two issues raised. Gerv
Assignee | ||
Updated•21 years ago
|
Attachment #126783 -
Flags: review?(bbaetz)
Comment 4•21 years ago
|
||
Comment on attachment 126783 [details] [diff] [review] Patch v.1 so we're changing the way $who is defined, but then we're not using $who anyway? Does this problem exist in 2.16.3?
Assignee | ||
Comment 5•21 years ago
|
||
We aren't changing $who, and it continues to be used elsewhere in the code. The two fixes are unrelated - one is a security fix, the other is a simple tidy-up. Gerv
Reporter | ||
Comment 6•21 years ago
|
||
Comment on attachment 126783 [details] [diff] [review] Patch v.1 Bugzilla->user will be undef if they're not logged in. You need to use a temp var for 0 vs the id, unless CanSeeBug takes the user object directly
Attachment #126783 -
Flags: review?(bbaetz) → review-
Assignee | ||
Comment 7•21 years ago
|
||
Try this, then. Gerv
Attachment #126783 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #126956 -
Flags: review?(bbaetz)
Reporter | ||
Comment 8•21 years ago
|
||
Comment on attachment 126956 [details] [diff] [review] Patch v.2 Err, no, you need: my $userid = Bugzilla->user ? Bugzilla->user->id : 0; We can access ->login diretly because theres an eralier check that FORM{'user'} exists if we're not logged in. That doesn't work for this, though
Attachment #126956 -
Flags: review?(bbaetz) → review-
Assignee | ||
Comment 9•21 years ago
|
||
Ok, how about this, then? :-) Gerv
Attachment #126956 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #127677 -
Flags: review?(bbaetz)
Comment 10•21 years ago
|
||
Does this problem exist in 2.16.3?
Reporter | ||
Comment 11•21 years ago
|
||
Comment on attachment 127677 [details] [diff] [review] Patch v.3 (for tip) r=bbaetz dave - looks like it from teh code, bnut I haven't tested. We can't use this patch for 2.16 though, ebcause of of the Content-Type stuff.
Attachment #127677 -
Flags: review?(bbaetz) → review+
Updated•21 years ago
|
Whiteboard: [wanted for 2.16.4] [wanted for 2.17.5]
Comment 12•21 years ago
|
||
CCing Gavin since he reported this bug to me in email this weekend.
Updated•21 years ago
|
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Updated•21 years ago
|
Attachment #127677 -
Attachment description: Patch v.3 → Patch v.3 (for tip)
Assignee | ||
Updated•21 years ago
|
Flags: approval?
Comment 13•21 years ago
|
||
we still need a patch for the 2.16 branch, or verification that branch isn't affected. We'll do same procedure as last time, once the patches are ready, we'll flag approval? and let it sit until we have the advisory ready to go before we check it in.
Flags: approval?
Assignee | ||
Comment 14•21 years ago
|
||
I've confirmed that this is a problem in 2.16. Here's a first attempt at a patch. Gerv
Assignee | ||
Updated•21 years ago
|
Attachment #130560 -
Flags: review?(justdave)
Updated•21 years ago
|
Whiteboard: [wanted for 2.16.4] [wanted for 2.17.5] → [wanted for 2.16.4] [ready for 2.17.5]
Comment 15•21 years ago
|
||
Comment on attachment 130560 [details] [diff] [review] Patch v.1a (for 2.16) tested on landfill, it works.
Attachment #130560 -
Flags: review?(justdave)
Attachment #130560 -
Flags: review?(bbaetz)
Attachment #130560 -
Flags: review+
Reporter | ||
Comment 16•21 years ago
|
||
Comment on attachment 130560 [details] [diff] [review] Patch v.1a (for 2.16) Looks fine, although haven't tested
Attachment #130560 -
Flags: review?(bbaetz)
Updated•21 years ago
|
Whiteboard: [wanted for 2.16.4] [ready for 2.17.5] → [ready for 2.16.4] [ready for 2.17.5]
Comment 17•21 years ago
|
||
Checked in on trunk: Checking in votes.cgi; /cvsroot/mozilla/webtools/bugzilla/votes.cgi,v <-- votes.cgi new revision: 1.15; previous revision: 1.14 done
Flags: approval+
Whiteboard: [ready for 2.16.4] [ready for 2.17.5] → [ready for 2.16.4] [fixed in 2.17.5]
Comment 18•21 years ago
|
||
Checked in on 2.16 branch: Checking in votes.cgi; /cvsroot/mozilla/webtools/bugzilla/votes.cgi,v <-- votes.cgi new revision: 1.3.2.1; previous revision: 1.3 done
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Whiteboard: [ready for 2.16.4] [fixed in 2.17.5] → [fixed in 2.16.4] [fixed in 2.17.5]
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•