Well good news ! I found the origin of our issue but probably the best
people to explain it would be the plugin developers.
On the administration interface of the user accounts
(/admin/accounts/users), you can create an account with 2 different
forms: 'Add user' at the top of the page or 'Add external user' at the
bottom (which in fact are duplicated in our project but it is an another
story). The evident difference between them is the setting of the
password (random or defined) but I didn't pay to much attention on this
because there is no particular information in the wiki and everything
was fine at that time.
So from the beginning I had to use 'Add user' form for the reasons I
explained in my last message. The newly account was listed under 'Users'
table then moved to the 'External Users' table after the first
connection of the user.
During my vacations, my colleague was not sure which form to use. She
saw that nearly all accounts were listed in 'External users' so she
chose 'Add external user' form which was consistent. Today I give it a
try to create a user account as usual ('Add user' form) and it works
perfectly...
That's all for the visible part of the problem, I was guessing that the
2 forms followed more or less the same process but it is not the case.
'Users' table seems to refer to accounts in the Trac database and
'External users' to accounts in a password file. So my initial procedure
of using 'Add user' jointly with HtPasswdStore is probably not the good
one but it works.
Nicolas
On 07/09/2017 01:16, Nicolas MARTIN wrote:
On 6 September 2017 23:06:03 CEST, RjOllos <[email protected]> wrote:
On Wednesday, September 6, 2017 at 8:46:52 AM UTC-7, Nicolas MARTIN
wrote:
I've modified pwhash.py but I'm still faced the issue.
Now I'm trying to analyse this in a different way, to see why the
procedure doesn't work now (changes in Trac or the server) or if the
problem dates back to the authentication switch. In particular, I
found
that most of the 'password_reset' entries for newly accounts are
still in
the 'session_attribute' SQL datatable. Would they not have been
removed
after the first connection with the personalized password ?
As noted, there are several issues with password reset. I doubt it
works
properly in all circumstances. I will try to take a look in the next
few
days.
The situation is a bit critical because I still can create an account
but
for me I have no more a secure way to transmit the access. Any hint ?
I don't understand the last statement.
- Ryan
For security purpose, I use the reset password procedure for every new account.
A new user contacts us by email with a chosen username, then I create the new
account (with only email and username, random password is generated), and ask
him/her back to follow the reset procedure. Finally the user has to set its own
password after the first connection.
Following this, I presume to reduce drastically the vulnerability of the whole
process. The credentials of an account will only be contained in a single email
just once and valid for a very limited time. Usually the user will finalize the
password reset in a few seconds.
At this time, I have a few people with a valid account but they can't use it.
On top of that, as the repository access is based on the same passwords file,
they are even not allowed to download the source code of our project.
I'm a bit paranoid perhaps but I don't want to send clear password if I'm not
sure it will be changed right away.
Nicolas
--
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.
