LoginModule with .htpasswd & passwd reset => not working

Replying to anonymous:

On my machine with Apache 2.2, trac 0.12.2 and Acountmanager 0.3 I first setup user login via .htpasswd. Since resetting the PWD by the user became important, I switched to LoginModule. Nearly everything works fine: * user can change his pwd
* user can log in after changing his pwd
* "forgot password" generates a mail with a new pwd
* /!\ new pwd is not written into .htpasswd
* /!\ prefs can be changed without beeing logged in

Yeah, I really appreciate your test feedback. I'll give you some comments and points to check, would be great to resolve this based on our cooperation ASAP.

AcctMgr is currently 0.3dev. Please note the suffix for the trunk branch meaning code under development. Of course this is more important for (future) reporting after the release, but keep it in mind anyway. But opposed to stable releases for development version the exact revision would be required to know, exactly what code you do have applied, since this branch changes a lot over time.

Reset passwords are no longer written to any password store by default. Please understand, that this is a feature, see comments to [10264].

Any connection to a Trac environment establishes a session. So you're always able to save some properties connected with an unauthenticated session and corresponding cookie in your browser, you see? But in contrast to an authenticated user session this data is lost, if you change to another browser instance. BTW, this is core Trac functionality and AcctMgr couldn't do much about it, even if you don't like it.

AcctMgr 0.3 will come with a several pages long changelog. You may notice more interesting features reading it - before I've got the chance to fully update wiki docs. I.e. be sure to check the style.css in contrib folder for an 'awesomely prettified login', as some other user told me.

Last but not least, I'm always open for discussion and try to assist in case of installation/local configuration issues too as my time permits. But the th-users mailing list is a much better place for that. If you're really determined about using tickets (meant for plugin development here), you're free to do so, but one issue per ticket, please. Anything else can't be tracked properly.

For now allow me to step down prioritization and severity to normal. Still I'm eager to learn, if my hints have been helpful. Thanks for taking care.

Regarding the access to prefs w/o beeing authorized: I managed the issue by using http authorisation on prefs. The user now has to log in with his pwd twice. Looking at the sql db, the sessions are not deleted. So, that means, that the db is filled and tha is a security hole to my minde because with a DOS attack the db can be slowed down or hdd space can be consumed. Or you could use trac to spam at someones email. Plus: what is the usecase to fill in an email address w/o beeing logged in?

Replying to anonymous:

Regarding the access to prefs w/o beeing authorized: I managed the issue by using http authorisation on prefs.

Ok, but this (basic HTTP) authentication method is disputed as well, largely because there is no sane way to logout within a browser session. I think this is one reason to prefer AcctMgr for a lot of current Trac applications.

The user now has to log in with his pwd twice.

Choice is up to you, but I'd never do that. Admittedly many users may not touch preferences that often, so they don't care. But for my applications I'm trying to avoid even a single password prompt, i.e. with Single Sign On of some flavor.

Looking at the sql db, the sessions are not deleted. So, that means, that the db is filled and tha is a security hole to my minde because with a DOS attack the db can be slowed down or hdd space can be consumed.

True, sessions are not deleted. One could come up with a simple cleanup algorithm. I've already thought about it several times. Occasional checks and a configurable expiration time would do. There's already a mechanism to refresh sessions and session cookies, so it should be hard to do similar with deletion of expired sessions. OTOH this is a convenience function. (You questioned use case below...)

Regarding db size, did you do some maths to eval, how many entries would bring you in serious trouble, considering today’s drive/partition size? I doubt that this is a real thread. And there are ways to prevent or at least lower the power of a DOS attack by connection tracking and intelligent IP filter settings etc.

Or you could use trac to spam at someones email.

How exactly would you do that? Use show_email_addresses option (docs: Show email addresses instead of usernames. If false, we obfuscate email addresses. - since 0.11) This has a corresponding privilege named EMAIL_VIEW, so it's easy to hide full email even to authenticated (non-admin) users.

BTW: This is one of the reasons, why we should have Trac upgrade from 0.10 here at t-h.o too ASAP.

Plus: what is the usecase to fill in an email address w/o beeing logged in?

Did you visit Trac's home - trac.edgewall.org? Since there is no easy way for registering an account, there are actually most of the users "signing" tickets, comments and wiki edits by email address - not visible to anonymous users. As I told you above, I'd consider this as a convenience method for someone to do a few contributions without the need to register, choose password, etc.

How about your initially reported issue? Can you see the new password hash inside the Trac db table session_attribute? Did it you get past the login after understanding the new way (password is transferred only after first successful login with that password)?

For the other considerations I recommend to move over to th-users or trac-users mailing list for discussion with the added benefit, that you may get more response than for development ticket comments.

Any feedback regarding last clarifications?

Does it work for you now, after taking the additional information into account? I'd like to know, if there's something to be done on my side, or if this is no longer an issue at all. And stale tickets irritate fellow plugin users, that might be interested to know current plugin state as reflected by current tickets as well.

Thanks for getting back to it. I managed it somehow with .htaccess that is written by the TracAccountManager? (0.3dev-r10363). However, sometimes, if I login as user A, do something, log out as user A, log in from the same machine with the same browser as user B, I am logged in as user B (wich is shown as "logged in as user B" - that's the way is should be, I know). But when I click on settings I see the settings of user A and can change them. Very strange. I asume it is some kind of cockie issue, but I do not know.

Replying to anonymous:

[...] But when I click on settings I see the settings of user A and can change them. Very strange. I asume it is some kind of cockie issue, but I do not know.

Strange indeed, but I tend more towards a caching issue. Try hitting <F5> (or whatever is needed to refresh the page in your browser). If I'm right, it should change to user B again. At least you shouldn't be able to change anything for user A. Submit - and get bitten, I guess. Anything else would be subject to serious examination.

I'd really like to be know about an issue, if there is one hidden inside. I do care about privacy and security, and Trac core devs will feel the same, if this turns out to need their attention.

I forgot: Would you do me a favor and not use old, known buggy stuff like acct_mgr-0.3dev anymore, please? Even if there have been mostly fixes for backwards-compatibility with Trac 0.11, AcctMgr 0.3 is definitely the better choice (currently 0.3.2), or trunk, if you feel more adventurous and eager to test the latest and greatest code.

The changelog has already some good stuff for the upcoming 0.4 release. Be sure to check the details, as we'll need to force some incompatible configuration changes, and admins will need to fix them on install for preserving AcctMgr from failure after that upgrade.

Sur, I would like to use the most actual one. However, despite what is written on http://trac-hacks.org/wiki/AccountManagerPlugin there is no version 0.12 in the SVN referenced on that site. So the latest stable one wold be 0.11 - is this correct? I'm using trac 12.2.

from AccountManagerPlugin wiki page:

0.11 should work equally well for Trac 0.11 (old stable),
0.12 (current stable) and Trac 0.13dev (development).

Don't know what else you did refer to. 0.11 branch is ok, there'll most probably never be a version dedicated to Trac 0.12, for ease maintenance: Better have only a compatible one than two to maintain in parallel.

But the 0.11 branch will unleash full power with 0.12 only, i.e. regarding visual feedback on account management actions or i18n.

Ok, updated to 0.11 (0.3.1). The following behavior is unchanged: - login as user A - go to "settings" (w/o changing anything) - logout user A => nothing visible happens - click on e.g. "view tickets" => "no rights for 'VIEW_REPORT'" => a log out screen would be handy. - login as user B - go to "settings" => I still see the credentials of User A - if I click on "create new ticket" I see that the system sees me as user B

Maybe there is something wrong with my setup, but this is for sure anoying.

I'm using chrome (latest release).

Hint: (Trac) WikiFormatting means, that multiple lines without blank line or headline in between are one paragraph, use <Preview> to examine before submitting comments. Ok, let's straighten your comment with [[BR]] while commenting on it...

Replying to anonymous:

Ok, updated to 0.11 (0.3.1). The following behavior is unchanged:
- login as user A
- go to "settings" (w/o changing anything)
- logout user A => nothing visible happens

Can't believe. Metanav should change from something like

logged in as userA | Logout | Preferences | Help/Guide | About Trac to
`Login | Preferences | Help/Guide | About Trac | Register

Not too subtle to spot, if you're already focused on monitoring for changes.?

- click on e.g. "view tickets" => "no rights for 'VIEW_REPORT'"

Ok, configuration-dependent. Obviously you don't give anonymous 'VIEW_REPORT' privilege - no problem.

=> a log out screen would be handy.

Why now, or did you just mean a more visible feedback on logout (you clicked it, before, right?), as later on it doesn't make sense to me. No big problem either, since Trac just does, what you ask it to do. Nothing unexpected about it, right?

- login as user B
- go to "settings"
=> I still see the credentials of User A

Did you try to refresh? I do always vote for browser cache issues in similar situations. Almost nothing, neither Trac nor AcctMgr could do about it, see #T791 as well as #8718 and related #T10148.

- if I click on "create new ticket" I see that the system sees me as user B

So this confirms, there's nothing wrong or twisted on the server side, just confusing output related to browser client behavior.

Maybe there is something wrong with my setup, but this is for sure anoying.

I'm using chrome (latest release).

Sorry, but this is most probably not a Trac nor AcctMgr issue. Nevertheless you may want to have the latest improvements on browser cookie handling, coming in right now into trunk (within the next few days). Or checkout acct_mgt-0.3.2 when it's released within the next few weeks.

Thanks for taking you time to test and report here anyway.

1. Logout => unchanged rendering Might it be related to the fact that I specified seperate .htaccess for the url to the "preferences"? I thought this is the way it should be so that they are secured. But maybe this creates this issue?

2. VIEW_REPORT yes, this is not my concern, I just explaines what I did to make sure the user is really logger out. Anonymous users do not have permission to view the report on my system.

3. Refresh When I refresh the same content gets rendered. You can see that it renders.

Replying to anonymous:

1. Logout => unchanged rendering Might it be related to the fact that I specified seperate .htaccess for the url to the "preferences"? I thought this is the way it should be so that they are secured. But maybe this creates this issue?

Yes, really wired. But as I've tested this already a few times during the course of this ticket, first with Trac 0.13dev and now with this and stock Trac 0.11 in parallel - without ever getting in trouble in a similar way - the 2nd authentication setup plus browser cookies are likely the culprit.

Meanwhile I've fixed quite some issues, all reproducible with much less effort than this one. In fact as of today we've settled quite a bit of the original claim, so I do expect to resort the remaining things a well. But as long as I've no real clue, no logs, etc. the best bet is for ongoing development to spot and fix this as a byproduct of other changes.

Please do regular tests without the additional authentication too, so we'll notice, when eventually sane operations are reached for you too. And try with deleting all cookies before attempting the login as the other user. This applies especially to the additional Basic HTTP Auth by the webserver, that is prone to seamless re-login, if you don't invalidate the browser session, i.e. restart your browser or similar.

(In [10606]) AccountManagerPlugin: Another (final?) fix to session cookie handling, refs #8927, #9088, #9095 and #9099.

Overriding the supplemental method _expire_cookie() looks saner than overriding (super method) trac.auth.LoginModule._do_logout() and still calling it later on as well.

Thanks to janakj for another non-trivial contribution.

(In [11086]) AccountManagerPlugin: Ensure sensible browser cookie lifetime setting, refs #8927, #9088, #9095, #9099 and #9547.

I think this is now the most intuitive setting of default cookie lifetime: auth_cookie_lifetime from section [trac] gets overwritten with AcctMgr default (30 d) as long as it's found equal to the Trac default (0).

Remember, that the AcctMgr feature still has to be switched on with the boolean option persistent_sessions, that defaults to False, if unset.

Does the weirdness prevail? I'd assume this has been fixed meanwhile, if there's no more complaint. Feedback welcome.

These are known issues with anonymous tickets and ticket comments: Requests doesn't get answered for weeks or months, if ever - you'll never know.

At least this no longer looks like a severe issue to me. I'll allow it to survive the next stable release, but certainly not longer. Running down through the comments yields evidence that the less-than-average description quality has improved, but the remaining "coss-visit" issue for one user in another ones preferences is not at all reproducible. Furthermore it might even be a side-effect of the pretty much off-standard web-server configuration for Trac user preferences mentioned earlier in this ticket.

Needinfo flag remains, because I really hope to get more feedback based on testing the current AcctMgr code.

(In [12312]) TracAnnouncer: Update AccountManagerPlugin messaging support, refs #7759, #7977, #8740, #8927, #9090 and #9204.

This long-standing regression is fixed now, while associated message templates are rather bare-bone ones yet and formatting could be improved significantly.

(In [12325]) TracAnnouncer: Fix generator, that was broken by [12309], refs #7759, #7976, #7977, #8740, #8927, #9090 and #9204.

And the same bad filter code even got replicated in [12312]. Sorry for not checking compiler errors earlier. Finally I discovered an UnboundLocalError for resource_id hidden behind the first error. Obviously unit tests are a blessing and needed here too.

(In [12331]) TracAnnouncer: Really fix filter now, refs #7759, #7976, #7977, #8740, #8927, #9090 and #9204.

Complete the change from [12325] to get expected behavior, or filters would be applied undesirably.

(In [12342]) TracAnnouncer: Add 'acct_mgr' as default for 'filter_exception_realms' option, refs #7759, #7976, #7977, #8740, #8927, #9090 and #9204.

IMHO this is required for better plugin usability, making AccountManagerPlugin notifications pass without additional configuration effort now.

Some Python doc-string tweaks and another unit test slipped in here too.

(In [12353]) Refs #7759, #7976, #7977, #8740, #8927, #9090 and #9204: Fixed minor syntax error introduced in [12342].

Any status update?

Sure, the login issue still looks about wired, but this is most probably a local installations/configuration issue.

Please provide feedback about the effect of seemingly relevant changes after 18-Aug-2011 to allow further progress. Currently, without confirmation and fresh ideas I can't do anything about it, and I'll close the issue assuming it's resolutions by some of the changes before acct_mgr-0.4 release.

I was using Trac 0.12 and Account Manager 0.31 for a year now and it worked stable. I moved to trac 1.0 recently and am now upgaring account manager plugin and see what happens.

By chance this could be related to #10700, even if a valid hash method is reported to be enabled in the component section shown here.

(In [12441]) AccountManagerPlugin: Propagate errors from AccountModule._reset_password, refs #7111, #8927, #10700 and #10701.

Thanks for the recent, anonymous hint on this issue, that originates from [10313] (btw, a fix for a much more serious issue).

Replying to MarcR:

I was using Trac 0.12 and Account Manager 0.31 for a year now and it worked stable. I moved to trac 1.0 recently and am now upgaring account manager plugin and see what happens.

If you didn't proceed, upgrade to the latest release, acct_mgr-0.4.2 as of today, and provide relevant feedback related to this ticket's defect claims, please. I fell that the code has advanced significantly, so I'm determined to get the list of open issues to reflect this as well.

I read in SVN under README.upgrade the follwoing lines:

Upgrading acct_mgr-0.3.2 -> 0.4

---

'password_file' is depreciated and no longer used by any authentication store provided by AccountManagerPlugin itself.

Until now I've been using .htpasswd to store user Passwds and Accountmanager 0.3.1 to manager permissions of users in my trac(s). I asume this means that this method will not work any longer? Since my users have changed their own passwords wich are hashed right now in the .htpasswd file, how can I transfere their passwords to the new location and where is this now?

Replying to anonymous:

I read in SVN under README.upgrade the follwoing lines:

...

Until now I've been using .htpasswd to store user Passwds and Accountmanager 0.3.1 to manager permissions of users in my trac(s). I asume this means that this method will not work any longer? Since my users have changed their own passwords wich are hashed right now in the .htpasswd file, how can I transfere their passwords to the new location and where is this now?

Thanks for reading that note. Obviously I've been unable to make the point totally clear to everyone. What this means it, that options have been renamed to enable using separate files for different password stores. Just rename the option to the correct new name as advised for the file store that you use, no need to change file nor path or anything else.

And don't hijack tickets, but use our mailing list for general support, please. Thanks for taking care.

Unfortunately, passwd on my system worked in 0.3 but does not work anymore in 0.4.2.

• user can change his password via "settings" menu
• changed passwd is written in /var/trac/TracProject1/.htpasswd
• user can request new passwd
• new passwd is sent to his email address
• new passwd is not written into /var/trac/TracProject1/.htpasswd
• => therefore the new passwd can not be used for logging in
• login via old passwd results in the system asking to change the pwd (wich is ok).

As I said, this worked before in ver accountmgr ver 0.3.

Some data of my config files:

trac.ini:

[account-manager]
account_changes_notify_addresses = xxxx@yyyy.de
force_passwd_change = true
hash_method = HtPasswdHashMethod
htpasswd_file = /var/trac/TracProject1/.htpasswd
htpasswd_hash_type = md5
login_attempt_max_count = 0
notify_actions = change,delete
password_store = HtPasswdStore,SessionStore,SvnServePasswordStore
persistent_sessions = true
refresh_passwd = true
verify_email = true

[components]
acct_mgr.admin.accountmanageradminpage = enabled
acct_mgr.admin.accountmanageradminpages = enabled
acct_mgr.admin.accountmanageradminpanel = enabled
acct_mgr.api.accountmanager = enabled
acct_mgr.db.sessionstore = enabled
acct_mgr.guard.accountguard = enabled
acct_mgr.htfile.abstractpasswordfilestore = enabled
acct_mgr.htfile.htdigeststore = disabled
acct_mgr.htfile.htpasswdstore = enabled
acct_mgr.http.httpauthstore = disabled
acct_mgr.notification.accountchangelistener = enabled
acct_mgr.notification.accountchangenotificationadminpanel = enabled
acct_mgr.pwhash.htdigesthashmethod = disabled
acct_mgr.pwhash.htpasswdhashmethod = enabled
acct_mgr.register.basiccheck = enabled
acct_mgr.register.emailverificationmodule = enabled
acct_mgr.register.usernamepermcheck = enabled
acct_mgr.svnserve.svnservepasswordstore = enabled
acct_mgr.web_ui.accountmodule = enabled
acct_mgr.web_ui.emailverificationmodule = enabled
acct_mgr.web_ui.loginmodule = enabled
acct_mgr.web_ui.registrationmodule = disabled
acct_mgr.web_ui.resetpwstore = enabled

https.conf:

<Location /projects/TracProject1>
	SetHandler mod_python
	PythonInterpreter main_interpreter
	PythonHandler trac.web.modpython_frontend 
	# PythonOption TracEnvParentDir /var/trac
	PythonOption TracEnv /var/trac/TracProject1
	PythonOption TracUriRoot /projects/TracProject1
</Location>
<Location /projects/TracProject1/prefs>
	AuthType Basic
	AuthName "FKEM User settings"
	AuthUserFile "/var/trac/TracProject1/.htpasswd"
	Require valid-user
</Location>

---

Great, some news!

But don't change ticket properties here, please. Not just because you can and you think you should. It looks like showing-off, even if unintended. The only way to get it right is to convince me about a possible issue, that I don't know/understand yet. Convince me, and I'll change ticket properties according to my perception. I hope, we can agree on that terms.

Now, let's see at your** newest findings. (** Because you do resist repeatedly to show a traceable identity, I'm not even sure, that I speak/write to the same person each time. This is not exactly nice playing, you see?

Replying to anonymous:

Unfortunately, passwd on my system worked in 0.3 but does not work anymore in 0.4.2.

Your perception, what I can imagine. But let facts speak for themselves, nothing else, ok? Thanks for testing latest maintenance release code, btw.

* user can change his password via "settings" menu * changed passwd is written in /var/trac/TracProject1/.htpasswd * user can request new passwd * new passwd is sent to his email address

Ok so far, fine.

* new passwd is not written into /var/trac/TracProject1/.htpasswd

Why should it? Did you read any note about the changed password reset procedure? Obviously not - just one more point for me to finally pull this ticket down in the near future.

* => therefore the new passwd can not be used for logging in * login via old passwd results in the system asking to change the pwd (wich is ok).

Plain-wrong. In fact you should see a new component acct_mgr.web_ui.ResetPwStore, that must be enabled. You have it in the last line of your trac.conf excerpt:

As I said, this worked before in ver accountmgr ver 0.3. Some data of my config files:

trac.ini:

[account-manager]
# skipped

[components]
acct_mgr.admin.accountmanageradminpage = enabled
acct_mgr.admin.accountmanageradminpages = enabled
# Old, no longer valid.

acct_mgr.admin.accountmanageradminpanel = enabled
# Keep just that one.

# skipped some more

acct_mgr.register.basiccheck = enabled
# Only that? If used with email verification you'll need at least
# acct_mgr.register.EmailCheck = enabled
# or you wont even get the email input to fill an initial email address into.

acct_mgr.register.emailverificationmodule = enabled
acct_mgr.register.usernamepermcheck = enabled
acct_mgr.svnserve.svnservepasswordstore = enabled
acct_mgr.web_ui.accountmodule = enabled

acct_mgr.web_ui.emailverificationmodule = enabled
# Obsolete again, notice the new place above.
# Btw, all that is covered by README.upgrade.

acct_mgr.web_ui.loginmodule = enabled
acct_mgr.web_ui.registrationmodule = disabled
acct_mgr.web_ui.resetpwstore = enabled
# Here we are.

Resetting your password you actually end up with two passwords before next valid login:

• Login with the new one (stored in ResetPwStore) to silently and finally overwrite the old with the new.
• Login with the old will just chancel the latest new password request. Good for anyone trying to just annoy you, you see?

Hope you'll find it all well now after my explanation. I added that and some reference in related pages after finding a lengthy explanation only in changeset [10264] and the related ticket #816), so this slight documentation issue is fixed at least now as well. Thanks for driving me into it, honestly.

See: AccountManagerPlugin/Modules, RegistrationInspector

#10762 has been closed as a duplicate of this ticket. But it has a much clearer focus just in the password reset stopping to work beyond acct_mgr-0.4 release, and proposed patch as well, repeating it here for convenience:

--- acct_mgr/web_ui.py	(revision 12517)
+++ acct_mgr/web_ui.py	(working copy)
@@ -143,7 +143,7 @@
         return is_enabled(self.env, self.__class__) and \
                self.reset_password and (self._write_check(log) != []) and \
                is_enabled(self.env, self.store.__class__) and \
-               self.store.hash_method
+               (self.store.hash_method is not None)
 
     reset_password_enabled = property(_reset_password_enabled)

I feel this is finally getting us close to a real solution, yet I fail to understanding it immediately.

Replying to hasienda:

#10762 has been closed as a duplicate of this ticket.

I indeed saw this ticket before to write mine, but I never thought it could be a duplicate. Sorry.

So, let me explain how I came to that 'patch'.

In LoginModule._remote_user(), there is a if acctmod.reset_password_enabled == True: that fails (I checked with a code to log the value of the test), and then the function returns None instead of the user name (the ResetPwStore is not used ???).

I then added a code to log the value of reset_password_enabled, and iirc it is a HtDigestHashMethod object. My idea was that such an object can not be compared to True and that the reset_password_enabled getter should rather return a boolean, hence the patch.

My knowledge of python is however limited, so perhaps I missed something else...

With the patch applied, I can login using the auto-generated password, the password_reset user's account attribute is deleted, and the password is stored in the .htdgest file.

(In [12536]) AccountManagerPlugin: Correct AccountModule._write_check logic, refs #8927.

Better return a boolean value as suggested, sure, but different way. Thanks to Samuel Degrande for giving valuable hints towards this solution.

(In [12537]) AccountManagerPlugin: Fix a possible DOS, when disabling some AccountManager components, refs #8927.

Disabling configured or default hash method throws an AttributeError with AccountModule enabled after a recent change in [12442]. This would actually yield a DOS situation for the affected Trac environment, requiring terminal access to fix trac.ini manually, what is a worst-case result for any web-UI action IMHO.

(In [12538]) AccountManagerPlugin: Remove private attribute AccountManager._password_store, refs #8927.

It has been obsoleted by removing support for legacy option 'password_format'. Adding and further improving debug logging for common configuration errors.

Today I received positive feedback from Marc: Issues remain on his workstation using for Chrome and IE9, but the password reset worked well for two accounts. So regarding this ticket this should count as success.

(In [12610]) AccountManagerPlugin: Publish maintenance release 0.4.3, closes #8927, #10681, #10765 and #10871.

This is another update for current stable acct_mgr-0.4 to immediatly push the fix against trac.ini corruption and other recent corrections.

Note though that an unnecessary msgid change from [12490] has been excluded and - as exception to the rule - there is a solution rated as 'feature' too.