The SysDatabaseLog wizard seems to group the tables that are available for auditing by the result of this method call. MSDN has no documentation on this method.
I need to know what it is returning so I can have a chance of putting some user tables into the wizard.
It returns the label of the topmost parent security key.
E.g. the security key of PriceDiscTable is BasicTables, the parent security key of BasicTables is Basic - it doesn't have a parent, hence its label (Basic in English, Basis in Danish, etc.) will be returned.
Okay the code is actually available in AX. It returns the name of the Security Key.
Related
Using DQMan or Document Admistrator, what's DQL statement to get hash of document in DCTM?
Select ... ?
If it's not possible how can I get it?
(I know exactly which is the document, r_chronicle_id, r_object_id, etc...)
AFAIK there is no field representing a document hash, but take a look in the dmr_content object table. It should be here if there is one (I haven't checked I several years).
Alternatively you would have to get it with API - either there is a method or you should do it yourself. Take a look in the api guide.
Edit: just searched the object reference guide. Turns out that there is a field in dmr_content. It's called r_content_hash.
Have a look at it to see if your docbase fulfills requirements to have this field populated. Maybe you're in luck ;-)
First the user can have multiple roles at the same time, and the role has scope. For example,
one user has three roles: /scopeA/editor, /scopeA/programmer, /scopeB/editor
and /scopeA/editor has access to resource /scopeA/post
/scopeA/programmer has access to resource /scopeA/bug
/scopeB/editor has access to resource /scopeB/post
so the question comes:
how can i declare a policy saying: if there is a role named "/XX/editor" in the role bag, then the corresponding user has access to "/YY/post", when "XX == YY"
I found a similar question here, and i proposed a way to solve the problem, but when it comes to multiple role(the role attribute value is a bag), my answer is not right. Because the role attribute value is a bag, I cannot just get the part between the first two slashes of the role attribute value, and compare to that of the resource attribute,
then i tried to find a higher-order bag function to do this, the "urn:oasis:names:tc:xacml:3.0:function:any-of" function can do this, but what about the first "function argument" of the any-of function?
here is what i do: the first argument of the any-of function is "string-equal", and the second argument is a function used to get the part between the first two slashes of the resouce-id, the third argument is the attribute value of the subject which is a bag.
so all i need to do is to define a function to get the part between the first two slashes, right?
is there a better way to do what i want? if anything is unclear, plz let me know, thanks~~
This is a great question. We call this issue the attributes of relations challenge. Essentially, a user has a role within a given context or scope as you call it.
If I read a user's role from the db based on the user's identity only, then I would get back the list of roles independently of the scope e.g. editor, publisher, reviewer...
This would lead to the risk I could edit a post outside the scope for which I have the right role.
There are several ways to solve this issue. One way is to define stricter mappings in your policy information point.
Using Policy Information Points
Assume that the XACML request says: "Can Alice edit post 123?". Your policy would state (in ALFA syntax):
policy editPost{
target clause resourceType=="post" and actionId=="edit"
apply firstApplicable
rule allowEditors{
target clause userRole=="editor"
permit
}
}
The notion of scope doesn't directly show up in the policy. The underlying mapping to the source of attributes would be as follows:
map userRole to the field role of the table usersRoleAssignment using SELECT role FROM usersRoleAssignment WHERE uid=? AND scope=?
uid would be mapped to the user identity that came in the XACML request.
scope would be a resource attribute that would also be mapped in the PIP as follows
map scope to the field scope of the table posts using SELECT scope FROM posts WHERE pid=?
pid would be mapped to the identifier of the post in question. That also came in the XACML request.
This means that your attribute userRole should really be called scopedUserRole. The modeling I gave is just one example. There are several other ways you could model with the same effect. Either way, all the heavy lifting happens inside the PIPs. The main drawback is that you lose visibility of the semantics of your authorization logic.
Using attributes values and functions
Another way of achieving a similar result is to store the relationship between scope and role in the value itself. This is what you allude to in your question.
You can use string functions such as string-starts-with or string-ends-with or string-contains to achieve what you're interested in. There is also a string-regexp-match function you can use.
Details on the functions can be found in the XACML 3.0 specification.
If the functions are not sufficient in XACML, you can:
implement your own
implement a PIP that can process your attribute values and produce new ones. More on PIPs here.
Creating a new datatype called tuple
The problem with XACML is that it flattens relationships. Using a new data type with multiple parts, i.e. a Tuple, would solve the issue. That would require custom coding though and quite some work.
Using the XML content inside a XACML request
If all the information comse from the XACML request, then it could be expressed as an XML payload as part of the <Content/> element inside a XACML request. You could then use attribute selectors and XPath to retrieve what you are interested in.
HTH. Do check out both my blog and the Axiomatics blog for more tips.
I've looked at plenty of examples on this site, but I'm still not sure how to do this:
For illustration, let's say I have persistent Venues, each of which has a collection of Events, where each Event has ReservationDate. If I want to get all the Venues whose next Event is of type "Wedding", how would I go about it? It requires selecting based on a value of a specific element (in this case the first ReservationDate > Today) in the child collection, that element being determined by a different restriction (Type == "Wedding").
I've looked at various queries using CreateCriteria, QueryOver, DetachedCriteria, JoinOver and the whole gamut of NH query options (I don't want to use HQL), but I'm still at a loss.
Your help is appreciated.
Michael
I've created very detailed example how to handle these situations. Please see all the details here:
Query on HasMany reference
The point is to create few Subqueries represented as DetachedCriteria. Using aliasing we can communicate among them (passing the ID).
At the end, we can SELECT clean/flat structure of the ROOT entity... while having full power of filtering based on referenced collecitons.
This approach has the biggest advantage in the fact, that we can apply the paging (Take(), Skip()) because the final select is on top of the root table
I have a User ndb.Model which has a username StringProperty that allows upper en lower case letters, at some point I wanted to fetch users by username but have the case forced to lowercase for the filtering. Therefor I added a ComputedProperty to User: username_lower which returns the lowercase version of the username as follows:
#ndb.ComputedProperty
def username_lower(self):
return self.username.lower()
then I filter the query like so:
query = query.filter(User.username_lower==username_input.lower())
This works, however it only does for users created (put) after I added this to the model. Users created before don't get filtered by this query. I first thought the ComputedProperty wasn't working for the older users. However, tried this and calling .username_lower on an old user does work.
Finally, I found a solution to this is to fetch all users and just run a .put_multi(all_users)
So seems like a ComputedProperty added later to the model works when you invoke it straight but doesn't filter at first. Does it not get indexed automatically ? or could it be a caching thing.. ?
any insight to why it was behaving like this would be welcome
thanks
this is the expected behaviour. The value of a ComputedProperty (or any property for that matter I guess) is indexed when the object is "put". The datastore does not do automatic schema updates or anything like that. When you update your schema you need to either allow for different schema versions in your code or update your entities individually. In the case of changes to indexing you have no choice but to update your entities. The MapReduce API can be used for updating entities to avoid request limitations and the like.
In the android Notes demo, it accepts the URI:
sUriMatcher.addURI(NotePad.AUTHORITY, "notes", NOTES);
sUriMatcher.addURI(NotePad.AUTHORITY, "notes/#", NOTE_ID);
Where the difference between notes and notes/# is that notes/# returns the note who's ID matches #.
However, the managedQuery() method that is used to get data from the content provider has the following parameters:
Parameters
uri The URI of the content provider to query.
projection List of columns to return.
selection SQL WHERE clause.
selectionArgs The arguments to selection, if any ?s are pesent
sortOrder SQL ORDER BY clause.
So, is there any particular cause for the design decision of providing a URI for that, rather than just using the selection parameter? Or is it just a matter of taste?
Thank you.
I thinks its so you can do more complex lookups without having to complicate your selections and arguments. For example in my project I have multiple tables but use the same selection and arguments. To filter content. By using the URI I don't have interpret the query, I can just switch on the URI. It.might be personal taste to begin with. But in more complex scenarios you appreciate the URI. You can also use * to match strings in the same.way you can with#.
I think it's mostly a matter of taste. IMHO, putting the id in the Uri is a little cleaner since you can make the id opaque rather than require the client to know that it actually represents a specific row id. For instance, you can pass a lookup key (like in the the Contacts API) rather than a specific row id.