What you can do for authentication for the time being is to use just any ol' user that happens to have a valid account and set that in the Repository setting. There's no need for it to be some special account. In practice, any will work, and we used to use David's at VMware for a while.
Don't set a password in there yet. We'll be putting a ticket value there instead. Then, according to the Perforce System Administrator's Guide, do a 'p4 login' as your user, then 'p4 login -p' to get the ticket value. You should be able to paste this value in as the password and it should accept it, meaning no passwords will need to be stored in the database. The downside to a ticket is that it expires by default, but the Perforce admin can set that user's ticket to not expire by putting that user in a group and then, in the group config, setting Timeout: to 0. Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Sun, Sep 21, 2008 at 2:32 PM, Christian Hammond <[EMAIL PROTECTED]>wrote: > I'd have to read up on how p4 tickets work, but it's still not that simple. > Remember that the server needs a way to access the content, and then caches > it so that future lookups are quick. This means that once one person > provides the necessary information to access the file, it'll be available > for all users until it drops out of the cache. > > To make this work, we'd need much finer-grained permission support with a > repository backend. We'd need to be able to query on a per-file basis that a > particular user has access to the server. This means several Perforce server > calls on every page access, which will slow things down a little bit, > especially for large diffs, and negate many of the speed and server-load > benefits of our caching. We'd also need a good way of associating Perforce > users with local users, which we don't have yet. > > Another option is to have the permissions control stay local to Review > Board. Users would be unable to access anything not approved by the Review > Board administrator. It would stay relatively fast without the complexity of > having to link accounts (something which would take additional per-user > configuration and introduce codebase changes I'm not too excited about), and > would stay more general across other revision control systems. > > This is work we'd need someone to champion, and probably wouldn't start > until after the 1.0 release unless someone gets it done fast. > > Christian > > -- > Christian Hammond - [EMAIL PROTECTED] > VMware, Inc. > > > > On Sun, Sep 21, 2008 at 12:43 PM, Daniel Wexler <[EMAIL PROTECTED]>wrote: > >> >> Can we use p4 tickets somehow to solve this problem? >> >> Would it be possible for each user to log in once per "session" using >> a password that isn't saved anywhere, and retain permissions for that >> user with a ticket? >> >> Obviously we shouldn't store passwords in cleartext or with bad >> encryption. But I wouldn't mind entering a password once a day (or a >> couple times) manually to get things started. Would requiring the >> password on each session should also get us around the password change >> issue? >> >> I'm pretty sure my IT dept won't allow us to store a password for the >> respository in our config files. Our IT department will not provide a >> special account for the server. Even read-only access is not secure >> enough. We need to prevent employees without access from *reading* >> files within parts of the repository for which they don't personally >> have access. The danger for us is the release of the IP, not the >> ability to modify the code. For us, and I'm sure many others, solving >> this issue will be essential to our use of reviewboard. >> >> On Sep 19, 8:37 pm, "Christian Hammond" <[EMAIL PROTECTED]> wrote: >> > 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 >> > much better. >> > >> > 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 >> > >> > -- >> > Christian Hammond - [EMAIL PROTECTED] >> > VMware, Inc. >> > >> > 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 >> > > reviewboard >> > > > > instances, with different user credentials in each (one for each >> > > project >> > > > > 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: >> > >http://pages.teamintraining.org/dm/tucson08/jandros >> > >> > > > > On Fri, Sep 19, 2008 at 4:30 PM, Daniel Wexler < >> [EMAIL PROTECTED]> >> > > wrote: >> > >> > > > > > I see an older discussion about the issue of Perforce security >> and >> > > the >> > > > > > need to put the P4 user and client information into the server: >> > >> > >http://groups.google.com/group/reviewboard/browse_thread/thread/d057c. >> .. >> > >> > > > > > 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. >> > > There >> > > > > > 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 "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
