No permissions granted but shows as "logged in as username"

i have seen this before but have been unable to reproduce :(

I realize I can go digging in code to find where the cookie gets read, but being new to Python and Trac, can you give me a hint to what file to start with? I am well-versed in session control using Perl and Apache, etc. so I might be able to track it down if given a starting point. Thanks in advance. (My boss would love our multi-project Trac if he only had to login once. As it stands he almost refuses to use it, bummer.)

Replying to boftx@hotmail.com:

I realize I can go digging in code to find where the cookie gets read, but being new to Python and Trac, can you give me a hint to what file to start with? I am well-versed in session control using Perl and Apache, etc. so I might be able to track it down if given a starting point. Thanks in advance. (My boss would love our multi-project Trac if he only had to login once. As it stands he almost refuses to use it, bummer.)

not really sure; i had a theory on why it could fail, but it is only true if ShareCookieAuthPlugin? was enabled on only a few Trac projects. If I see it reproduced in the wild I will try to debug. Otherwise, its hard to guess

Same problem here. When going to a different project, the rights are missing, user is logged in but can't do really much :(

Same here, I started eith enabled the plugin on a single project first and then via a global inhereted trac.ini

So I am in good company. Same problem, configuration as described with the initial comment (multiple projects via TRAC_PARENT_ENV, the plugin enabled in the main configuration and inherited by all environments.

Have the same problem. Some information is stored in DB, not in cookies browser:trunk/trac/web/auth.py#L148

Perhaps this is the problem, because record with user's hex_entropy exists only in one environment

Hi all,

I've tried this plugin today. I'm also getting permission errors.

I'm using mod_python and PythonOption TracEnvParentDir. The (I think) relevant settings are in one "shared" trac.ini.

I've got some rather "open" projects and one "closed" projects. In this closed project you need to be logged-in to see anything. I'm using AccountManagerPlugin and NoAnonymousPlugin.

When I start (login) in the open project and then to to the closed project, I get

Error: Forbidden
WIKI_VIEW privileges are required to perform this operation on WikiStart

A logout-login solves this.

Hope this helps...

Same problem for me.

One thing I noticed is that there are more cookies:

trac_session trac_from_token

Their path is relative to the trac environment. They only show up in the environment I log in. The other environments do not have these cookies. They seem to have information from the db (not checked, there is a session related table).

Hope this helps.

Trying to implement SSO style Trac login I'm hitting this barrier too.

Since I use and maintain AccountManagerPlugin, first step has been to patch that plugin, especially to know about the new auth_cookie_path option. Sadly there has been no progress here for a long time, so that the SharedCookieAuthPlugin possibly has never lived up to it's promises for a number of users.

Still anyone interested to make this work? I do even consider implementing shared cookie functionality in AccountManagerPlugin itself, in case there is no more support here.

I no longer maintain this plugin but would happily give the plugin, and the ticket, to any interested party

Replying to k0s:

I no longer maintain this plugin but would happily give the plugin, and the ticket, to any interested party

Ok, sad to hear that, but thanks for making a clear statement. So flagging the plugin's wiki page with needsadoption would be a good idea, right? If I succeed in fixing this, I'll consider taking maintenance officially. But I'd not want to stand in the way, if someone else feels like contributing some ideas and time, since I've already loaded way too much on my desk.

Replying to hasienda:

So flagging the plugin's wiki page with needsadoption would be a good idea, right?

I think that would be a good thing to do. My situation is similar to yours. Previously I'd come across a plugin that needed some patching, would adopt the plugin and patch it, but then find myself without time to maintain it. The approach I frequently take now is to contact the author for approval to commit against their project, patch the project and then tag it as needsadoption (provided the author has indicated they no longer wish to maintain it, which is the usual occurrence).

I have over 40 projects at works and many frustrated of having to sign on every one of them. So I really appreciated the intention of the plugin. Unfortunately, session and auth cookies are very tricky to override. Finally I got a hang of that, but end up with a massive modification to get it working.

Basically, all projects must use the same session and auth_cookie tables. Trac uses the tables for login authentication and permission checking once a session is established. The only way to do that is with MySQL backend, not with SQLite3. MySQL allows accessing other database (or schema) via the "dot" notation. For example, every project can access the session table in a common project "trac_tools" via trac_tools.session. In summary, my changes include:

• Migrate to MySQL database backend
• Change all SQL statements on session table to trac_tools.session
• Change all SQL statements on auth_cookie table to trac_tools.auth_cookie
• Add auth_cookie_path to trac.ini (Trac >= 0.12 required)

   [trac]
   auth_cookie_path = /
  

Here is my attachment:common_cookie_table.diff against the Trac-0.12.2 base and AccountManager (with a RememberMe patch which is not necessary).

I no longer maintain any of my Trac plugins. However, I would be happy to give access to any qualified person willing to do so

Replying to rlrj60:

I have over 40 projects at works and many frustrated of having to sign on every one of them. So I really appreciated the intention of the plugin. Unfortunately, session and auth cookies are very tricky to override. Finally I got a hang of that, but end up with a massive modification to get it working.

I'll certainly look into your modifications, since I intend to make it work too, but as generically as possible.

From a first look at your patch I just want to throw out some basic warnings for early adopters of your approach. Beware:

• Trac patches include table rename, that makes your environment incompatible with unpatched Trac installations
• AcctMgr patches make patched code incompatible to Trac 0.11
• AcctMgr patches include an duplicated Option definition for auth_cookie_path, that is already defined in Trac core since 0.12 (Hint: you'll need env.config.get() here instead)

Basically, all projects must use the same session and auth_cookie tables. Trac uses the tables for login authentication and permission checking once a session is established. The only way to do that is with MySQL backend, not with SQLite3. MySQL allows accessing other database (or schema) via the "dot" notation.

I'm no db expert, but I almost sure that you can do this with PostgreSQL too, since it has multi schemes as well.

Just a few pointers as I engage into more work towards SSO for Trac with AccountManagerPlugin:

Reading some code it seems like trac.web.auth.LoginModule._get_name_for_cookie kills trac_auth browser cookies, if the value isn't found in auth_cookie Trac db table. In Trac trunk trac-r10345 (Trac 0.13dev) relevant code has been factored out into trac.web.auth.LoginModule._cookie_to_name.

Tracking my effort to get SSO working in #9676 - but with AccountManagerPlugin for now.

(In [12348]) Fix multiple call to authenticate problem, closes #5566.

There seem to be a possibility that the authenticate method is called multiple times during the processing of a request.

Also the '0.11' directory has been renamed to 'trunk' and monkey patching has been disabled.

The problem with trac.web.auth.LoginModule? killing trac_auth cookies still seem to need to be addressed. So the problem wasn't completely solved.

OK, there is an workaround for this. Basically what needs to be done to avoid having the auth_cookie expired is to have only one project keeping track of the auth_cookie. This can be done by disabling the default authentication mechanism in the other projects (as described on the wiki now). The downside is that the login and logout will not be available in the other projects.