Modify

Opened 15 years ago

Closed 11 years ago

Last modified 8 years 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@…, Michael Renzmann, Ryan J Ollos 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 13 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 Changed 15 years ago by anonymous

Cc: boftx@… added; anonymous removed

comment:2 Changed 15 years ago by Jeff Hammel

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

comment:3 Changed 15 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 15 years ago by Jeff Hammel

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 15 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 14 years ago by anonymous

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

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:7 Changed 14 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.

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:8 Changed 14 years ago by Igor

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

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:11 Changed 13 years ago by Steffen Hoffmann

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 Changed 13 years ago by Jeff Hammel

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 ; Changed 13 years ago by Steffen Hoffmann

Cc: Michael Renzmann Ryan J Ollos 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 13 years ago by Ryan J Ollos

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 Changed 13 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 13 years ago by rlrj60 - common shared cookie and session

Attachment: common_cookie_table.diff added

comment:16 Changed 13 years ago by Jeff Hammel

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 13 years ago by Steffen Hoffmann

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 12 years ago by Steffen Hoffmann

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 12 years ago by Steffen Hoffmann

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

comment:20 Changed 12 years ago by agitronic

Owner: changed from Jeff Hammel to agitronic

comment:21 Changed 11 years ago by agitronic

Resolution: fixed
Status: newclosed

(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 11 years ago by anonymous

Resolution: fixed
Status: closedreopened

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.

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:23 Changed 11 years ago by anonymous

Resolution: fixed
Status: reopenedclosed

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.

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:24 Changed 8 years ago by Ryan J Ollos

In 15064:

0.1.4: Remove unused code

This is a follow-on to [12348].

Refs #5566.

comment:25 Changed 8 years ago by Ryan J Ollos

In 15071:

0.1.4: Tag version 0.1.4

Refs #5566.

comment:26 in reply to:  22 Changed 8 years ago by Ryan J Ollos

Replying to anonymous:

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.

As noted in comment:18, the issue is that the cookie is expired when delegating authentication. I implemented a fix in #12592.

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain agitronic.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


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

 
Note: See TracTickets for help on using tickets.