SecurityContextEx in 8.0

Hi guys,

in our company we've been using cmd line tool, that automates creation and configuration of builds and vcs-roots by calling several REST API endpoints. Due to the fact, that our TC users are not system administrators (but they still need to authenticate to use the tool), we modified the REST API that wraps the "authorization critical" code like this:

public Project createEmptyProject(final String name, @InjectParam SecurityContextEx securityContext) throws Throwable {
    ...
      final SProject[] projects = {null};
      securityContext.runAsSystem(new SecurityContextEx.RunAsAction() {
          public void run() throws Throwable {
             
projects[0] = myDataProvider.getServer().getProjectManager().createProject(name);
          }
      });

    projects[0].persist();
    return new Project(projects[0], myDataProvider, myApiUrlBuilder);
  }

This kind of a hack worked fine with version 7.0 but doesn't seem to be working with the new TC 8 (we're currently using 8.0.3). Do you have any idea why it stopped working or any hint how to allow non-system users to do this kind sort of operations like creating a project, vcs-root, build etc using modified REST API?
I know that there is a security token generated at a server start-up... could it be somehow used from the REST API internally? Or any other idea?

Thank you in advance for any help!

Jan

4 comments
Comment actions Permalink

Hello,

It's hard to say why it stopped working. Are there any errors?

BTW, TeamCity 8.0 supports mixed mode authentication. if you're using LDAP or NT domain authentication you can also enable built-in authentication and create a special user account there with necessary permisions. Then you can use this account in REST requests.

0
Comment actions Permalink

Hi Pavel,

thanks for your reply. In REST log there is just warning that the request couldn't be processed due to lack of permissions:

[2013-09-03 01:25:39,828]   WARN [nio-8111-exec-1] - est.jersey.ExceptionMapperUtil - Error has occurred during request processing (Forbidden). Error: jetbrains.buildServer.serverSide.auth.AccessDeniedException: You do not have enough permissions to edit build configuration with id: MyProjectQuick_MyBuildQuick. Access denied. Check the user has enough permissions to perform the operation. URL: http://teamcity-upgrade.vm.netsuite.com:8111/ext/rest/projects/MyProject_Quick/buildTypes.

I just sent POST request with build name as a plain text (as documentation says) and wanted it to be created under build types of MyProject_Quick. The user, I used to call this request with, is a normal user and in REST api, I modified it like this:

public BuildType createEmptyBuildType(@PathParam("projectLocator") final String projectLocator, final String name,
                                        @InjectParam SecurityContextEx securityContext) throws Throwable {
    if (StringUtil.isEmpty(name)) {
      throw new BadRequestException("Build type name cannot be empty.");
    }
      final SBuildType[] buildType = {null};
      securityContext.runAsSystem(new SecurityContextEx.RunAsAction() {
          public void run() throws Throwable {
              final SProject project = myProjectFinder.getProject(projectLocator);
              buildType[0] = project.createBuildType(name);
          }
      });
      buildType[0].persist();
    return new BuildType(buildType[0], myDataProvider, myApiUrlBuilder);
  }

Something like this worked with previous version (7.x) of TC without any problem. I'm just wondering... does this system context get propagated to the all sub-calls of getProject and createBuildType name methods? I guess it should...
Strange thing also is that the build type is created after this request but it fails on editing like the error message says. But this request shouldn't edit anything, it should just create an empty build type and that's it.
I don't get it :)

And about the special user for the requests... we could do it like you suggested but then we cannot easily track in history who (what user) actually called these requests.

Thanks in advance for looking into it!

Jan

0
Comment actions Permalink

Please try to enable debug-general logging preset on Administration -> Diagnostics page and reproduce this problem. In this case you'll see complete stacktrace. My current guess is that AccessDeniedException is thrown from .persist method.

0
Comment actions Permalink

Good guess, Pavel ;)
With the debug logging for REST being turned on, I can process further...
Thanks a lot!

Jan

0

Please sign in to leave a comment.