Chris Clark wrote:
> On Oct 29, 2:22 am, Christian Hammond <chip...@chipx86.com> wrote:
>> I should point out for anyone else reading the notes that you were able to
>> get away with not needing the old secret key because you're (I'm assuming)
>> using something like LDAP or NIS or Active Directory. In these cases, we
>> don't store an encrypted password in the database, so it should be fine.
>> However, if you have *any* built-in auth accounts (like an initially created
>> admin user), you'll probably want to use your old secret key. Or just use it
>> anyway, it should be safe enough.
> We're currently using built-in auth (we're hoping to move to LDAP/AD
> soon as we already have AD setup for other stuff). Weird... I know!
> Thought it was worth mentioning as it (potentially) saves a step.
> I didn't purge cookies, I did have to login using the regular login
> form so I think the auth really is working (rather than cookie
> caching). I'm guessing the per-password salt is stored in the database
> along with the HMAC rather than using the site setting shared key (but
> this is just a wild guess).
> I should point out that I'm not storing auth for SCM's (all the SCM's
> we use do NOT use auth) which maybe where the shared key may be used.
> If I get burned by this later with other security stuff I'll report
> back :-)
Follow up after a days usage after the upgrade.
Not sure if I've been burned but cookies on client machines expired,
which makes sense (the server did change).
Some of my users had REALLY old postreview clients that had the "looping
when auth fails" bug
<http://code.google.com/p/reviewboard/issues/detail?id=808>, which was
fixed a while back.
Moral of the story, make sure your users upgrade postreview when asked
I did have one review that had a last_updated time in the future (some
time in 2011) which meant that one review was constantly at the top of
the review list with an "Updated 0 minutes ago" note on it. I didn't own
the review so I ended up cheating and updating the record:
$ sudo rb-site manage /var/www/reviewboard shell
from reviewboard.reviews.models import ReviewRequest,
# review to update id is 405
mydate = datetime.datetime(2009, 05, 21, 19, 15, 0) # date it was
x.last_updated = mydate
Using SQL would have worked too.
I've not done any benchmarking but the new release "feels" faster to me
compared with 0.9.
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at