Migration to AccountManagerPlugin, user can login without password

42 views
Skip to first unread message

Mo

unread,
Jun 25, 2019, 1:44:05 PM6/25/19
to Trac Users
Hi, we migrated from Trac 1.2 to 1.2.3. We also switched from webserver htpasswd to AccountManagerPlugin using htdigest.

The reason was I would like to make it possible for people to self register.
Then before it was not possible for people to set their own password.
As far as I know this all is only possible with the AccountManagerPlugin.

This all works fine. The admin/accounts/users are empty and I like to make all register themselve.

Now I see a weird isse. One user with its browser session is still able to login. After logout and login he is logged in whithout password. I can't reproduce this with an empty browser profile.
After he logged in, I see in trac-admin project session list:

SID:TheUser
Auth:1
Last Visit:<today>
All the rest is empty.

After deleting this session the user can still login. There is no entry about that user in the htdigest file that is configured with htdigest_file.
How can that be? I like all users to re-register, but after testing with one user it seems that all can login without password.

Best regards

Ryan Ollos

unread,
Jun 25, 2019, 2:22:09 PM6/25/19
to Trac Users
On Tue, Jun 25, 2019 at 10:44 AM Mo <burcheri...@gmail.com> wrote:
Hi, we migrated from Trac 1.2 to 1.2.3. We also switched from webserver htpasswd to AccountManagerPlugin using htdigest.

Did you remove the handler (Location directive) for /login in your web server configuration? If not, the web server will intercept and route the request.
 
The reason was I would like to make it possible for people to self register.
Then before it was not possible for people to set their own password.
As far as I know this all is only possible with the AccountManagerPlugin.

This all works fine. The admin/accounts/users are empty and I like to make all register themselve.

Now I see a weird isse. One user with its browser session is still able to login. After logout and login he is logged in whithout password. I can't reproduce this with an empty browser profile.
After he logged in, I see in trac-admin project session list:

SID:TheUser
Auth:1
Last Visit:<today>
All the rest is empty.

After deleting this session the user can still login. There is no entry about that user in the htdigest file that is configured with htdigest_file.
How can that be? I like all users to re-register, but after testing with one user it seems that all can login without password.

Best regards


Please share you [account-manager] section from trac.ini 

Mo

unread,
Jun 26, 2019, 2:37:05 AM6/26/19
to Trac Users
Am Dienstag, 25. Juni 2019 20:22:09 UTC+2 schrieb RjOllos:

On Tue, Jun 25, 2019 at 10:44 AM Mo <burcher...@gmail.com> wrote:
Hi, we migrated from Trac 1.2 to 1.2.3. We also switched from webserver htpasswd to AccountManagerPlugin using htdigest.

Did you remove the handler (Location directive) for /login in your web server configuration? If not, the web server will intercept and route the request.

That solved it, thanks.


Please share you [account-manager] section from trac.ini 

[account-manager]
allow_delete_account = disabled
htdigest_file = /mnt/data/trac/projects/trac/trac.htdigest
htdigest_realm = trac
login_attempt_max_count = 3
password_store = HtDigestStore
persistent_sessions = enabled
reset_password = enabled
user_lock_time = 30

However, self registration is not possible. For instance, I did trac-admin ... session delete ThisUser.
Then we try to register ThisUser, and Trac says the user already exists:

Warning: Another account or group already exists, who's name differs from ThisUser only by case or is identical.

I try to filter the relevant log lines:

Trac[main] DEBUG: Dispatching <RequestWithSession "POST '/register'">
Trac[main] DEBUG: Chosen handler is <Component acct_mgr.register.RegistrationModule>
Trac[session] DEBUG: Retrieving session for ID '731b3375eb2b2e1ea2a15538'
Trac[chrome] DEBUG: Prepare chrome data for request
Trac[perm] DEBUG: No policy allowed anonymous performing DISCUSSION_VIEW on None
Trac[perm] DEBUG: No policy allowed anonymous performing XML_RPC on None
Trac[perm] DEBUG: No policy allowed anonymous performing ROADMAP_VIEW on None
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_VIEW on <Resource 'ticket'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_CREATE on None
Trac[perm] DEBUG: No policy allowed anonymous performing SEARCH_VIEW on None
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_VIEW on None
Trac[perm] DEBUG: No policy allowed anonymous performing DISCUSSION_ADMIN on None
Trac[perm] DEBUG: No policy allowed anonymous performing ACCTMGR_CONFIG_ADMIN on None
Trac[perm] DEBUG: No policy allowed anonymous performing ACCTMGR_USER_ADMIN on None
Trac[perm] DEBUG: No policy allowed anonymous performing VERSIONCONTROL_ADMIN on <Resource u'admin:versioncontrol/repository'>
Trac[perm] DEBUG: No policy allowed anonymous performing PROJECT_SETTINGS_VIEW on <Resource 'projects'>
Trac[perm] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on <Resource u'admin:general/basics'>
Trac[perm] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on <Resource u'admin:general/logging'>
Trac[perm] DEBUG: No policy allowed anonymous performing PERMISSION_GRANT on <Resource u'admin:general/perm'>
Trac[perm] DEBUG: No policy allowed anonymous performing PERMISSION_REVOKE on <Resource u'admin:general/perm'>
Trac[perm] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on <Resource u'admin:general/plugin'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Resource u'admin:ticket/components'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Resource u'admin:ticket/milestones'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Resource u'admin:ticket/versions'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Resource u'admin:ticket/priority'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Resource u'admin:ticket/resolution'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Resource u'admin:ticket/severity'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Resource u'admin:ticket/type'>
Trac[perm] DEBUG: No policy allowed anonymous performing BLOG_ADMIN on <Resource 'blog'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on None
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on <Resource u'admin:ticket/workflowadmin'>
Trac[perm] DEBUG: No policy allowed anonymous performing REPORT_VIEW on <Resource u'report:-1'>
Trac[perm] DEBUG: No policy allowed anonymous performing TIMELINE_VIEW on <Resource 'timeline'>
Trac[perm] DEBUG: No policy allowed anonymous performing WIKI_VIEW on <Resource u'wiki:WikiStart'>
Trac[perm] DEBUG: No policy allowed anonymous performing WIKI_VIEW on <Resource u'wiki:TracGuide'>
Trac[perm] DEBUG: No policy allowed anonymous performing BLOG_VIEW on <Resource 'blog'>
Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_VIEW_HOURS on None
Trac[perm] DEBUG: No policy allowed anonymous performing QUIET_MODE on None
Trac[main] DEBUG: Rendering response from handler
Trac[perm] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on None
Trac[XMailEMailModule] DEBUG: +++++++++++++++ init EMailEventHandler
Trac[main] DEBUG: Dispatching <RequestWithSession "GET '/wikiextras/dynamicboxes.css'">
Trac[main] DEBUG: Chosen handler is <Component tracwikiextras.boxes.Boxes>
Trac[session] DEBUG: Retrieving session for ID '731b3375eb2b2e1ea2a15538'

Mo

unread,
Jun 26, 2019, 3:12:36 AM6/26/19
to Trac Users
Eventhough the user was not existing anymore, it seems that some single user permission rules in /admin/general/perm were blocking.
So I need to remove all of them first, and recreate later.

Actually this is the correct behaviour when I think about that some rule of a non-existing user exists, and somebody anonymous fetches this username...

We are going to have a self-Registering phase and close that after all users have registered. How is that done? Just disabling the RegistrationModule?

Is it true, that without this plugin and using the htpasswd auth by the webserver, it is not possible for users to change their password? If true, then this plugin is required for us.

What is the meaning of all the acct_mgr.model.* modules like AttachmentUserIdChanger? Those are all disabled here. After enabling they get disabled again.

As for the /login directive in the webserver, the plugin docs say this is still required, is that true or just removing the complete /login section?
<Location /trac/login>
   # Some options like AuthType and AuthUserFile
   Require valid-user
</Location>

What about

[account-manager]
email_regexp
= your_regex

Is it possible to make a rule here matching the domain like this?

email_regexp = .*@company.com



Mo

unread,
Jun 26, 2019, 4:36:04 AM6/26/19
to Trac Users
Most questions about the configuration and RegEx have been answered by the sophisticated GUI configuration wizard.
However the "Apply" to write the configuration does not work, it just waits for refresh...
However the output of the plain configuration is useful and I just merged that into my configuration manually.

RjOllos

unread,
Jun 26, 2019, 10:53:00 PM6/26/19
to Trac Users
Is your trac.ini and the environment conf directory writable by the webserver? If you can save configuration from the Admin page, such as Logging options, then the directory and file are writable.

- Ryan


Reply all
Reply to author
Forward
0 new messages