Edgewall Software
Modify

Opened 4 years ago

Closed 3 years ago

#10148 closed defect (cantfix)

Permission check fails

Reported by: anonymous Owned by:
Priority: high Milestone:
Component: general Version: 0.12.2
Severity: critical Keywords: permission needinfo
Cc: shoffmann
Release Notes:
API Changes:

Description

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)

Attachments (0)

Change History (8)

comment:1 Changed 4 years ago by anonymous

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

comment:2 follow-up: Changed 4 years ago by rblank

  • Keywords needinfo added
  • Milestone 0.12.3 deleted

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?

comment:3 in reply to: ↑ 2 ; follow-up: Changed 4 years ago by 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

comment:4 in reply to: ↑ 3 ; follow-up: Changed 4 years ago by shoffmann

  • Cc shoffmann added

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.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 3 years ago by 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?

comment:6 in reply to: ↑ 5 ; follow-up: Changed 3 years ago by rblank

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?

comment:7 in reply to: ↑ 6 ; follow-up: Changed 3 years ago by 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.

comment:8 in reply to: ↑ 7 Changed 3 years ago by rblank

  • Resolution set to cantfix
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.
Author


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

 
Note: See TracTickets for help on using tickets.