This isn't a very usable solution, for a few reasons.
First, we can't use the user's Review Board username/pass, because this
won't always correspond to the account on the Perforce server. Also,
passwords are one-way encrypted so that they can't easily be decrypted if
the database is accessed by a malicious user.
Given that, we'd have to specify the user/pass to use on every operation.
Since Review Board pulls files from the Perforce server when generating a
diff, which may happen at any time, we'd have to store the user/pass in
plaintext in the database, which is horribly insecure. IT admins generally
wouldn't be okay with this, and it would just be irresponsible for us to
implement. We could do a sort of two-way encryption but this isn't really
Yes, we are storing the repository account's password in plaintext, but the
general advice is to have a read-only user account or something so that if
someone has the password, they can't do anything too dangerous. It's also
far better than to have every single user's password available in plaintext.
Also, if a user changes his username/password at a later time on the
Perforce server, or the user is removed from the Perforce server, all
associated review requests would become inaccessible. So storing user
account info for accessing the server has a lot of downsides.
Christian Hammond - [EMAIL PROTECTED]
On Fri, Sep 19, 2008 at 5:16 PM, Daniel Wexler <[EMAIL PROTECTED]> wrote:
> So, I think we already are using the official Perforce Python module.
> That's good (it makes my IT guys happy).
> Why do we use the client and repository setting for the Repository
> instead of using a client/pass from the user?
> I think my IT guys would be happy if we used the user's client/pass
> information when the server accesses the repository instead of a
> single, global user/pass.
> Just poking around the code, how would I get the reviewboard user/pass
> inside scmtools/perforce.py:19? If I had folks set up their
> reviewboard account using their same user/pass as they have with
> Perforce, would it all Just Work (tm)?
> On Sep 19, 5:00 pm, Daniel Wexler <[EMAIL PROTECTED]> wrote:
> > Has anyone explored the new Python bindings for Perforce?
> > http://www.perforce.com/perforce/doc.081/manuals/p4script/p4script.pdf
> > They seem to have functions for logging in to the server with a
> > specific user name and password from Python. Could we use this and
> > have the user's provide the Perforce user/pass as part of their client
> > info?
> > On Sep 19, 4:43 pm, "Jeff Andros" <[EMAIL PROTECTED]> wrote:
> > > it's not a pretty solution, but what about setting up multiple
> > > instances, with different user credentials in each (one for each
> > > you've got) then you only create accounts on the servers that theyr'e
> > > supposed to have access to.
> > > Jeff
> > > O|||||||O
> > > Help me and the Leukemia and Lymphoma society fight blood cancers:
> > > On Fri, Sep 19, 2008 at 4:30 PM, Daniel Wexler <[EMAIL PROTECTED]>
> > > > I see an older discussion about the issue of Perforce security and
> > > > need to put the P4 user and client information into the server:
> > > >
> > > > Any update on this situation?
> > > > My company is similarly concerned about this security issue and would
> > > > like a way of passing through the user's perforce credentials. Is
> > > > anyone actively working on this issue?
> > > > We have a large company and have many internal security groups.
> > > > have been issues in the past with "server" accounts that make the IT
> > > > department hesitant to set up a special Perforce account for the
> > > > server.
> > > > Can someone explain why the server needs Perforce access in the first
> > > > place? Why not just upload the required information as part of the
> > > > user-side post-review script?
> > > > BTW, I did install Windows NTLM authentication on my server using
> > > > mod_auth_sspi with no issues so far, which provides a modicum of
> > > > security.
You received this message because you are subscribed to the Google Groups
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at