try to look into the database:
http://www.sqlite.org/sqlite.html
there are the tables session and session_details. are there any rows in it?
1) Happens with all new users, not just deleted and recreated.
2) We're using postgresql
3) There's a session table with a bunch of sessions in them. "select
count(*) from session;" returns 46599
4) No session_details table:
I hope that helps, thanks for the quick reply!
Chris
Chris
1) Tried removing all permissions from anonymous.
2) Tried removing all permissions from authenticated.
3) Tried removing a slew of permutations as such.
4) Tried giving the different accounts direct permissions rather than
the virtual permissions of readonly_access
Here are the applicable permissions:
User Action
-------------------------------------
anonymous readonly_access
authenticated TICKET_APPEND
authenticated TICKET_CHGPROP
authenticated TICKET_CREATE_SIMPLE
readonly_access BROWSER_VIEW
readonly_access CHANGESET_VIEW
readonly_access FILE_VIEW
readonly_access LOG_VIEW
readonly_access MILESTONE_VIEW
readonly_access REPORT_SQL_VIEW
readonly_access REPORT_VIEW
readonly_access ROADMAP_VIEW
readonly_access SEARCH_VIEW
readonly_access TICKET_VIEW
readonly_access TIMELINE_VIEW
readonly_access WIKI_VIEW
This is a limitation of the AccountManager plugin. If two users are
trying to register simultaneously it will cause this error since the
fileinput module detects that it's already trying to write to the
file. A synchronization method would help here, but you've probably
got too many users to practically support an htpasswd file. The
frequent user registrations make a collision more likely and the file
will take longer to write as it grows in size, so that's also going to
contribute to the problem. I've just started on a backend to store
passwords in the database which will be better for sites with many
users. It should be able to handle passwords in the htpasswd or
htdigest formats so that either of these can be imported into the
database.
-- Matt Good
I'll test this tonight by pointing account manager at a blank file and
will let you know the results. This definitely makes sense to me though,
thanks for the detailed explanation.
Chris
So I just tested this. I changed the file to an empty file in
trac.ini and then restarted lightty. Upon trying to register, I'm
seeing the same problem.
Chris
Well, the file-based storage obviously has serious limitations on
large sites. I've just committed a new SessionStore which stores user
passwords in the session_attributes table. By default it will store
passwords in htdigest format, but it can also be used with htpasswd
format by setting "hash_method = HtPasswdHashMethod" in trac.ini.
I've added a script to the source in "contrib/sessionstore_convert.py"
to move existing user passwords into the database. Call it like
"python sessionstore_convert.py myproject". It will check the config
for the current password file and format used and add the users to the
database, make the necessary changes to the config and save it. You
may need to enable the components if you don't have "acct_mgr.* =
enabled" in your config. I've tested it out a bit, but it's brand new
so if you experience any problems please report them on the trac-hacks
site.
-- Matt Good
how does this help to access the subversion repository? via trac, we
tried to get "web based administration of trac/svn permissions".
-solo
--Noah