ASP.NET Permissions and the Vault Client API

[kellyb]

SourceGear folks,
I developed a pretty handy build mechanism for applying a label to our Vault source, fetching label diff's from the previous build, and then fetching by label and proceeding with our build process. I created this functionality using the Vault Client API in a simple ASP.NET web application.

When developing this app on my local Windows XP machine - all is well. When deploying the app to our build server running Windows Server 2003(also the Vault server), the app blows when it tries to connect to Vault via a ClientInstance. I know for a fact I have the ASPNET user account setup with much higher permissions than W2K3 out of the box.

Because this operation is initiated by the ASPNET worker process I know there's some uniqueness about the security needs. I was hoping you can tell me what system resources ASPNET account needs for interacting with the Vault Client API programmatically via a Web App. Of course, I'm interested in the lowest level of permissions I can get away with for this operations (I have security folks to answer to!).

I'm currently getting the following error:

--------------------------------------------------------------------

Access to the path "SourceGear\Vault_1\Client\C98947FB-9F74-4655-BF1D-059D764BE68F\buildmaster" is denied.

Line 50: //This will load up the client side cache files and refresh the repository structure.
Line 51: //See http://support.sourcegear.com/viewtopic.php?t=6 for more on client side cache files.
Line 52: base.SetActiveRepositoryID( repository.RepID, base.Connection.Username, repository.UniqueRepID, true, true );
Line 53: found = true;
Line 54: break;
--------------------------------------------------------------------

Thanks in advance

-kelly

[jeremy_sg]

Most likely, you only need to make sure that the c:\Documents and Settings\MACHINENAME\ASPNET\Application Data directory exists and that the ASPNET process has full control over it.

[kellyb]

it wasn't there, but I created it and granted full control, but the problem remains.

Can you give me some backgroup on this? I'm a little confused what function that folder serve. Is that server side cache? What does it mean that they weren't present?

I created this web app using the Vault Client API on my developer machine that was invoking the Vault Server and everything worked fine. Now I deployed the web app to the Vault Server itself - just a coincidence that this web app is hosted on the same phyiscal box as our our source control server. There is nothing noticably wrong with Vault - everyone on our team is accessing it remotely with the Vault Client GUI. Furthermore, as I stated, this web app was accessing the Vault server via the API with no problems from my machine. Why would it fail when running on the same physically box?

To me this sounds like the Vault Client API itself is trying to create a cache of some kind and ASPNET on the server doesn't have sufficient permissions. A permission issue anywhere else would mean other things would be broken.

Any info would be appreciated.

-kelly

[davidcstuart]

I fairly sure that the user on 2003 is "NETWORK SERVICE" not "ASPNET" like on XP. If you look at the properties on the Application Pool asp.net is using (Probably "DefaultAppPool"), there is an "Identity" tab that will tell you what user the asp.net worker process is using.

[jeremy_sg]

Every Vault client (API included) tries to put cache files in the Documents and Settings/USER/Application Data/Sourcegear directory. You can read about the cache files at: http://support.sourcegear.com/viewtopic.php?t=6

The account that your Asp.Net app is impersonating must be able to create the client side cache. davidcstuart is right in his recommendation for setting the identity to use, but I would recommend that you make sure that you don't change anything on the application pool that the Vault service is using. Create a new application pool for your app, if needed.