Hi Christian, I filed bug http://code.google.com/p/reviewboard/issues/detail?id=2538about this issue, and put a patch into the comment.
I validated my change by turning on logging, adding a line to show the key being generated, and then running reviewboard. That confirmed that my fix added the SITE_ROOT into the key. Please let me know if you need anything more to apply this. Thanks for the pointers that got me looking in the right place. -Eric. On Fri, Mar 16, 2012 at 9:13 AM, Christian Hammond <chip...@chipx86.com>wrote: > Hi Eric, > > Ah, yes, in this case you may be stuck. We use the actual domain name > specified for the site, which in your case is being duplicated, hence the > leakage. > > This code lives in Djblets's djblets/util/misc.py. Look at make_cache_key. > > One thing that could be done is to have that function check if settings > has the SITE_ROOT attribute set, and if so, include that as part of the key > prefix. If you'd like to try modifying your copy of djblets to do this and > test it, we can get that in for a release. > > > Christian > > -- > Christian Hammond - chip...@chipx86.com > Review Board - http://www.reviewboard.org > VMware, Inc. - http://www.vmware.com > > > On Fri, Mar 16, 2012 at 1:05 AM, Eric Johnson < > ericjohn...@alumni.brown.edu> wrote: > >> Hi Christian, >> >> Thanks for the quick response. I should have added crucial details - I'm >> hosting all these reviewboard instances with the same DNS name, but just a >> different path, as in: >> >> http://myhost.example.com/rbinstance1/ >> http://myhost.example.com/rbinstance2/ >> >> (the above being examples, of course, not my actual host or path). When >> you say "the server's configured domain", exactly where is this >> configuration, so that I can verify that it is distinct amongst these >> ReviewBoard instances? >> >> I asked the question because I've seen cache leakage - someone using >> "rbinstance2" sees a diff applied to source code from "rbinstance1". >> Restarting memcached fixed the problem, at least temporarily, so it is >> definitely something related to cache, rather than my configuration. I've >> seen this problem once before, but that was perhaps a year ago, and using >> 1.5.0, not 1.5.7, and several updates to memcached ago. Of course, now I'm >> using 1.5.7, with the latest stable version of memcached on Gentoo, so >> something else is going on. >> >> As for the features of 1.6.x, I'm aware of the changes. Unfortunately, we >> deployed before they were available, and needed isolation between >> instances. Without a way to merge instances, we're unlikely to switch to >> use ReviewBoard's built-in approach for security. >> >> -Eric. >> >> >> On Thu, Mar 15, 2012 at 11:23 PM, Christian Hammond >> <chip...@chipx86.com>wrote: >> >>> One is fine. The keys will be prefixed with the server's configured >>> domain in order to prevent conflicts. >>> >>> You'll just want to bump up the memory allocation for memcached as high >>> as you can go. A good rule in general, but even more important when you >>> have many instances using it. >>> >>> I should point out though that in 1.6.x, Review Board can keep review >>> requests and code restricted to certain groups/users. So there's less need >>> to run multiple servers. >>> >>> Christian >>> >>> -- >>> Christian Hammond - chip...@chipx86.com >>> Review Board - http://www.reviewboard.org >>> VMware, Inc. - http://www.vmware.com >>> >>> >>> On Thu, Mar 15, 2012 at 2:54 PM, Eric Johnson < >>> ericjohn...@alumni.brown.edu> wrote: >>> >>>> I've got multiple instances of reviewboard (version 1.5.7) running on >>>> the same server (so that I can sandbox the users so that there's no risk of >>>> them seeing code from other code repositories that they don't have access >>>> to. >>>> >>>> I'm only using one instance of memcached, though. Do I need a separate >>>> instance of memcached for each instance of reviewboard? >>>> >>>> >>>> -Eric. >>>> >>>> -- >>>> Want to help the Review Board project? Donate today at >>>> http://www.reviewboard.org/donate/ >>>> Happy user? Let us know at http://www.reviewboard.org/users/ >>>> -~----------~----~----~----~------~----~------~--~--- >>>> To unsubscribe from this group, send email to >>>> reviewboard+unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/reviewboard?hl=en >>> >>> >>> -- >>> Want to help the Review Board project? Donate today at >>> http://www.reviewboard.org/donate/ >>> Happy user? Let us know at http://www.reviewboard.org/users/ >>> -~----------~----~----~----~------~----~------~--~--- >>> To unsubscribe from this group, send email to >>> reviewboard+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/reviewboard?hl=en >> >> >> -- >> Want to help the Review Board project? Donate today at >> http://www.reviewboard.org/donate/ >> Happy user? Let us know at http://www.reviewboard.org/users/ >> -~----------~----~----~----~------~----~------~--~--- >> To unsubscribe from this group, send email to >> reviewboard+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/reviewboard?hl=en >> > > -- > Want to help the Review Board project? Donate today at > http://www.reviewboard.org/donate/ > Happy user? Let us know at http://www.reviewboard.org/users/ > -~----------~----~----~----~------~----~------~--~--- > To unsubscribe from this group, send email to > reviewboard+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/reviewboard?hl=en > -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~----------~----~----~----~------~----~------~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en