Closed
Bug 45918
Opened 25 years ago
Closed 24 years ago
Cookie setting not checked in bugzilla
Categories
(Bugzilla :: Bugzilla-General, defect, P3)
Bugzilla
Bugzilla-General
Tracking
()
VERIFIED
FIXED
Bugzilla 2.14
People
(Reporter: jms, Assigned: justdave)
References
()
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
If I have disabled cookies, I get problems with the login or
with changing passwords. For example, the system let me change
my password, but afterwards, it is not changed.
Server should check if client browser allows cookies.
Comment 1•25 years ago
|
||
Wrong component.
Component: Server Operations → Bugzilla
Product: mozilla.org → Webtools
Comment 3•25 years ago
|
||
reassigning to cyeh who is more aware of recent bugzilla changes. It seems
that something has broken cookieless operation. I never work that way so
I'm not sure when it broke.
Assignee: endico → cyeh
Updated•24 years ago
|
Whiteboard: 2.14
Assignee | ||
Comment 4•24 years ago
|
||
moving to real milestones...
Whiteboard: 2.14
Target Milestone: --- → Bugzilla 2.14
Assignee | ||
Comment 5•24 years ago
|
||
ok, disabled cookies and logged out. testing...
Assignee | ||
Comment 6•24 years ago
|
||
It let me make a comment... made me log in again in the process of posting it.
I then went to my email prefs and changed my password. This worked fine, too.
Although there is a catch to it. When you click the button to go to your prefs,
you get prompted to log in. So I do, then I get the form with the old password,
new password, etc. Fill that out, hit Commit, and I get prompted to log in
again. I have to log in one more time USING THE OLD PASSWORD in order for it to
connect to change my password. Once that's been done, it does indeed change to
the one you put on the form.
This bug, as written, is WORKSFORME. However... it would be WAY less confusing,
since the user *is* putting in their old password on that page, to use the old
password field in order to log in, for that one time, instead of prompting for
redundant information again. That might be a tall order, though, because of the
way the security system is designed. Anyone have any comments?
QA Contact: endico → matty
Comment 7•24 years ago
|
||
I think using the old password to log in isn't a bad idea. It should be
possible to put the user name that was used to login in order to view the pref
page in a hidden form element for the other half of the authentication.
However, I'd think that could be pushed back to 2.16.
Assignee | ||
Comment 8•24 years ago
|
||
Assignee | ||
Comment 9•24 years ago
|
||
Attached a patch to userprefs.cgi which implements using the old password field
from the "change password" form to log you back in, skipping the redundant
password screen. This was easier to implement than it sounded. Just changed the
name of the old password field from "oldpwd" to "Bugzilla_password" and added a
hidden field called "Bugzilla_login" with the user's email address. Since those
are the same tokens used by the real login form, Confirm_login() thinks that's
where you just came from and sends you right on through.
Comment 10•24 years ago
|
||
This looks reasonable and didn't break anything when I tried it.
r=tara
Assignee | ||
Comment 11•24 years ago
|
||
checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 12•23 years ago
|
||
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
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
•