This is how I have mine setup. I use my account in reviewboard and every time my ticket expires I use p4 login -a -p. I have found that I need the -a to allow my ticket to work from any computer.
Sent from my iPhone On Sep 21, 2008, at 5:54 PM, "Christian Hammond" <[EMAIL PROTECTED]> wrote: > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
