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

Reply via email to