I am looking to compare user attributes to resource data to permit access. I.E. permit if user office == office of record.
Is the only way to do this using a Context Enricher with a Condition Evaluator? Or is there something more "out of the box"?
Thank you
Based on my research, which was months ago, yes, you need to extend Apache Ranger in order to conditional evaluation.
Related
The iceberg documentation discusses using merge-on-read when deleting data. The documentation also refers to doing position deletes versus equality deletes. It seems straight forward to specify that I want merge-on-read in the table properties.
I've looked through the iceberg documentation and also found a half dozen external sites that talk about the pro's and con's of each method, but none of them describe how to specify position versus equality. Is this a table property? How do I choose a method?
I'm using spark 3.3 on EMR with scala/python
You don't need to specify POS or EQ delete. These two delete methods are automatically selected within the engine based on different scenarios.
To better use iceberg, you may need to pay attention to the following:
Use merge-on-read or cory-on-write
Merge files by specified policy
Expired snapshots and data deletion
Hope it helps you.
I want to prevent anyone from deleting my registered filter except my account.
I wonder that is possible if I set security descriptor in FwpmFilterAdd function.
And could you show me source code of example which adds a filter using security descriptor for my purpose?
I read "Hindering Filter Deletion" and "Forcing Filter Deletion" in WFP msdn.
Is there any method preventing anyone from forcing filter deletion?
Thank you in advance.
First, just for context, these are the links to sample code you were referring to:
Hindering Filter Deletion
Forcing Filter Deletion
The samples there simply illustrate how to use FwpmFilterSetSecurityInfoByKey0 and FwpmFilterGetSecurityInfoByKey0 API. However the practical purpose of the specific scenario chosen for these samples is quite dubious. Why would anyone want set explicit ACLs on WFP filter to disable DELETE access to the world, along with disabling WRITE_DAC and WRITE_OWNER? For all practical purposes, local administrators can always take ownership of the object back, then overwrite the security descriptor (which is what the "Forcing Filter Deletion" sample is doing). Non-administrators cannot take ownership of other account's objects, and cannot delete WPF filters even with default security descriptor, that will be given to the filter by passing NULL as third parameter to FwpmFilterAdd.
To answer your question, no you don't need to secure it any further. You will not gain any more security by using the "Hindering Filter Deletion" technique. The best that technique is doing is adding small layer of obfuscation. Your default DACL you get for WFP filter is BFE engine DACL, described here. With default DACL only local administrators have DELETE access. And local administrators can do anything to the system by definition, so there is no point of security anything from administrators.
Well, first: I found this question:
What to use: JPQL or Criteria API?
and from other searches I suppose that the only benefit of criteria api is that can check the query and, if it isn't correct, returns a compiler error.
Is it right?
If no, which are the advantage and disavantage from using JPQL or Criteria Api?
P.S.: The question is born after this other question:
https://stackoverflow.com/questions/8342955/error-in-criteriaquery
and the difficult that I'm finding to resolve that problem when I do the correct method using JPQL in 20 minutes...
I think what you are asking is when would you consider a Criteria Query.
I will further assume you are using an Application Server.
The Criteria API exists to allow for the construction of dynamic SQL queries in a type-safe manner that prevents SQL injection. Otherwise you would be concatenating SQL strings together which is both error prone and a security risk: i.e. SQL Injection. That would be the only time you would want to use the Criteria API.
If the query remains basically the same but need only accept different parameters you should use annotated #NamedQueries which are simpler, precompiled, can be cached within the secondary cache and validated during server startup.
That's basically the the rule of thumb concerning Criteria Queries versus #NamedQueries. In my experience rarely do you require the Criteria API but it is good that it exists for those rare times it is required.
Hope this helps.
In migrating to CRM 2011, we're discovering different developers used different capitalization of custom entities and custom fields. This creates a headache for custom programming using the early bound methods. http://msdn.microsoft.com/en-us/library/gg327844.aspx. Is there a way to normalize the entity/field names before (or after) the migration?
As far as I'm aware. The only way to achieve the correct capitalisation you desire is to recreate the entities with the appropriate names.
Before or after the migration is mostly the upgrade of the CRM Server installation and modifying the database schema to reflect the upgrade, while still maintaining the current data and customisation data.
Thats as far as the "Supported" spiel goes.
As for an actual workaround. If your looking to upgrade anyway I'd be tempted to restore your current CRM 4 system to a test domain. Then look at how feasible it is to change the schema names in the actual "untouchable" crm database. I believe there is a MetaDataSchema.Entity table where this is centrally stored so i'd test this to see how usable this is and what impact it has on say the webservice.
So you face a similiar choice that I face on multiple occasions while working with Dynamics CRM. Go with the supported way, or a bit of "Yee-Ha" development. Sorry it's probably not what you want to hear!
Edit:
In regards to what to change I can't say for sure as I haven't got a CRM 4.0 system to hand only a 2011 at this moment in time. However as an example, there will be a MetadataSchema.Entity table in the [OrganisationName_MSCRM] Database. Of which certain columns will jump out. Name, PhysicalName and Logical Name.
Logical name is the one that CRM users which it defaults to lowercase no matter how you enter it.
I believe PhysicalName and Name are the ones you would be looking to change into lower case.
The actual "Name" of the entity, eg logical name is "account" whereas in CRM where it is displayed in a user friendly way is related through a table called MetadataSchema.LocalizedLabel through the foreign key "ObjectId" which in this case would be the "EntityId" field.
This is where I would be looking to do the changes as it shouldn't have an impact on the rest of the data due to the "logicalname" field being the one CRM probably uses.
As far as your generation for strongly types classes goes.
if you use latebound such as
relatedEntity.LogicalName = "new_related_account";
relatedEntity["relatedaccountid"] = entity["accountid"];
then all the properties and logical names need to be lower case. As this will use the "logicalname" property previously identified in the MetadataSchema table.
Howver using SVCUtil I can only assume it looks at the "Name" and "Physical Name" attributes to give a slightly more user friendly coding experience when it generates the file for use in custom applications.
Though if you are looking to use the early bound class generation it shouldn't be a problem as the definition file generated will provide intellisense on the correct capitalisation of attributes and properties, and if you are using late bound like the example previously it's all lower case. So it's more it will just be a bit untidy to look at than completely impractical =)
I have a requirement to retrieve data from share point (I guess it is 2010, but will check with admin if relevant) and generate an excel report/chart. Say we have a bug tracking system in share point. Currently, I could create a view and see some statistics, but I need to plot a graph to see historically (every week) how the number of bugs changed. For example,
get the number of bugs filed in a specific week
do some grouping based on type/severity
based on classification get number of bugs solved that week etc.
If I can get the numbers based on date range, I may use excel to plot the graph.
After some reading, SharePoint object model come close to what I used to work with (Oracle DB). I understand it may be entirely different from tradition db and querying.
Please help me with
What is the best method to approach this?
Is there a good book/resource.
Thanks a lot,
bsr
The easiest apprach would be to LINK to the sharepoint lists using Access 2007 or 2010 and then export the data to Excel for further processling. Of course, you could also write a program that uses CAML query to access the data. Your requirement sound straightforward, unless you need to automate the reporting process, the simplest approach would be to access the lists via an access database.
You could also create a web service via REST that pulls the data directly into Excel.
SharePoint has it's own query language: CAML query, and in theory that could be used to retrieve the list you seek.
And you should be prepared for "some" trial and error.
Tools I used:
http://www.u2u.be/res/tools/camlquerybuilder.aspx
http://spud.codeplex.com/
what I understand from this question is that you have the need to put the SharePoint data to an excel file and this from within the SharePoint site? So it looks to me that you could just create a simple SharePoint web part that consists of one button "generate excel file". So when the user clicks on the button you would just query your SPList object(SharePoint object model) and you would get all the necessary data from the list (SPListItems).
This is the way that I would take. Mind you that this is offcourse custom SharePoint Development (.NET c#). There are lots of books or blogs that described how to create your own web part in SharePoint.