Permission check fails

[anonymous]

Trac sometimes denies views for users with sufficient rights !

Tested with IE8:

1. Open Trac per link, e.g. TRAC_URL/browser or TRAC_URL/newticket
2. Error will be shown, because anonymous has not sufficient rights
3. login with user with sufficient rights
4. Error will still be there and no login name in metanav — this view will be blocked for user (at least as long as the session last, sometimes only deleting Browser-Cache will work)
5. clicking on any other menu works and then user will be displayed in metanav and all menus for the user will be shown (but view TRAC_URL/browser or any other won't work)

[anonymous]

there might be also hints in trac-hack Ticket 8718, see ​https://trac-hacks.org/ticket/8718

[Remy Blank]

This sounds very much like a caching issue. Are you browsing through a proxy? If the user name isn't shown at the top of the page, you received a stale page from a cache. Does a "hard reload" (usually Shift+Reload) on the page displaying the error fix the issue?

[anonymous]

Replying to rblank:

This sounds very much like a caching issue. Are you browsing through a proxy?

I am using Apache2 as web server with AuthType Basic — is Apache2 httpd like a proxy?

If the user name isn't shown at the top of the page, you received a stale page from a cache. Does a "hard reload" (usually Shift+Reload) on the page displaying the error fix the issue?

Shift + Reload don't work, but Ctrl + Reload works in IE8

[Steffen Hoffmann]

Replying to anonymous:

Shift + Reload don't work, but Ctrl + Reload works in IE8

You do confirm, that this can be fixed always this way for you, right? Then it's really not more than a (local browser instance) caching issue. There's not much Trac could do about that, apart from providing the page with (short enough) expiration time on initial page delivery. I don't know enough about this detail.

[anonymous]

Replying to shoffmann:

You do confirm, that this can be fixed always this way for you, right?

Yes, I do confirm that it work with "hard reload" (IE: Ctrl + Reload, FF: Shift + Reload)

Then it's really not more than a (local browser instance) caching issue. There's not much Trac could do about that, apart from providing the page with (short enough) expiration time on initial page delivery. I don't know enough about this detail.

Well it is not a very nice effect for users. At least it should be a hint there that (hard) reloading page might get you the correct page.

A better solution would be that if the error occurs, Trac goes to default page (maybe configurable in trac.ini, otherwise just /wiki). This way it solves at least the case when user switches at a page where the second user isn't allowed. For example: login as admin, calling admin page and the switching to ordinary user (which has no rights for admin page).

For an admin it would be also useful to know, how I could solve this problem by configuring apche2 correctly - is there any documentation in trac?

[Remy Blank]

Replying to anonymous:

A better solution would be that if the error occurs, Trac goes to default page (maybe configurable in trac.ini, otherwise just /wiki). This way it solves at least the case when user switches at a page where the second user isn't allowed.

The point is, this isn't even possible. As your browser caches the page, it only sends a HEAD request, and if it finds that the cached page is still relevant, it won't even fetch the whole page.

For an admin it would be also useful to know, how I could solve this problem by configuring apche2 correctly - is there any documentation in trac?

I don't think you can solve this on the server. For some reason, your browser decides that the cached page is current and doesn't refresh its content. The only way I can imagine this happening is if some headers relevant to caching are stripped from the HTTP request or reply (by a (transparent) proxy, the web server, or maybe even a Trac plugin).

Can you try running your site through tracd on a different port, and see if the issue persists there?

[anonymous]

Replying to rblank:

I don't think you can solve this on the server. For some reason, your browser decides that the cached page is current and doesn't refresh its content. The only way I can imagine this happening is if some headers relevant to caching are stripped from the HTTP request or reply (by a (transparent) proxy, the web server, or maybe even a Trac plugin).

Can you try running your site through tracd on a different port, and see if the issue persists there?

The issue don't appear when using tracd. But it runs on a different server, where no proxy is in between. I asked our admin and he said, we are using squid as a proxy. But as we'll use trac only for internal use, we we'll move the new trac instance into our server environment and there's no proxy. So I'll watch this issue.

[Remy Blank]

Replying to anonymous:

The issue don't appear when using tracd. But it runs on a different server, where no proxy is in between. I asked our admin and he said, we are using squid as a proxy.

Ok, definitely a caching issue at the proxy, then. Nothing we can do in Trac, I'm afraid, except if setting some headers differently would improve the situation (and no, removing caching altogether is not an option).