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 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to