Modify

Opened 5 years ago

Closed 23 months ago

#5566 closed defect (fixed)

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

Reported by: anonymous Owned by: agitronic
Priority: normal Component: SharedCookieAuthPlugin
Severity: major Keywords: auth permission
Cc: boftx@…, macjoost@…, otaku42, rjollos Trac Release: 0.11

Description

I installed this module in an inherited plugins dir and enabled in an inherited .ini file. After logging out on all projects, and starting up a new browser, I only had full permissions on the project I logged in on. When visiting other projects I show as being logged in but have no permissions. Needless to say I consider this a major bug in what is otherwise a very useful plugin.

The Trac site uses AccountManager and UserManager together (with the AccountManager admin panel disabled). There is also a common .htpasswd file in use.

The Trac 0.11 site is running on Solaris 10, python 2.5, and Apache 2.2 with mod_python.

Attachments (1)

common_cookie_table.diff (38.7 KB) - added by rlrj60 - common shared cookie and session 3 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 5 years ago by anonymous

  • Cc boftx@… added

comment:2 Changed 5 years ago by k0s

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

comment:3 follow-up: Changed 5 years ago by boftx@…

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.)

comment:4 in reply to: ↑ 3 Changed 5 years ago by k0s

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

comment:5 Changed 5 years ago by anonymous

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

comment:6 Changed 5 years ago by anonymous

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

comment:7 Changed 5 years ago by izzy

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.

comment:8 Changed 5 years ago by ibestuzhev

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

comment:9 Changed 5 years ago by macjoost@…

  • Cc macjoost@… added

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...

comment:10 Changed 5 years ago by anonymous

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.

comment:11 Changed 3 years ago by hasienda

  • Keywords auth permission added

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.

comment:12 follow-up: Changed 3 years ago by k0s

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

comment:13 in reply to: ↑ 12 ; follow-up: Changed 3 years ago by hasienda

  • Cc otaku42 rjollos added

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.

comment:14 in reply to: ↑ 13 Changed 3 years ago by rjollos

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).

comment:15 follow-up: Changed 3 years ago by 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.

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).

Changed 3 years ago by rlrj60 - common shared cookie and session

comment:16 Changed 3 years ago by k0s

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

comment:17 in reply to: ↑ 15 Changed 3 years ago by hasienda

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.

comment:18 Changed 3 years ago by hasienda

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.

comment:19 Changed 3 years ago by hasienda

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

comment:20 Changed 3 years ago by agitronic

  • Owner changed from k0s to agitronic

comment:21 Changed 23 months ago by agitronic

  • Resolution set to fixed
  • Status changed from new to closed

(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.

comment:22 Changed 23 months ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:23 Changed 23 months ago by anonymous

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.