If you can get your ticket expiration for your user set to 0, you shouldn't have to p4 login -a -p anymore. If not, you could probably automate this with a cronjob. Login, get the new ticket, stuff it in the database.
Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Sun, Sep 21, 2008 at 3:16 PM, Joshua Slominski <[EMAIL PROTECTED]>wrote: > 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]>[EMAIL PROTECTED] > VMware, Inc. > > > On Sun, Sep 21, 2008 at 2:32 PM, Christian Hammond < <[EMAIL PROTECTED]> > [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]>[EMAIL PROTECTED] >> VMware, Inc. >> >> >> >> On Sun, Sep 21, 2008 at 12:43 PM, Daniel Wexler < <[EMAIL PROTECTED]> >> [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> >>> 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> >>> 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.> >>> 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 -~----------~----~----~----~------~----~------~--~---
