Opened 20 years ago
Last modified 2 years ago
#791 new enhancement
login/logout, authentication, and authorization
Reported by: | Matthew Good <matt-good.net> | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | next-major-releases |
Component: | general | Version: | devel |
Severity: | normal | Keywords: | login logout permission authentication authorization |
Cc: | shishz@…, jouvin@…, coderanger@…, r.sokoll@…, ufs@…, admin@…, bruno.matos@…, christer@…, sbranden@…, tonibony@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
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.
Attachments (5)
Change History (112)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
Priority: | normal → highest |
---|---|
Severity: | normal → critical |
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)
comment:3 by , 20 years ago
Summary: | [merge] login/logout and forced authentication → login/logout and forced authentication |
---|
Removing "[merge]"-prefix because no patch is attached…
comment:5 by , 20 years ago
Severity: | critical → blocker |
---|
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.
comment:6 by , 20 years ago
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;
comment:7 by , 20 years ago
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.
comment:8 by , 20 years ago
Status: | new → assigned |
---|
comment:9 by , 20 years ago
Milestone: | 0.8 → 0.9 |
---|---|
Priority: | highest → normal |
Severity: | blocker → normal |
[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…
comment:10 by , 20 years ago
+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.
comment:11 by , 20 years ago
Could we get an updated patch for 0.8.1? The logout bug is really a showstopper for a lot of people.
comment:12 by , 19 years ago
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!
comment:13 by , 19 years ago
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
comment:14 by , 19 years ago
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.
comment:15 by , 19 years ago
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.
comment:16 by , 19 years ago
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)
comment:17 by , 19 years ago
Keywords: | login logout security authentication added |
---|---|
Priority: | normal → high |
Severity: | normal → major |
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?
comment:18 by , 19 years ago
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.
comment:19 by , 19 years ago
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).
comment:20 by , 19 years ago
I'm voting +1 for the idea of the previous commenter, since this will possibly lead to better compatibility with IIS (see #1522) :-p
comment:21 by , 19 years ago
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
comment:22 by , 19 years ago
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.
comment:23 by , 19 years ago
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
comment:24 by , 19 years ago
Keywords: | authorization added |
---|---|
Summary: | login/logout and forced authentication → login/logout, authentication, and authorization |
+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.
comment:25 by , 19 years ago
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.
comment:26 by , 19 years ago
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. ;-)
comment:27 by , 19 years ago
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
comment:28 by , 19 years ago
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
comment:29 by , 19 years ago
Cc: | added |
---|
comment:30 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Type: | defect → enhancement |
comment:31 by , 19 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:32 by , 19 years ago
Milestone: | 0.9 → 1.0 |
---|
Nice discussion, but I really don't see this happening for 0.9.
comment:35 by , 19 years ago
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.
comment:36 by , 19 years ago
Cc: | added |
---|
comment:37 by , 19 years ago
Priority: | high → highest |
---|
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.
comment:38 by , 19 years ago
Cc: | added |
---|
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 ?
comment:39 by , 19 years ago
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.)
by , 19 years ago
Attachment: | auth_form.diff added |
---|
A patch for login using a form, instead of direct HTTP auth
by , 19 years ago
Attachment: | auth_form2.diff added |
---|
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.
comment:40 by , 19 years ago
Cc: | added |
---|
comment:41 by , 19 years ago
Component: | general → timeline |
---|
comment:42 by , 19 years ago
Component: | timeline → general |
---|
There is no justification for changing the component. The login/logout issue is not specifically related to the timeline.
comment:43 by , 19 years ago
Milestone: | 1.0 → 0.12 |
---|
comment:44 by , 19 years ago
Cc: | added |
---|
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.
comment:45 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:46 by , 19 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:48 by , 18 years ago
Cc: | removed |
---|
comment:49 by , 18 years ago
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?
comment:50 by , 18 years ago
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.
comment:51 by , 18 years ago
Keywords: | permission added; security removed |
---|
comment:52 by , 18 years ago
Cc: | added |
---|
comment:53 by , 18 years ago
Type: | enhancement → defect |
---|
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?
comment:54 by , 18 years ago
#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.
follow-up: 57 comment:55 by , 17 years ago
Severity: | major → blocker |
---|
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).
comment:56 by , 17 years ago
Severity: | blocker → major |
---|
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).
comment:57 by , 17 years ago
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.
comment:58 by , 17 years ago
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?
follow-up: 76 comment:59 by , 17 years ago
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.
comment:60 by , 17 years ago
Cc: | removed |
---|
comment:62 by , 16 years ago
Cc: | added |
---|---|
Component: | general → i18n |
Severity: | major → critical |
Version: | devel → 0.8.4 |
comment:63 by , 16 years ago
Component: | i18n → general |
---|---|
Severity: | critical → major |
Type: | defect → enhancement |
why are all fields changing
comment:66 by , 16 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
comment:70 by , 16 years ago
Severity: | major → blocker |
---|
this is sad. trac is an industrial strength application, but you cant logout.
comment:71 by , 16 years ago
Severity: | blocker → major |
---|
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.
comment:72 by , 16 years ago
Version: | 0.8.4 → 0.7.1 |
---|
comment:73 by , 16 years ago
Version: | 0.7.1 → devel |
---|
comment:74 by , 16 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
comment:75 by , 16 years ago
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
comment:76 by , 16 years ago
Cc: | added |
---|
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).
comment:77 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:78 by , 16 years ago
Owner: | changed from | to
---|
comment:79 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:81 by , 16 years ago
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.
comment:82 by , 16 years ago
Owner: | changed from | to
---|---|
Priority: | highest → normal |
Severity: | major → normal |
Status: | reopened → new |
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.
comment:83 by , 15 years ago
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.
comment:84 by , 15 years ago
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 :)
comment:85 by , 15 years ago
Cc: | added |
---|
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?
comment:86 by , 15 years ago
See comment 54 for a javascript solution which works with major browsers (IE, Firefox, …).
comment:87 by , 15 years ago
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).
comment:88 by , 14 years ago
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?
comment:89 by , 14 years ago
Trac is a very good software. but this is a small feature (bug) which needed for some people. can you consider it?
follow-ups: 92 105 comment:91 by , 14 years ago
this issue is really easy to workaround in most sane UA's:
- "logout"
- manually navigate to http://FooBarIsMyName@trac.yoyodyne.net
- ???
- profit
comment:92 by , 14 years ago
Replying to RektideDeLaFey:
this issue is really easy to workaround in most sane UA's:
- "logout"
- manually navigate to http://FooBarIsMyName@trac.yoyodyne.net
- ???
- 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.
follow-up: 94 comment:93 by , 14 years ago
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.
comment:94 by , 14 years ago
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…
comment:95 by , 14 years ago
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.
comment:96 by , 14 years ago
Cc: | added |
---|
comment:97 by , 14 years ago
Cc: | added |
---|
comment:98 by , 14 years ago
Cc: | removed |
---|
comment:99 by , 14 years ago
Ugh, TrueHttpLogoutPatch does not work for me, when I click logout it still says logged in. Did I miss something?
comment:100 by , 14 years ago
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!!
follow-up: 102 comment:101 by , 13 years ago
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 ?
comment:102 by , 13 years ago
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.
comment:103 by , 13 years ago
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.
follow-up: 106 comment:105 by , 12 years ago
Replying to RektideDeLaFey:
this issue is really easy to workaround in most sane UA's:
- "logout"
- manually navigate to http://FooBarIsMyName@trac.yoyodyne.net
- ???
- profit
Thank you!!! this workaround is all I need.
comment:106 by , 12 years ago
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 ;-)
comment:107 by , 10 years ago
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).
comment:108 by , 9 years ago
Owner: | removed |
---|
comment:109 by , 7 years ago
Cc: | added |
---|
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.