How to add multiple values to a claim in policy - azure-api-management

I am working with API Management policy expressions and trying to create a claim with multiple values dynamically. I have a list of string values and want to create a claim values from that string list.
e.g "123232,43434,545455,5656565,676767" and i want to add these values to claim dynamically
<validate-jwt............>
<required-claims>
<claim name="test" match="any">
<value> </value> how can i create multiple value dynamically
</claim>
</required-claims>
</validate-jwt>

I think you can split the string to array and apply claims like below:
<required-claims>
<claim name="group" match="any">
<value>value[0]</value>
<value>value[1]</value>
</claim>
</required-claims>
Also refer https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#authorize-access-to-operations-based-on-token-claims

Related

Accessing Jaspersoft Report fields with nested JSON data fails using dot notation

I want to use data from a DSpace REST API in a Jasper report. I have successfully created a data adapter with type "JSON File" and provided the resource URL and set GET as request type. When I use that data adapter in my report, I can edit its options and when I click "Read Fields" in Jaspersoft Studio, I see the tree of nested JSON objects according to my request, as expected.
I now want to use different of levels of the JSON in the fields of my report. This works fine for the top level values, however, when I try to access the nested values using dot notation, no data is displayed in the report.
Example:
<field name="sections.publications_result.dc.title.value" class="java.lang.String">
<property name="net.sf.jasperreports.jsonql.field.expression">
<![CDATA[sections.result.dc.title.value]]>
</property>
</field>
How do I get the nested values?
The problem is that there are dots (.) in the names of your JSON response. I guess Jasper assumes that each dot denotes one sublevel. You need to "escape" those identifiers that have a dot in them.
E.g., if dc.title is one identifier,
sections.result.dc.title.value
needs to be changed to
sections.result["dc.title"].value
in your "Field Expression".

Get selected values from multiple dynamically generated Mat Selection Lists in Angular

I am generating and populating multiple <mat-selection-list>s, the number of which is dynamic and based on user input. I need to collect the selected values from those lists upon submission, but I don't know how to uniquely identify the lists.
Each instance of user input results in two <mat-selection-lists>s, so I need to not only identify which variety of the two list but also which instance of user input populated the list.
The lists are currently generated in an *ngFor loop and I am tracking the index value of each list, so if I could attach that index value to something like a template reference variable for each list variety I would be set.
A potential solution would look something like this:
<mat-expansion-panel *ngFor="let customer of customersAry; let x=index">
<!-- Here is where I would create a dynamic variable name
to be referenced in the typescript file -->
<mat-selection-list #'details'+k>
<mat-list-option>Name</mat-list-option>
<mat-list-option>Email</mat-list-option>
</mat-selection-list>
</mat-expansion-panel>
where I create some type of dynamic variable attached to the <mat-selection-list> tag.
I've tried using template reference variables as seen here as well as [(ngModel)] but can't find a solution that solves my problem.

Infusionsoft populate custom field via API

I am trying to set the value of a custom field that belongs to a contact via the Infusionsoft API.
When I try to create or update the contact with the custom field value set I receive the following response:
[NoFieldFound]No field found: Contact.InitialSiteVisitTime
Which leads me to believe that the custom field value is stored in a different table. Can anyone please tell me the name of the table that holds Infusionsofts custom field values?
Infusionsoft automatically prefixes custom field names with an underscore. Adding the underscore to the name allows to populate this value via the API successfully.
Note, that custom fields API names (the way they stored in Infusionsoft database) not always equal to how you name a custom field on creation.
This article shows where your actual custom fields API names are listed.

django using variable in request.POST.get('x')

In my current project, users can create spreadsheets with fields, then each field inherits a unique ID based on the column it is attached to in the spreadsheet, so when fields are updated, my template looks like this:
<input type="text" name="{{field.unique_id}}" id="{{field.unique_id}}" value="{{field.data}}">
But in my views, when I attempt to grab the value from the field:
request.POST.get('field.unique_id')
It sees nothing because it's looking for literally 'field.unique_id' and not the variable that field.unique_id would produce.
Is there a way to tell it to replace field.unique_id with the variable or do I have to define the id of the POST get manually?
You can use a variable in request.POST.get() instead of a string, for example.
request.POST.get(my_var)
However in your case, request.POST.get(field.unique_id) does not work, since the keys in request.POST are strings, and field.unique_id is an integer.
The answer is to use str() to convert it to a string.
request.POST.get(str(field.unique_id))

Re-use web service response across datasets or subreports

I'm using a web service as my XML datasource which returns entities including multiple hierarchical data like below (codes modified for project privacy);
public class UserData {
// some scalar properties
public string Id ...
public string Name ...
public string Surname ...
// some navigational properties
public Address address ...
public CourseInfo[] courses ...
public AwardInfo[] awards ...
}
To show all the entity information inside the same report, I can create different datasets in my report to call my web service and filter preferred parts of the returned service response.
To get only UserData properties:
<Query>
<Method Name="GetUserData" Namespace="UserApp.ReportingServices"/>
<SoapAction>UserApp.ReportingServices/IReportingService/GetUserData</SoapAction>
<ElementPath IgnoreNamespaces="true">GetUserDataResponse{}/UserData</ElementPath>
</Query>
To get Address information together with UserData properties:
<Query>
<Method Name="GetUserData" Namespace="UserApp.ReportingServices"/>
<SoapAction>UserApp.ReportingServices/IReportingService/GetUserData</SoapAction>
<ElementPath IgnoreNamespaces="true">GetUserDataResponse{}/UserData/Address</ElementPath>
</Query>
To get course information together with UserData properties:
<Query>
<Method Name="GetUserData" Namespace="UserApp.ReportingServices"/>
<SoapAction>UserApp.ReportingServices/IReportingService/GetUserData</SoapAction>
<ElementPath IgnoreNamespaces="true">GetUserDataResponse{}/UserData/Courses/CourseInfo</ElementPath>
</Query>
My question raises right here: If I use multiple dataset queries like above, my report will make a web service call for every dataset it has though my service always returns the same XML response which includes all the data needed for the three datasets above.
Is there any way to re-use returned XML response of a query for the other datasets? If it would possible, my report would call the web service only one time, and datasets would filter different parts of that XML response without calling the web service again and again.
If this is not possible, than what's the best practice about showing multiple hierarchical data inside the same report? Do I have to create different web services returning different hierarchical parts of the data?
Reporting Services datasets are limited to a simple table of rows and columns - they can't handle data with multiple hierarchies as you have described.
I would redesign your web service to reflect this, probably splitting it into the three sets of data you described. Then there will be three web service calls, but without the duplication of content. They will also be executed in parallel which will probably be more efficient overall than your current design.