login/logout, authentication, and authorization

[Matthew Good <matt-good.net>]

I'm kind of combining a couple of things from #599 and #788 here. The main issue is that the browser caches the authentication information, so you can't log out unless you close the browser (or with Mozilla you can use certain extensions to clear the information). A related issue is that in situations where authentication is enforced to access the project, users should never be logged in anonymously.

I've already gotten a patch working that will force users who logged out to log back in, allowing them to login as a different user. I'm going to try to extend this to allow users to disable anonymous access and handle these setups more appropriately.

[vittorio]

The problem with an enforced authentication apache setup (always authenticate, not only on ../login) is following:

I login as user A, im logged in as user A. I am closing all browsers. I login as user B. I am still logged in as user A! I click on logout -> I get user B.

If i delete all cookies before login, authentication works as expected.

[vittorio]

changing priority and severity cause users are able to login as a different user without knowing the password, and maybe worse, are logged in as a different user without knowing it. (in enforced authentication setup)

[jonas]

Removing "[merge]"-prefix because no patch is attached...

[daniel]

Emailed matt and asked about the patch.

[Matthew Good <matt-good.net>]

partial implementation

[cmlenz]

More information about comments 1 and 2 by vittorio: When authentication is enforced for the complete project (as opposed to just the /login URL), we set both the cookies trac_auth and trac_session, which looks like:

  Set-Cookie: trac_auth=6ae279aadc6c265ff34345d72981a8e8; \
              Path=/mptrac/trac; \
              trac_session=6c4f7e717273952a267287f2; \
              expires=Mon, 05-Feb-2018 17:15:50 GMT; \
              Path=/mptrac/trac;

(line breaks for better readability)

This is supposed to result in a trac_auth cookie that expires at the end of the browser session, and a trac_session cookie that expires sometime in the distant future. But actually it results in only a trac_auth cookie that is set to expire in 2018, and no trac_session cookie at all.

That's the reason why this behaviour has first been encountered after the introduction of sessions, which added the second cookie.

Although this ticket isn't exclusively about that problem, I'm raising its severity to blocker for 0.8. This is serious stuff.

[cmlenz]

If I'm not mistaken, we should actually split the Set-Cookie header in two:

  Set-Cookie: trac_auth=6ae279aadc6c265ff34345d72981a8e8; \
              Path=/mptrac/trac;
  Set-Cookie: trac_session=6c4f7e717273952a267287f2; \
              expires=Mon, 05-Feb-2018 17:15:50 GMT; \
              Path=/mptrac/trac;

[Matthew Good <matt-good.net>]

Ok, this may sound a little strange, but I think it's a reasonable solution that will provide for decent security and allow for us to still use Apache to test the login information so we can keep a single sign on with SVN.

Basically what we can do is provide an HTML page with a login form. When the user submits the form, Trac internally makes a request to a URL (set in the config) that requires authentication. It passes the username and password from the form to the URL, and uses the server's response (200, 401, 403, etc.) to determine whether the login is correct.

We'll also have to provide the configuration option to disable anonymous access. In this is enabled we'll have to redirect to the login form if the user is not logged in.

There might need to be some changes to the way login sessions are handled in the DB, but I'll look at that later.

[jonas]

[966] solves the "cookie problem" described in the comments but do not address the original problem. The remaining problem do not however block the 0.8 release so I'm rescheduling...

[steve.yen@…]

+1 on this. We're using trac for tracking internal sw development, but it'll have an exposed url so that employees can access it from home/on-the-road. I believe a logout should mean a full logout in this scenario. If someone's working from an internet cafe, reminding them to fully close their browers all the time isn't smooth. Thanks for the great work.

[anonymous]

Could we get an updated patch for 0.8.1? The logout bug is really a showstopper for a lot of people.

[shawn.debnath at sun.com]

Hey guys, first off must congratulate you guys on writing such a great piece of software. We are starting to look at several SCM solutions, and the SVN + Trac combo looks particularly attractive to us. I would really appreciate if you guys could release a temporary patch for 0.8.1 release and integrate into 0.9. A lot of important "stuff" needs to be protected, and as mentioned above, requiring employees to close browsers after hitting logout seems a bit redundant. Thanks!

[shawn.debnath at sun.com]

Attempting to patch the attached patch in this bug results in:

(none):/usr/lib/python2.3/site-packages# patch -p0 < ~/logout.patch <br> patching file trac/core.py<br> Hunk #1 FAILED at 291. Hunk #2 FAILED at 332. Hunk #3 succeeded at 416 with fuzz 2 (offset 7 lines). Hunk #4 FAILED at 428. 3 out of 4 hunks FAILED -- saving rejects to file trac/core.py.rej patching file trac/auth.py

[shawn.debnath at sun.com]

Added patched up 0.8.1 core.py, download and enjoy!

[shawn.debnath at sun.com]

Added patched up 0.8.1 auth.py. Download and enjoy!

[shawn.debnath at sun.com]

So for those interested, I have attached the core.py and auth.py with the logout fix. However, seems like my browser (Safari) is not respecting the no-cache directives :-/ Perhaps its a bug...someone could help by following up on this. Till then if you are running the 0.8.1 trac release, install the attached .py's and the logout should be fixed.

[mgood]

Please use the preformatted text formatting when pasting snippets from the command line, and attach patches rather than whole files.

The patch that I attached originally does provide for some logout capabilities, unfortunately there are some problems with it to which no one has found a reasonable solution.

The main issues are that it still doesn't work as expected if authenitication is required for the whole Trac project (no anonymous access), and it's still not really protected against someone logging in as the previous user. It relies on a cookie that indicates that the person chose to log out. However, since the browser is still caching the user's authentication, someone can simply alter the cookie, click login, and they're back as the old user.

I suppose at this point that we probably should remove the logout link until someone comes up with a reasonable solution for making it work.

[richard.musil@…]

I have applied both core.py and auth.py to 0.8.1 release. The login/logout seem to work better right now. However I am able (instead of logging in with valid credentials) to choose "Create New Session (without auth info required)". Once I do this, I get complete access to the project (as anonymous). I can still log in as authenticated user, but after logging out (as authenticated user) I still have access to the project (again as anonymous user).

In other words, it seems after creating "Anonymous session" the login/logout stops working correctly.

I am using mod_python and multiple project setup (using TracEnvParentDir? option)

[anonymous]

I think Matthew's idea sounds like a nice solution. The current approach for logins (i.e. relying on browser-based HTTP authentication) makes real logouts "impossible". After logging out, just click on Login again. Do you get prompted for your username/password? I don't (with Trac 0.8.2). If there is a way to force browsers to forget login credentials without closing the browser, I'd like to learn it.

IMHO, the security model must not depend on browsers "doing the right thing". It also must not depend on a "loggedout cookie", since that just provides a false sense of security to the user; the login info is still in the broswer (as mgood points out).

Bumping severity and priority up a notch. I was tempted to remove the word "forced" from the summary because this flaw (i.e. reliance on browser behavior for security) exists in the recommended configuration, not just "forced authentication" configurations. Maybe this should be a new ticket and mark this one as a dup of the new one?

[mgood]

If you use Firefox there are some extensions that will allow you to clear your authentication without closing the browser.

The main problem that was discussed regarding my earlier suggestion for how to handle our own login form is that you can no longer use digest authentication to protect the transmission of the password from the browser to the server. This would mean that you'd need to use HTTPS if you wanted any protection for the password.

[anonymous]

Using browser extensions that allow the user to logout is browser dependent and requires a two step logout (logout from Trac to nuke the session and logout in the browser to forget the credentials). It does not really solve the problem.

Yes, you would have to use HTTPS to secure the password with a form-based login, but people this concerned about security are probably already using HTTPS anyway. Ideally Trac could provide two different login/logout options: one using browser-based HTTP authentication (with no logout link since one can't really logout anyway) and one using form-based entry of credentials that get validated on the server. Then the Trac administrator can use whichever model suits their needs better.

Not providing strong(er) login/logout security is not going to impress people who worry about security (e.g. the decisions makers for my project).

[markus]

I'm voting +1 for the idea of the previous commenter, since this will possibly lead to better compatibility with IIS (see #1522) :-p

[David MacMahon]

Here is a thumbnail sketch of an idea that addresses/solves the logout converns expressed in this comment...

The problem has to do with browsers "remembering" username/password credentials for part of a web site (e.g. http://hostname/trac/login). The solution is to NOT password protect /trac/login, but instead password protect /trac/login/invite_*. Then trac will respond to /trac/login requests by generating (and remembering in the database) a random string "invitation" and redirecting the browser to /trac/login/invite_<random string here>. The user will then be required to authenticate based on that "invitation URL". Once trac sees the now-authenticated request for the "invitation URL" and verifies that the invitation present in that URL is valid (i.e. in the databse), trac will delete the inviation from the database so that it can't be used again (even if the browser remembers the credentials for the original invitation URL) and then create the auth record and cookie similarly to how it does it now. Below is some pseudo code that shows how I think this should all work. It probably has a few remaining details to work out, but I think it could form the basis of a better login/logout system...

if logout:
  if auth cookie present:
    delete auth record from database
    remove auth cookie and redirect to logout
  else: # auth cookie not present
    display logged out page
else if login:
  delete expired invitations from database
  if no invitation in extra path:
    if too many pending invitations for req's IP:
      display appropriate error page (prevents DoS)
    else: # ok to invite
      insert invitation record into database
      redirect to login/invite_... (preserving any "?ref=URL" in req)
  else: # invitation found in extra path (i.e. .../login/invite_...)
    if invitation from req is not in database:
      redirect to login (preserving any "?ref=URL" in req)
    else: # invitation is in database
      delete invitation record from database
      insert auth record into database
      set auth cookie and redirect to URL from "?ref=URL" or default
else: # Some other request
  if permission error:
    if no auth cookie: # Not logged in
      redirect to "login?ref=REQ_URL"
    else: # Logged in user is not authorized
      display appropriate error page
  else:
    dispatch request

Dave

[mgood]

The invite idea sounds interesting, however the browser seems to continue to authenticate itself for the rest of the site, not just the /login path. So, despite the difference in invite URLs, as far as I can tell, the browser will still automatically send the login information. Also, it doesn't address setups where authentication is required to get any access to the project.

[David MacMahon]

I just tried a few simple tests using both basic and digest authentication. Both schemes seemed to behave in a manner consistent with the invite idea with one small change. Instead of redirecting to /login/invite_<random string here> the redirect needs to be to /login/invite/<random string here. For the digest test, I used AuthDigestDomain /login/invite in the <Location /login/invite> section of httpd.conf. This behavior also seems consistent with http://www.ietf.org/rfc/rfc2617.txt (as far as I can tell). Can you provide more details about your tests?

You're right about this not helping if the entire project requires HTTP authentication. The idea is that one could (would have to) trust Trac's built in authorization mechanisms to protect the project (and remove all permissions from "anonymous"), yet use HTTP authentication to do logins via the invite method. In other words, Trac does all of the authorization once someone is logged in, but HTTP provides the authentication needed to get logged in. This wouldn't be acceptable to everyone and it wouldn't work conveniently (i.e. without ugly work-arounds) for sites that require HTTP authentication at even higher levels in the server's location-space, but it seems like it would make things better while still supporting HTTP digest authentication over HTTP.

Dave

[Steve Traugott]

+1 on implementing Dave's invite/* mechanism -- it's a one-time pad for authentication. His HTTP authentication + Trac authorization paragraph sounds about right, especially if you follow that by having ./logout clear the auth record from the db. Then always require a valid authorization record for all other requests, and redirect to ./login otherwise.

After I thought this all through I went back and actually read Dave's pseudo code, and it looks like he came to the same conclusions, and already has the high points covered.

Unless I'm missing something, I think the "entire site authenticated" problem is already handled here. If the entire site is password-protected by httpd, then we know the user has already authenticated if we see them in Trac code at all. All we have to do is handle authorization,and Dave's pseudo-code does that right, I think. Because of the redirect to login near the bottom, it looks to me like the user experience will actually be the same regardless of whether httpd only protects ./invite/*, ./login, or the entire site.

Are we missing anything else which would prevent this plan from working with both private and public sites?

I ran into all of these issues on a public site I'm setting up, BTW; GPL project but security-minded audience. Changing summary and keywords to reflect the thought that it's not a "forced" issue alone, and solving the general case is likely more desireable.

[Steve Traugott]

Okay, I finally saw what I was missing -- the "kiosk" problem. And I agree that we can't allow ourselves to trust the browser to forget things.

Dave, the AuthDigestDomain? directive doesn't seem to me like it *should* work for this -- we want sort of the opposite; a temporary realm for each ./invite/* URL, rather than a permanent one for the whole tree. It's late at night though, and I really need to make myself not do any more testing.

Temporary realms which dissolve when the user hits 'logout' -- I'm thinking it's going to need tracd, or at least discourage use of the cgi for secure sites, in favor of mod_python.

[Steve Traugott]

As an alternative to temporary realms -- having (e.g.) a mod_python authenhandler() return apache.HTTP_UNAUTHORIZED when the authorization record is missing seems like it ought to be dependable. It's still asking the browser to do something for us (forget the credentials and prompt the user again), but at least it's slightly better than relying on cookie state.

I'd like to try the temporary realms thing -- not tonight though. ;-)

[Steve Traugott]

Okay, this seems to work: it lets apache and the browser do the authentication steps, so no login form is needed, and it lets you add your own code for authentication against e.g. svn. (In my case, I'm authenticating against a mailman user db in that mmauth() call.)

All I did was add this handler to ModPythonHandler?.py and add a " PythonAuthenHandler? ModPythonHandler?" directive to httpd.conf. Haven't beat this to death yet, but at least it's now possible to switch users. And login now prompts for credentials after logout.

def authenhandler(req):
    mpr = ModPythonRequest(req)
    mpr.init_request()
    env = get_environment(req, mpr)
    if not env:
        return apache.HTTP_FORBIDDEN

    pw = req.get_basic_auth_pw()
    user = req.user
    if not mmauth(user, pw):
        return apache.HTTP_UNAUTHORIZED

    if not mpr.incookie.has_key('trac_auth'):
        # browser cache is clean -- let core and auth do their thing
        return apache.OK

    db = env.get_db_cnx()
    cursor = db.cursor ()
    cookie = mpr.incookie['trac_auth'].value
    cursor.execute ("SELECT name FROM auth_cookie WHERE cookie=%s" ,cookie)
    if cursor.rowcount < 1:
        # no auth record -- user must have logged out; convert to anon cookie 
        # and get them to log back in
        cursor.execute (
            "INSERT INTO auth_cookie (cookie, name, ipnr, time)" +
            "VALUES (%s, %s, %s, %d)",
            cookie, 'anonymous', mpr.remote_addr, int(time.time())
        );
        db.commit ()
        # XXX clear session cookie
        return apache.HTTP_UNAUTHORIZED

    authname = cursor.fetchone()[0]
    if user != authname:
        # looks like they logged back in as 
        # another user -- delete the auth record and let 
        # core.dispatch_request create a new one
        cursor.execute ("DELETE FROM auth_cookie WHERE cookie=%s", cookie)
        db.commit ()

    return apache.OK

[David MacMahon]

This seems to require basic authentication (so you can get the password from the request), which is only secure over https. I don't think it will help people who want to run digest authentication over http.

I'll have to go back and revisit my tests. I'm pretty sure they worked for both basic and digest authentication (even with AuthDigestDomain=/login/invite, which I agree seems counter-intuitive).

Dave

[cmlenz]

Nice discussion, but I really don't see this happening for 0.9.

[eblot]

#2228 has been marked as a duplicate of this ticket

[eblot]

#2350 has been marked as a duplicate of this ticket

[justin@…]

There is a perl-implemented script that logs out HTTP authenticated users at http://www.itlab.musc.edu/perl_logout. It is not the best implementation because it requires the pop-up of an authentication request box on logout, but it may have some value to this discussion.

It basically sends an authorization failed to the browser on the logout request, at which point the browser should discard the current auth information, and ask the user to log in again, at which point the user can cancel.

[mala]

On 07/08/05 18:28:48 Steve Traugott added some piece of code tothis ticket here. Has anyone tried it out or has experiences with it? I did not get it working. I inserted this into my mod_python_frontend.py and tried to activate on logout, but I could not. Does anyone know how to do so?

I do have the problem with the nothing-doing-logout and I am rid of this because trying any solution and failing to solve is getting on my nerves.

[jouvin@…]

I just read this thread. I was about to create a ticket on the same issue. But my needs were may be not exactly the same and I had in mind a slightly different (but probably complementary) approach.

We have some projects either with no anonymous access at all or with restricted areas accessible only to (some or all) logged in users. Currently if a not yet logged user enter such an area it received a 'XXX privileges are required to perform this operation'.

My idea was, instead of displaying the error message, if the user is not logged yet, to trigger a login operation (may be with an option in trac.ini like 'autologin' to enable this feature). This would be particularly nice when you are using certificates to authenticate as generally your certificate is already validated by http and the login operation doesn't need any input.

Any comment ?

[adeason@…]

I uploaded my attempt at a patch for this. It executes an internel request for '/login', which is expected to have some sort of HTTP authentication from the server. I think this only works if you have projects in the form http://trac.company.com/project, since the login form is displayed at /project/login, and the internal request happens at /login. If someone would like to make this work in the more general case, I'd like to see how. I'm also very new to trac development and trac in general, so I apologize in advance for how much I screwed up this patch. (However, it does appear to work on my installation.)

[adeason@…]

A patch for login using a form, instead of direct HTTP auth

[adeason@…]

A patch for logging in using a form instead of direct HTTP auth, and for actual logouts to work. Uploaded the wrong version of this patch previously; this one should work.

[eblot]

There is no justification for changing the component. The login/logout issue is not specifically related to the timeline.

[coderanger]

I have created a plugin project at trac-hacks based off the most recent patch. If you would like commit access please just email me at coderanger@…, and I will ask Alec.

[anonymous]

日本語を入れてみる テスト

[nikolas.hagelstein@…]

I dont see how AuthFormPlugin? should fix the disable anonymous access by adding requiere-valid user to the whole site?!. Any news on that? Imho the login form covers the login/logout issue but what about just introducing a "anonymous_access=disabled" flag to track.ini which forces the "loginform" to come up?

[anonymous]

The AuthFormPlugin has nothing to do with access control, it it simply a modified authentication system to allow for "true" logout. If you want to disallow anonymous access just remove all permissions from the anonymous virtual user.

[Andrejs Cainikovs]

Seems nobody is willing to fix this bug for more than 2 years[[BR]] After logging out, just click on Login again. Do you get prompted for your username/password?

[cboos]

#3577 points to a Javascript solution that would work for IExplorer and Firefox browsers. That solution is available at TracHacks:TrueHttpLogoutPatch and #3577 proposed that we implement that solution in Trac itself.

At first glance, that solution is a bit limited cross-browser wise, but maybe it's better than nothing.

[anonymous]

It's ridiculous that such a critical bug gets little to no attention from the developers of this project. This ticket has been open for 3 years for goodness sake! If you want Trac to grow and be adopted by a large number of software projects, you had best consider security a core requirement. After all, issues like this have already been solved by the software packages you are essentially trying to integrate/replace (Mantis, wikis, et. al).

[nkantrowitz]

This is not a blocker, as Trac is still usable. If you dislike the caching behavior of HTTP authentication, AccountManager is an excellent alternative login system. It is trivial to setup and the only reason this ticket is still open is as a reminder that something similar to it is worth looking at later on for core integration (~0.12).

[eblot]

Replying to anonymous:

This ticket has been open for 3 years for goodness sake!

Knowing that this behaviour is due to the nature of HTTP-based authentication, there is little Trac can do if Trac wants to keep using this scheme - but using some clever workarounds as the one that has been suggested lately.

If you want Trac to grow and be adopted by a large number of software projects

Considering the number of sites that use Trac, it seems that this issue is not a blocker one, as you suggested. This does not mean that this issue is not real, though.

After all, issues like this have already been solved by the software packages you are essentially trying to integrate/replace (Mantis, wikis, et. al).

They use another authentication scheme (that bring there own drawbacks) which has already been implemented thanks to the th:wiki:AccountManagerPlugin.

[anonymous]

I came here as I can't implement TRAC to my users with the logout broken. Then I read right at the end to use account manager. Sounds good to me. You have a fix: the account manager plugin, so why not just make that part of TRAC instead of a plugin and close this ancient bug?

[adeason2@…]

Replying to anonymous:

I came here as I can't implement TRAC to my users with the logout broken. Then I read right at the end to use account manager. Sounds good to me. You have a fix: the account manager plugin, so why not just make that part of TRAC instead of a plugin and close this ancient bug?

Some places, believe it or not, rely on HTTP authentication for things like SPNEGO. So, even if some kind of form-based authentication is incorporated into the main tree, someone please leave basic HTTP authentication as an option.

[Pedro Algarvio, aka, s0undt3ch <ufs@…>]

why are all fields changing

[anonymous]

test

[anonymous]

Replying to daniel:

Emailed matt and asked about the patch.

[anonymous]

leave

[ebray]

You leave.

[rblank]

Related to #7371.

[anonymous]

this is sad. trac is an industrial strength application, but you cant logout.

[eblot]

Come on, this is definitely not a blocker issue: there are alternative ways to log out: th:AccountManagerPlugin, using a browser with HTTP session cleanup, or closing your browser. It does not prevent Trac from being used.

[admin@…]

Replying to adeason2@…:

Replying to anonymous:

I came here as I can't implement TRAC to my users with the logout broken. Then I read right at the end to use account manager. Sounds good to me. You have a fix: the account manager plugin, so why not just make that part of TRAC instead of a plugin and close this ancient bug?

Some places, believe it or not, rely on HTTP authentication for things like SPNEGO. So, even if some kind of form-based authentication is incorporated into the main tree, someone please leave basic HTTP authentication as an option.

Ever considered to make the authentication type (web form, http, etc), configurable? A good example would be PHPMyAdmin, which allows users to use the way of authentication they prefer.

Plus, authentication is criticial in most environments, plus .htaccess is the way of making the installation of Trac quick and easy (especially if the user is not using Apache).