Starting from version 12.2, we will provide a DC-based demo that works with the new security system (Client-Side Security UI and Integrated modes are currently supported. The middle-tier scenario will be supported in the future). For your convenience, both XPO and DC-based versions will be available as part of our SecurityDemo solution.
Security - Support domain components in the new security system (Client-Side UI and Integrated modes)
Answers approved by DevExpress Support
I wanted to explicitly repeat the description of the DC operation specifics in a middle-tier scenario with regard to the shared parts we discussed earlier in this thread. The matter is that security permissions do not affect objects corresponding to shared parts and they are always loaded (e.g., a developer can always access them in code) by default. However, this does not affect end-users of your application in any way since the application itself behaves normally and displays "Protected Content" where required. There is no such specifics in the UI-level mode.
Other Answers
If you are using domain components + complex security strategy + middle tier application server, then you can get things running by writing a patched version of the ServerSecurityClient class like this:
C#/// <summary>
/// Patch requests to ServerSecurityClient.
/// </summary>
public class PatchedServerSecurityClient : ServerSecurityClient, IRequestSecurityStrategy
{
#region Constructors
public PatchedServerSecurityClient(IServerSecurity serverSecurity, IClientInfoFactory clientInfoFactory)
: base(serverSecurity, clientInfoFactory)
{
}
public PatchedServerSecurityClient(IServerSecurity serverSecurity)
: this(serverSecurity, new ClientInfoFactory())
{
}
#endregion
/// <summary>
/// Patch.
/// </summary>
/// <param name="assemblyQualifiedName">The assembly-qualified name of the type to get the permissions for.</param>
/// <param name="membersName">The members to calculate the read-only status for.</param>
/// <param name="targetObjectsHandle">The handles of the objects to deal with.</param>
/// <returns>The permission matrix</returns>
Dictionary<string, bool> IRequestSecurity.CanReadMembers(string assemblyQualifiedName, List<string> membersName, List<string> targetObjectsHandle)
{
// Apply a patch for generated classes
if (assemblyQualifiedName.StartsWith("DevExpress.ExpressApp.DC.GeneratedClasses"))
{
// Get the first object handle. It is of the following form:
// DOMAINCOMPONENT_FULLTYPENAME ( HANDLE ) ...
// ---> we extract the domain component full type name here.
string dcTypeName = targetObjectsHandle.First();
dcTypeName = dcTypeName.Substring(0, dcTypeName.IndexOf('('));
// Now we search the registered domain component type with that full name.
var dcAssemblyQualifiedTypeName =
(from type in XafTypesInfo.PersistentEntityStore.RegisteredEntities
where type.FullName == dcTypeName
select type.AssemblyQualifiedName).FirstOrDefault();
if (dcAssemblyQualifiedTypeName != null)
// If we were successfull, patch the assemblyQualifiedName parameter.
assemblyQualifiedName = dcAssemblyQualifiedTypeName;
else
// Otherwise allow anything.
return membersName.ToDictionary((s) => s, (s) => true);
}
// Run base logic
return base.CanReadMembers(assemblyQualifiedName, membersName, targetObjectsHandle);
}
/// <summary>
/// Patch.
/// </summary>
/// <param name="permissionRequest">The request to elaborate.</param>
bool IRequestSecurity.IsGranted(IPermissionRequest permissionRequest)
{
var request = permissionRequest as ClientPermissionRequest;
// Decode the request: Is it a ClientPermissionRequest for a generated class?
if (request != null && request.ObjectType.FullName.StartsWith("DevExpress.ExpressApp.DC.GeneratedClasses"))
{
// Get the domain component type of the generated class.
var dcType = XafTypesInfo.CastTypeToTypeInfo(request.ObjectType);
permissionRequest = new ClientPermissionRequest(
dcType.Type, request.MemberName, request.TargetObjectHandle, request.Operation);
}
return base.IsGranted(permissionRequest);
}
}
Then, go to your WinForms client and instead of
C#var securityClient =
new ServerSecurityClient(clientDataServer, new ClientInfoFactory());
use:
C#var securityClient =
new PatchedServerSecurityClient(clientDataServer, new ClientInfoFactory());
The patch basically translates the generated class types (or generated class type names) into domain component types (or domain component type names).
I have been working cheerfully for several month with the work-around posted at: Q363027.
I hope it helps.
Sooo… Pretty disapointing that we still can't use DC with the new security system released last year. Is this going to be completed as part of a minor update? Or is it going to wait until 12.2?
Yes you're right. I asked the same question 6 months ago. It's rather strange DevExpress won't create an example despite their promises to do so.
Yes, I have asked the same question many times, But DevExpress still not willing to implement it, don't know why.
I've requested the example for manny times to. Still don't understand way the problem is…
Hi guys, Thank you for your interest in the domain components and the new security system. There is no example on the subject available because we have not yet fixed the following issue: B211934.
Let me now elaborate more on why it is taking us so long to fix this. Implementation of the IsGranted method for domain components (technically we have to deal with interfaces and not with classes) is not as straightforward as for regular persistent classes. In the first place ,this is because domain components may consist of smaller parts that are not registered as entities in the end application. Implementing a security system for these individual parts rather than for the entity as a whole creates many collisions and complexities. So, I would like to ask your opinion on whether we need to provide a security system implementation that will allow assigning permissions for these 1) smaller parts (not registered as entities) or for 2) registered entities only. The latter approach seems to be more logical to me, because after all, your end-users operate with entities and not by individual domain components. This also significantly decreases the complexity of the entire system. Take special note that people who require more control of this, will still be able to subclass the default security system and override the IsGranted method as they require. I would ask you show us your thoughts on this by posting 1) or 2) in the comments to this thread. Thank you for your help in advance.
Hello Dennis,
I think the RegisterSharedPart method is dispensable for us and I thinks the RegisterSharedPart method should be unified for Register method because sometimes we need to rename the sharing of DC , but the RegisterSharedPart method can not support the rename method,so I think the RegisterSharedPart method is dispensable for us.
thanks,
XinRong Liu
Release in 12.2?
For registered DC only sounds OK to me! Can you give us an estimate of when this will be implemented?
2 for me too.
Thank you for the feedback, guys. We will take it into account.
As for ETA, I am afraid I cannot share any dates at the moment. In any event, you will be automatically notified of any status changes.
Is there any news concerning this ticket?
Any news so far on this topic?
I think it is very important for dc and its users to implement this feature very soon!
At the moment, dc users cannot fully benefit the new security features. It will make dc quite useless using the 12.x releases.
+1 Arjan
i completely agree with you Arjan
+1 Arjan
+1 Arjan
+1 Arjan
Not using DC yet because of this. But next project I hope to use it when I migrate to 12.1
hope all of you guys vote for this issue not just leaving comments ;-)
Where/How do you vote?
At the top of this site, next to the picture of Dennis,… now there are 14 votes.
click on the up button.
see screenshot attached.
Duh! Never saw that!!
Any news???
Voted For!
Guys, we do not have any new information for you at the moment. When we have something to share with you, we will certainly update this thread. Thanks for your patience.
You are also right about upvoting the original message instead of putting these +1, which are not tracked by our system automatically. However, I would also ask you to upvote this only if you are really using DC and greatly interested in using the new security system (the old one already works fine) + middle tier with it, and not just because of coming across this thread and seeing other people liking it, not to negatively bias the results (especially taking into account that there are many other features you can benefit from instead).
This is a bit unsatisfactory to tell our customers also. We urgently need this piece of functionality because we're using DC in our new projects which we must deliver at the end of this year.
I understand your situation, Arjan. We do not have other suggestions at the moment except for using the old security system as demonstrated in the XCRM demo that works fine with DC. We apologize for all the inconvenience here.
Guys:
I wanted to inform you that we have made some changes in 12.2 regarding DC + new security system, and just finished recovering unit tests for the most common and simple scenarios . Note that as indicated and discussed with you above, we did not consider scenarios with assigning permissions to shared parts, but rather to real entities only. Also, we have not yet tested DC work in middle-tier scenarios and have not recovered respective functional tests for this. Please stay tuned to our further announcements.
I have one more piece of news regarding this. We have recovered our functional tests for the DC + middle-tier scenario. We will consider providing a demo application (similar to our SecurityDemo for regular persistent objects) that demonstrates how to use domain components with the new security system.
Very good news!!! I can't wait to see the demo…
thx XAF team.
Any news regarding the release date for 12.2??
Thanks
As indicated on our web site, it is scheduled for December, 3rd.
I've seen the demo in 12.2 and how domain components are used with the new security system. That's great. Anyway, I think most of us are waiting for the middle tier scenario to be supported. However, middle-tier + new security system + DC doesn't work yet, does it? (If so - how are the chances of this being supported in the next release?)
@Daniel: The middle-tier scenario is already supported in 12.2. Feel free to test it and share your feedback with us.
@Dennis: So it must be my fault then; I basically took the example from http://www.devexpress.com/Support/Center/e/E4035.aspx, upgraded it to version 12.2.4 and added a domain component to the module. (See attached solution.) I then ran the modified example and tried viewing an instance of the domain component - this gives an exception. I suppose it's just that the example is incomplete?
Thank you for the update, Daniel. We will examine your example and get back to you as soon as we can. Please bear with us.
We have examined this scenario and found out that, unfortunately, changes we have introduced are insufficient to support DC in the middle-tier security. I have created a separate suggestion in this regard: DC - Provide support for Domain Components in the RemoteSecuredDataServer/WcfSecuredDataServer classes. Currently, please use the Integrated Mode with domain components.
@Daniel: I apologize for the confusion as it was fully my fault about mixing up the client-side Integrated mode with the middle-tier scenario, which even though does use the same core internally (SecuredDataServer), has some specificities that we hope to work out as part of implementing the DC - Provide support for Domain Components in the RemoteSecuredDataServer/WcfSecuredDataServer classes suggestion. Please stay tuned.
I wonder why the ommision is defined in a suggestion rather than a bug considering the original request of implementing
the new security system for DC.
Is there any way we can develop support for middle tier ourselves?
thx
Arjan
@Arjan: I have just updated the DC - Provide support for Domain Components in the RemoteSecuredDataServer/WcfSecuredDataServer classes suggestion with a temporarily solution.