-
-
-
-
Rather than say to only use it with Perforce, I'd like to see some new logic in templates/admin/scmtools/repository/change_form.html to dynamically show/hide this form, like we do with the hosting settings.
-
I'm not sure I want to add repository-specific fields. What I would like to do, and now is a good time to do it I suppose, is add a "metadata" or "extra_config" (or something) JSONField where we can store additional data like this. That would be more expansive and even allow tools to store additional data per-repository, which could be very useful down the road.
-
-
-
I think we used to have this but that there was some incompatibility with a version of P4API. I'm not sure. I'm going to have to see if David remembers the story here.
-
Enable ticket based authentication for Perforce
Review Request #1445 — Created March 3, 2010 and discarded
Introduced a new repository parameter named ticket_based_auth for use with perforce repositories. When the parameter is set for a perforce repository it will used the ticket based authentication mechanism provided by perforce. This security mechanism is required depending on the security level set for the perforce server. The change also rewrites the PerforceTool get_file method to use the perforce API instead of calling the p4 command line utility.
I setup a local test Reviewboard and tried posting and viewing a review request against both a repository with ticket based authentication and one without.
TR
-
Florian, does this change REQUIRE you use ticket based auth? When I looked at it a few days ago, it kind of seemed that way, but haven't had time to dig in. Right now we simply enter the ticket into our user password. It would seem easier to have something automated, so I am interested in this change.
AR
- Change Summary:
-
As suggested by Christian I added a new "metadata" field to the repository model. The field now stores the "ticket_based_auth" flag for perforce repositories. There's a new attribute for SCMTool classes named "supported_metadata" which will determine which fields will be saved/loaded and displayed out of the metadata field.
- Diff:
-
Revision 2 (+66 -25)
AR
- Change Summary:
-
Removed unnecessary blanks. I also wanted to point out that I did not change rbsite.py and diffviewer.js but merged to the latest trunk before posting the review. I guess post-review diffs against the wrong branch (not master?).
- Diff:
-
Revision 3 (+66 -25)
-
Make sure your branch is merged or rebased onto master. That's likely why the additional changes are on there.
AR
- Change Summary:
-
Got the diff right by using --parent=master. My branch is merged as described in the getting started guide so I still wonder why post-review keeps including all files that have changed during my initial clone of the repository. Will get back to this on the mailing list.
- Diff:
-
Revision 4 (+64 -23)
SE
-
-
I believe it will cause performance issues on the ticked based authentication P4 servers. I tested on my server, it's much slower than before. And I'm also surprised that it's faster after I moved these into self._connect(). In fact, I find out that run_login is just need in get_file() on my server. Please check again.
AR
- Change Summary:
-
Made corrections based on Christians comments.
- Diff:
-
Revision 5 (+68 -23)
AR
- Change Summary:
-
Modified get_file to only use run_print with ticket based authentication. Breakage is now only possible when using the new feature (compromise for 1.5?!). I think having the ticket based mechanism use the command line call as well is both too complicated and insecure (we would have to pipe the password to a "p4 login" command line call).
- Diff:
-
Revision 6 (+101 -21)