Какая область позволяет расширению TFS управлять списками ACL?

TFS 2015 u2. Попытка написать расширение TFS, которое будет использовать JavaScript API для управления безопасностью в определении выпуска. API, связанные с безопасностью, перестали работать с ошибкой 401. Код выглядит так:

VSS.require(["VSS/Service", "VSS/Security/RestClient"],
        function (Srv, SecAPI)
        {
            var SecClient = Srv.getCollectionClient(SecAPI.SecurityHttpClient);
            SecClient.queryAccessControlLists("aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee").then(function(a)
            {
                //...
            });
        }

Это ошибки с 401 Несанкционированный. Насколько я понимаю, список REST API, который может использовать расширение, определяется scopes параметр в манифесте. Что я размещаю там, чтобы это работало? В списке областей нет ничего подобного.

Между тем, вызов той же конечной точки из обычного клиента REST с аутентификацией Windows работает, как и ожидалось.

2 ответа

Решение

Наконец, в TFS 2017 u2 есть vso.security_manage.


В TFS 2017 u1 есть простор vso.base которая охватывает эту конечную точку API, но только с помощью GET. POST, который требуется для изменения дескриптора, все еще не охватывается областью действия.

В TFS 2015 u2 и, вероятно, ниже, нет области действия, которая покрывает связанные конечные точки ACL.


Я нашел очень хакерский способ включить эти конечные точки для OAuth в старых версиях TFS. Это применимо только к локальной TFS. Взаимосвязь между областями OAuth и URL-адресами / методами конечных точек службы хранится в глобальной общедоступной изменяемой одноэлементной структуре данных, которую часть пользовательского кода может просто изменить. Вы можете увидеть его в своем любимом дизассемблере MSIL (ILDASM, ILSpy, Reflector), если вы будете использовать метод CreateDefault в классе Microsoft.VisualStudio.Services.DelegatedAuthorization.AuthorizationScopeDefinitions в Microsoft.TeamFoundation.Framework.Server.dll,

Следующий Global.asax делает свое дело. Вы должны скопировать его в C:\Program Files\Microsoft Team Foundation Server 14.0\Application Tier\Web Services (для TFS 2015).

<%@ Application Inherits="Microsoft.TeamFoundation.Server.Core.TeamFoundationApplication" %>
<%@ Import namespace="Microsoft.VisualStudio.Services.DelegatedAuthorization" %>
<%@ Import namespace="System.Collections.Generic" %>
<%@ Import namespace="System.Linq" %>
<script runat="server">
void Session_Start(object o, EventArgs a)
{
    AuthorizationScopeDefinition Def = AuthorizationScopeDefinitions.Default.scopes
        .FirstOrDefault(d => d.scope == "vso.identity");
    if(Array.IndexOf(Def.patterns, "/_apis/SecurityNamespaces#GET") < 0)
    {
        List<string> l = Def.patterns.ToList();
        l.Add("/_apis/SecurityNamespaces#GET");
        l.Add("/_apis/AccessControlLists#GET+POST");
        l.Add("/DefaultCollection/_apis/SecurityNamespaces#GET");
        l.Add("/DefaultCollection/_apis/AccessControlLists#GET+POST");
        Def.patterns = l.ToArray();
    }
}
</script>

Подключение Application_Start могло бы иметь больше смысла, но DLL с выделенным кодом уже перехватывает его. Другой обработчик в Global.asax не переопределяет. Я обезьяна-патч vso.identity область, потому что мое расширение уже заявляет, что, но не стесняйтесь использовать любой другой.

Представляя свой собственный, совершенно новый охват, вероятно, не сработает.

К сожалению, нет REST API для изменения разрешения определения выпуска или среды выпуска.

Есть голос пользователя, который вы можете проголосовать. REST API для определения релиза или релиза TFS PM любезно рассмотрит ваше предложение.

Другие вопросы по тегам