client - user usage
gabor-v opened this issue · 14 comments
Hi!
How can I decide, when only clientId needs to be changed and when should we additionally change the user as well? Can the same user use different clientIds simultaneously? For example:
Here only the clientId is changed - TestCase_S04_TC25_ConvertToSchemaJoinCoauth_SharedLock
Here the user is also changed (UserName02) - TestCase_S03_TC30_ReleaseLock_DifferentSchemaLockWithOneClient
I'm interested in MS-FSSHTTP.
Thank you very much!
@ChangDu2021 this is another clarification. I'm not seeing in the MS-FSSHTTP spec what is driving the need to change the user credentials in TestCase_S03_TC30_ReleaseLock_DifferentSchemaLockWithOneClient. Perhaps it's there and I missed it. Can you comment?
@tomjebo What I found in spec is in 3.1.4.4.2 Release Lock:
"The protocol server SHOULD[<52>] return an error code of "FileAlreadyLockedOnServer" if there is a current exclusive lock on the file or if there is a shared lock on the file with a different schema lock identifier." It doesn't indicate to change a user. I am working on verifying in code to see if it is also works without changing the user credential.
@ChangDu2021 thanks, I agree with that. Looking forward to what you find in testing this.
I'm going to wait on this thread to see if we need a behavior note in MS-FSSHTTP.
@tomjebo I ran this test case on SharePoint 2019, it always returns 'Success' instead of 'FileAlreadyLockedOnServer' no matter changing the user credential or not. I suspect that coauthoring session has already been deleted, so 'Success' status returned. I am still debugging the code.
@ChangDu2021 did you find any explanation for why the S03_TC30 test changes the user as well as the client ID? Since the specification doesn't mention anything about the user credentials for this, do you think it's not necessary? Maybe we should just move on and consider this an anomaly.
@tomjebo After I removed the code about changing the user and ran the test case S03_TC30 against SharePoint 2016, the test result has not been changed, so it is not necessary to change the user in S03_TC30. Actually, the key point of this test case is to use a different schema lock identifier to release a schema lock. So, it is not necessary to change user credential.
@tomjebo I ran this test case on SharePoint 2019, it always returns 'Success' instead of 'FileAlreadyLockedOnServer' no matter changing the user credential or not. I suspect that coauthoring session has already been deleted, so 'Success' status returned. I am still debugging the code.
@tomjebo Because below behavior note is for SharePoint 2010 and 2013, it is correct to return "Success" on SharePoint 2019. Now I tested the code on SharePoint 2016 and it also returns "FileAlreadyLockedOnServer", so we need to update the behavior note to include SharePoint 2016.
<52> Section 3.1.4.4.2: SharePoint Server 2013 and SharePoint Server 2010 return an error code "FileAlreadyLockedOnServer" if there is a shared lock with a different shared lock identifier and a coauthoring session with one client in it.
Hi! How can I decide, when only clientId needs to be changed and when should we additionally change the user as well? Can the same user use different clientIds simultaneously? For example:
Here only the clientId is changed - TestCase_S04_TC25_ConvertToSchemaJoinCoauth_SharedLock Here the user is also changed (UserName02) - TestCase_S03_TC30_ReleaseLock_DifferentSchemaLockWithOneClient
I'm interested in MS-FSSHTTP. Thank you very much!
@tomjebo To answer gabor's question, I think, we need to clarify the difference about the concept "User" and "Client". Here is the definition about ClientId in the spec. Do you think the "Client" mentioned below equals to a "user"? As my understand, a user can have more than one ClientId. Please correct me if I am wrong.
@JimZhao2023 I don't think user and ClientID are the same.
@tomjebo Thanks for your help.
@gabor-v Thanks for your question. After investigation, we don't find any description in spec about the need to change the user credentials in S03_TC30, we will remove the below code from it. And we have done the test and test case could be passed after removing the code. So, when we need to test the scenario, like coauthor with more than one client, we just need to change ClientId and don't need to change the user credential.
// Initialize the service using different user account.
this.InitializeContext(this.DefaultFileUrl, this.UserName02, this.Password02, this.Domain);
About another question, can the same user use different clientIds simultaneously?
I think it is yes. In S03_TC33, we prepare two different schema locks with two ClientIDs to simulate that there are more than one client in coauthoring session.
TestCase_S03_TC33_ReleaseLock_DifferentShardLockWithMoreThanOneClients()
// Prepare two schemaLock on a file with two clientIDs.
this.PrepareSchemaLock(this.DefaultFileUrl, SharedTestSuiteHelper.DefaultClientID, SharedTestSuiteHelper.ReservedSchemaLockID);
this.PrepareSchemaLock(this.DefaultFileUrl, Guid.NewGuid().ToString(), SharedTestSuiteHelper.ReservedSchemaLockID);
Please let me know if you have any other questions. And if everything is okay, could you please close this issue?
Thank you!
@JimZhao2023 Okay. In lots of cases the comments mention only changing the clientId indeed. But if the clientId is enough to be changed for coauthoring-testing, then what about the other occurrences of the user changing code (this.InitializeContext(this.DefaultFileUrl, this.UserName02, this.Password02, this.Domain))? It is used quite often in SharedTestCase/S02_Coauth.cs, but can also be found in S03_SchemaLock.cs or S01_Cell.cs or S07_EditorsTable.cs. I would like to understand in general in which use cases should I change both (like for example only for testing different authorization rights)?
What should happen, when different users use the same clientId accidently? Is it a valid situation?
@gabor-v Generally, if "a client with a different user name than the current client" is mentioned in spec, the related use cases should change both; otherwise, they are both okay to change the user or not.
"If there is a current exclusive lock on the file or a shared lock on the file with a different schema lock identifier, the protocol server returns an error code value set to "FileAlreadyLockedOnServer". If the coauthorable file is checked out on the server and checked out by a client with a different user name than the current client, the protocol server returns an error code value set to 'FileAlreadyCheckedOutOnServer'."
Here is an example about FileAlreadyLockedOnServer error code verification, it must use two users to test because "Check Out" operation is to block other users' operation.
TestCase_S02_TC03_JoinCoauthoringSession_FileAlreadyLockedOnServer_ExclusiveLock
For other test cases you mentioned in
S03_SchemaLock.cs or S01_Cell.cs or S07_EditorsTable.cs, we tested a few test cases after removing the code about changing different user, they can also passed. So, they are both okay to change the user or not. No matter use a user with different client ID or use two users with different client ID, both meet the spec.
I don't think it is a valid situation about different users use the same clientId, please see below definition about ClientID, it should be unique no matter a client with the same user name or a client with a different user name.
ClientID: A string that serves to uniquely identify each client that has access to a shared lock on a coauthorable file. ClientID MUST be specified on all types of schema lock subrequests. The different types of schema lock subrequest are defined in section 2.3.3.5.
Okay, thank you for all of you, I close this issue.