UnauthorizedAccessException in ASP.NET app using SDK

[dprothero]

Please see this thread for background:

http://support.sourcegear.com/viewtopic ... 30&t=11195

We ended up implementing the semaphore idea and all of these errors went away. It solved the problem beautifully.

However, we recently upgraded to VaultPro, server is running version 5.1.1.19216. Now, the errors have returned. Even though we've got a semaphore system in place we're still getting them. Has something changed?

Error:
Exception:
System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.UnauthorizedAccessException: Access to the path 'Vault_CacheMember_CommitDialogBugInfo_-1489968562' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.Threading.Mutex.<>c__DisplayClass3.<.ctor>b__0(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name, Boolean& createdNew, MutexSecurity mutexSecurity)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at VaultLib.SystemMutex..ctor(String name)
at VaultClientOperationsLib.CacheMember..ctor(String folder)
at VaultClientOperationsLib.CacheMember_CommitDialogBugInfo..ctor(String folder)
at VaultClientOperationsLib.TreeCache.Load()
at VaultClientOperationsLib.TreeCache..ctor(Int32 repID, String username, String uniqueRepositoryID, String localStoreBasePath, ClientInstance ci)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Int32 id, String username, String uniqueRepositoryID, Boolean doRefresh, Boolean updateKnownChangesAll)
at TRC.Vault.Utilities.Login()
at TRC.Vault.File.ConfirmLogin()
at TRC.Vault.File.setStatus()
at TRC.Vault.File.RefreshStatus()
at WebRoot.IntraNet_DetailDoc.grdSegmented_ItemDataBound(Object sender, DataGridItemEventArgs e)
at System.Web.UI.WebControls.DataGrid.OnItemDataBound(DataGridItemEventArgs e)
at System.Web.UI.WebControls.DataGrid.CreateItem(Int32 itemIndex, Int32 dataSourceIndex, ListItemType itemType, Boolean dataBind, Object dataItem, DataGridColumn[] columns, TableRowCollection rows, PagedDataSource pagedDataSource)
at System.Web.UI.WebControls.DataGrid.CreateControlHierarchy(Boolean useDataSource)
at System.Web.UI.WebControls.BaseDataList.OnDataBinding(EventArgs e)
at System.Web.UI.WebControls.BaseDataList.DataBind()
at WebRoot.IntraNet_DetailDoc.Load_DDUpdate(DocumentStatuses DocStatus)
at WebRoot.IntraNet_DetailDoc.btnDDUpdate_Click(Object sender, EventArgs e)
at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
at System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
--- End of inner exception stack trace ---
at System.Web.UI.Page.HandleError(Exception e)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at ASP.intranet_detaildoc_aspx.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

[Beth]

Can you confirm that the error is only when multiple users are using your custom application at the same time?

Can you verify that permissions are still ok on the cache? You might try to open permissions just to make sure that some other problem hasn't been introduced.

[dprothero]

It does seem to be when multiple users are on the system. We use a simple "lock" file to determine if someone is using Vault operations on the ASP.NET app. Other users wait up to 30 seconds and then timeout with a message to try again later.

I assume by cache you are referring to the Path we are passing tot he ClientInstance.Init method (localStoreBasePath)?

_ci.Init(VaultConnection.AccessLevelType.Client, strVaultWorkFolder)

Just now, I've set the permissions to Full Control for Everyone to see if that will affect the issue.

[Beth]

While waiting for results from the permissions change, can you tell me if you are using a "system wide" semaphore?

[dprothero]

We are using a file on the filesystem of the server, so, yes, I would consider it "system wide".

[Beth]

Just now, I've set the permissions to Full Control for Everyone to see if that will affect the issue.

What are the results from this action? Anything different or more errors?

[dprothero]

Unfortunately, we are still receiving the same errors.

[jclausius]

Nothing has changed in this regard from Fortress to Vault Pro except for the creation of a VaultPro virtual directory.

Can you go over your semaphore again? Are you positive nothing is re-entrant? Nothing would've changed that affected the API in this manner. The only thing that would require effort would be recompiling against the new API.

[alfred123]

For ASP.NET, things are a bit different. By default, ASP.NET will run under a special account called ASPNET. This account is a "least privileged" account which means it's pretty restricted in the things it can do on your system. To make things a bit more confusing, on Windows Server 2003, an account called "Network Service" is used by default instead of the ASPNET account.

So, whether you are using Anonymous Access or Basic / Integrated security, the account is always the ASPNET or Network Service account. However, you can change this by modifying the Web.Config file for the application. To make the change, you can add an <identity impersonate="true" /> to the <system.web> section. If you add the element, IIS will impersonate the current user and use that account instead of the ASPNET account. This means that with Anonymous Access enabled, this account is the anonymous account. Usually, this will be the IUSR_MachineName account, but check out step 4 of the instructions for classic ASP to find out whether that is true or not in your situation.

[Beth]

Thank you for the additional information.

The user has been in contact with us offline since this thread and any issues have been fixed.