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 Borgström]

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

[daniel]

Emailed matt and asked about the patch.

[Matthew Good <matt-good.net>]

partial implementation

[Christopher Lenz]

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.

[Christopher Lenz]

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 Borgström]

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

[Matthew Good]

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?

[Matthew Good]

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

[Matthew Good]

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

[Christopher Lenz]

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

[Emmanuel Blot]

#2228 has been marked as a duplicate of this ticket

[Emmanuel Blot]

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

[Emmanuel Blot]

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.

[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?

[Christian Boos]

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

[Noah Kantrowitz]

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

[Emmanuel Blot]

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.

[Remy Blank]

Related to #7371.

[anonymous]

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

[Emmanuel Blot]

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

[Remy Blank]

Please stop that.

[anonymous]

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

[John Hampton]

I have started a branch browser:sandbox/accountmanager where I am merging the essential parts of account manager into core. It should currently be functional, but needs a bunch of cleanup. I'll be getting to that shortly.

[nn@…]

I found this ticket looking for the way to disable logout link in TRAC. Although accountmanager looks promising I would like to solve this issue quickly without changing the way my TRAC installation works. My TRAC uses basic HTTP authentication and for me it is good enough. I'd like to just disable the logout link with all the consequences.
Could somebody please tell us how to disable the logout link? I tried to do it myself studying trac's code but failed.

[postb99@…]

I'm using Trac 0.11.4 and found this relevant ticket. In my setup I have AccountManagerPlugin that hides this behavior, but when I added XmlRpcPlugin and HttpAuthPlugin to integrate with third-party tool (Testlink, since I'm trying to integrate professional-looking tools) it came back.

I see some people lately worked on this. Hoping it will be effective soon in an official release, since it seems to be all but trivial to implement. Good luck in coding :)

[Sebastian Heuchler <sheuchler@…>]

I'm a bit disappointed - this is a very serious issue which ought to be fixed asap. Or did Trac stop to try to achieve industrial strength?

[anonymous]

See comment 54 for a javascript solution which works with major browsers (IE, Firefox, …).

[anonymous]

Issue #3577 was closed as a duplicate of this one 3 years ago. Yet this bug doesn't go anywhere because there's a solution proposed elsewhere (which so happens to be on the closed-duplicate bug). Any news on integrating the JavaScript solution??

Please don't remove HTTP auth from the possibilities!! This is critical for many people, not least of which for privacy and security reasons (why advertise the existence of a Trac installation to unwanted people when you can simply present an HTTP auth dialog).

[anonymous]

Is this bug's existence set to implement cookie support instead of http/cache support, so users can have real user names, passwords, e-mail addresses, etc. connected through Trac, with a user admin interface?

[anonymous]

Trac is a very good software. but this is a small feature (bug) which needed for some people. can you consider it?

[Bruno Matos <bruno.matos@…>]

Any advances on this?

Thank you, Bruno Matos

[RektideDeLaFey]

this issue is really easy to workaround in most sane UA's:

1. "logout"
2. manually navigate to ​http://FooBarIsMyName@trac.yoyodyne.net
3. ???
4. profit

[Christian Boos]

Replying to RektideDeLaFey:

this issue is really easy to workaround in most sane UA's:

1. "logout"
2. manually navigate to ​http://FooBarIsMyName@trac.yoyodyne.net
3. ???
4. profit

Nice try ;-)

With a manual step, this can't be considered to be a valid solution, though. I experimented with this idea (using [metanav] logout.redirect) and it works great with Chrome (7.0.517), but unfortunately not with any other browsers I've tried:

• Firefox (3.6.10) warns you about a possible security risk, but at least the trick will work if you manually confirm
• Opera (10.63) and Safari (5.0.2) simply don't care (i.e. the trick doesn't work)
• IE9b1 apparently has issues with such redirects and otherwise doesn't care

I suppose it is only a matter of time until Chrome considers this is a security issue and starts throwing confirmation dialogs at your face like the others.

[Remy Blank]

This is a manual implementation of what #3577 suggests, which is implemented in the ​th:TrueHttpLogoutPatch using a XMLHttpRequest. I thought PHPMyAdmin was using that trick, but looking at it again, it doesn't seem so, and their "logout" button is a simple link. I wonder if it would be possible to send bogus authentication headers when accessing /logout (and a 401), so that the browser opens a new authentication dialog and hopefully removes the previously cached information.

[Remy Blank]

Replying to rblank:

I wonder if it would be possible to send bogus authentication headers when accessing /logout (and a 401), so that the browser opens a new authentication dialog and hopefully removes the previously cached information.

That does indeed work with Firefox 3.6, but Chrome and Opera keep the credentials. Back to square one…

[anonymous]

The ​TrueHttpLogoutPatch seems to work well enough for me and is easy to implement. The only issue with it is that it brings up the auth login immediately as opposed to say redirecting to another url.

The issue with the ​AccountManagerPlugin was that it doesn't seem to protect the Available Projects page as you could with Basic Auth. For a Trac site that is external and private you may not wish to give out that information.

We've just started using Trac and it seems to do what we need. I had to spend a little more time dealing with the broken logout feature (which does seem to concern a number of people) than I would have liked and it would be nice to have been able to find a usable workaround more directly.

[williams.jackj@…]

Ugh, TrueHttpLogoutPatch does not work for me, when I click logout it still says logged in. Did I miss something?

[willy@…]

I am hitting this same problem too….

Hey, i need a fix for this! Or remove the logout button altoghether, because its USELESS and confusing!!

[anonyme]

TrueHttpLogoutPatch doesn't look to work anymore starting with Firefox 4. Does anyone have an idea about what to change in order to adapt that hack for Firefox ≥ 4 ?

[Ryan J Ollos <ryano@…>]

Replying to anonyme:

​th:TrueHttpLogoutPatch doesn't look to work anymore starting with Firefox 4. Does anyone have an idea about what to change in order to adapt that hack for Firefox ≥ 4 ?

This question is more appropriate for the MailingList.

[Remy Blank]

To anyone considering posting a "me too" comment on this ticket, don't, just don't. The current status is the following:

• This is an issue with the HTTP authentication scheme itself, and there's nothing we can do in Trac to fix it properly.
• There is currently no workaround (JavaScript or other) that works with all major browsers.
• If that bothers you, use ​th:AccountManagerPlugin.

Only post a new comment if you can provide a complete, tested workaround that works on all major browsers (Firefox, Opera, IE, Chrome, Safari). Comments that don't bring any new information will be deleted.

[version2@…]

+1

[anonymous]

Replying to RektideDeLaFey:

this issue is really easy to workaround in most sane UA's:

1. "logout"
2. manually navigate to ​http://FooBarIsMyName@trac.yoyodyne.net
3. ???
4. profit

Thank you!!! this workaround is all I need.

[Christian Boos]

Nothing new since comment:92, as that trick:

• still works great with Chrome (now 26.0.1410.33 etc.)
• still produces an annoying security warning with FF (19.0.2)
• Opera still doesn't care (12.14)
• and well, IE10 doesn't seem to understand the ​http://user@host/ syntax…

Ah yes, something new: Safari (5.1.7) now cares and produces a security warning even more scary than FF does… and if you go through ("Ignore warning"), well the trick doesn't work and you're logged in again under the original account ;-)

[Christian d'Heureuse <chdh@…>]

A good workaround for protecting a whole Trac site from anonymous users is to use the ​LoginModule of ​Account Manager and the ​PermRedirectPlugin.
(And remove all permissions from the anonymous group).