sebas I have understood, but in any way you keep a variable with the
password and when you click ok it restore the old password, this IS a
security issue, why you keep that?
Keep in mind that I close the user's properties with OK, so everyone think that
you have closed the transaction and all var
On Monday 08 January 2007 12:39, Luka Renko wrote:
> sebas, we could make GUI "smarter" that it would not change password if
> user did not change the password field from last Apply/OK. The problem
> is that opening the dialog and clicking Apply/OK should not do any
> change to password (like setti
sebas, we could make GUI "smarter" that it would not change password if
user did not change the password field from last Apply/OK. The problem
is that opening the dialog and clicking Apply/OK should not do any
change to password (like setting it to empty or whatever) if user did
not touch the passw
On Monday 08 January 2007 10:49, Cimmo wrote:
> passwords are all read when you come in the users list or when you double
> click in a user to change its properties?
>
> If the one so ok to your answer, if second then I still think this is a
> bug.
We cannot 'read' the password at any time, it's n
sebas a question:
passwords are all read when you come in the users list or when you double click
in a user to change its properties?
If the one so ok to your answer, if second then I still think this is a
bug.
thanx
--
user password is not read every time you open an user, results in password
The password cannot be read anyway. And frankly, I think the steps you
describe is shooting yourself in the foot. You are deliberately creating
a race condition.
If we want to support all such cases where we want guidance to still
work even when a user simultaneously uses different tools for the s
