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