Possible Bug, Extension executes the OnLogOn and OnLogOff hundreds of times

Possible Bug, Extension executes the OnLogOn and OnLogOff hundreds of times

thomas.behrendY5FX4
Advocate Advocate
478 Views
4 Replies
Message 1 of 5

Possible Bug, Extension executes the OnLogOn and OnLogOff hundreds of times

thomas.behrendY5FX4
Advocate
Advocate

Good Morning,

 

I already wrote in the Recycle Bin threat something, I see as a bug in the system. I created my Vault Extension based on the example provided in the SDK.

So far, I had no problem, but yesterday we found a problem with our Recycle Bin implementation and needed to load the Groups the currently logged in User is member of.

But he has no ACL´s for "User Read" and "Admin Read". In the SDK documentation under Knowledge Base -> User Impersonation is a workaround we had to use in the end. So my OnLogOn Method was extended:

 

Autodesk.DataManagement.Client.Framework.Vault.Results.LogInResult results
	= Autodesk.DataManagement.Client.Framework.Vault.Library.ConnectionManager.LogIn(
		application.Connection.Server,
		application.Connection.Vault,
		"ExtensionAdmin",
		"929njcicui294e", // Not the real username or password ;-)
		AuthenticationFlags.ServerLicense,
		null
);

if (results != null && results.Success) {
	try {
		var adminConnection = results.Connection.WebServiceManager;
		
		// Next Bug, Roles and Groups are empty
		boot.UserInfo = adminConnection.AdminService.GetUserInfoByUserId(application.Connection.UserID);
		
		var allGroups = adminConnection.AdminService.GetAllGroups().ToList();
		var tempGroupMemberships = new List<Autodesk.Connectivity.WebServices.Group>();

		allGroups.ForEach(group => {
			var members4Groups = adminConnection.AdminService.GetMemberUsersByGroupId(group.Id);
			
			if (members4Groups != null && members4Groups
				.ToList()
				.Where(user => user.Name.Equals(boot.UserInfo.User.Name))
				.FirstOrDefault() != null) { 
				tempGroupMemberships.Add(group);
			}
		});

		boot.UserInfo.Groups = tempGroupMemberships.ToArray();
	} finally {
		Autodesk.DataManagement.Client.Framework.Vault.Library.ConnectionManager.LogOut(results.Connection);
	}
}

Now the real hell in the Client began with NullPointer Exceptions and MessageBoxes (the OnLogOff Method is called when I LogOut from the Admin Connection)

 

The methods were called hundreds of times, my Screen exploded with Messageboxes from the OnLogOff Method and I had to kill Vault. Debugging it, I saw that the Method was called over and over again when the Client started up.

 

That shouldn´t be the case in my opinion, it should be loaded only once.  We also use Vault DataStandard Customizations outside of the C# project.

 

When I remove the MessageBox from the Vault.Custom -> Default.ps1 -> OnLogOff method, it works again normaly.

Vault shouldn´t call the OnLogOff Methods when the Adminsession is terminated, that is a bit a sour taste in design.

 

Maybe somebody has an Idea how to solve such problems for a more stable system.

 

Best Regards

Thomas

0 Likes
479 Views
4 Replies
Replies (4)
Message 2 of 5

Markus.Koechl
Autodesk
Autodesk

Vault 2020 introduced user-defined roles. Since then, we recommend creating a role promoting the required read permissions to the user groups for customizations instead of following the impersonation user strategy. 



Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
0 Likes
Message 3 of 5

thomas.behrendY5FX4
Advocate
Advocate

Hi Markus,

 

yes, "User Read" and "Administrator User Read" are needed for the impersonated user. Normal user are not allowed, per company policy, to have such rights.

 

Problem is, I can read too much information of other users with these roles. For a future release, I suggest to have either the UserInfo object in the application.Connection object or a new Webservice Endpoint on AdminService like GetUserInfoForCurrentUser() without parameters and it returns the UserObject of the Connection user. Users should get their own Principals without the need of special rights. Same could be done with Groups (GetGroupMembershipsForCurrentUser) and Roles (GetRoleMembershipsForCurrentUser) when I need it again.

 

I prefere the first method and when I switch the user with a Logoff and Login, it is updated automatically.

 

Any Dev should use this connection and then, you can i.e. add Menus based on his Role or Group.

 

The AdminService.GetUserInfoByUserId(id) Endpoint is doing a similar thing, but it doesn´t return the Groups or Roles somehow, the only Group in it is "All" and the Roles are null. Maybe it´s because we lack the permission, but CSO says no to "User Read".

0 Likes
Message 4 of 5

Markus.Koechl
Autodesk
Autodesk

Admin User Read permission does not allow to access user information from a UI perspective. 

GetUSerInfoByUserId returns the directly assigned roles if there are any. Roles propagated by groups require to iterate the parent groups. GetParentGroupIdsByGroupId(<user.id>) return all recursively.

My preferred "fast track" is querying the user's permissions instead of iterating: GetPermissionsByUserId() does not require specific permission for the logged-in user self. To retrieve permissions from other user accounts, Admin User Read permission is required.



Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
0 Likes
Message 5 of 5

thomas.behrendY5FX4
Advocate
Advocate

For the behaviour of the logon/logoff, the permissions are not the problem. It looked like the Extension was loaded over and over again, even when not in Debug by Visual Studio. I had a Messagebox in my Extension Logoff Method, one in DataStandard LogoOff and in LogOn the Impersonate User Logon/Logoff. Then it happend. I moved the Messagebox reminder into my Extension, but it could happen to anybody.

 

I don´t look for permissions, but that can come in useful some day. If there would be a way to create new permissions, we could create better ACL´s, that´s also true.

 

Again, the background is a bit more complex:

Let`s asume you give users the permission to delete files and folders, but only certain roles have these permissions. This can be handled by ACL´s by Vault.

 

Now we want to give certain users the right to delete, but restrict every delete event to a) move the file to the recycle bin folder, if it´s not already in there b) if the file is in the recycle bin folder, and no other restrictions intersects (LifeCycles, Child Associations etc.), only a small set of people or groups should be able to delete them from this special folder.

 

But there is no special recycle bin folder in this Document Managment System, we had to make our own implementation.

 

That is why I found this behaviour. I´ve created a restriction for the DeleteFileEvents and lookup the memberships of the user who deletes and if he is allowed to delete the file. Real delete, not move.

 

Our users are setup with groups, the groups have roles and in the roles, we have the permissions. So I assumed, AdminService.GetUserInfoByUserId (id), would load my groups but I have to ask for the groups manually and iterate through it, like you said. That´s destroying the point of having this Endpoint when I can set the username and id manually.

 

If there would be an object in the Logon Result in the future and the application.connection has it, that would be nice, because we also planned for menu items based the users group memberships. Also something that is missing in Vault imho. Oh, and of course, adding an Icon in the Context-Menu 🙂

0 Likes