Returned SAML assertion for all the attributes default to
xsi:type="xsd:string"
In Assertion response, it showing like below
<saml2:Attribute
FriendlyName="givenName"
Name="givenName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string">testshibboleth
</saml2:AttributeValue>
</saml2:Attribute>
Now, I want to change xsi:type from string to Boolean or Integer or Duration like different data types.
Is there any possibility to do that?
I followed a few articles and they are telling to update metadata
https://wiki.shibboleth.net/confluence/display/IDP30/MetadataDrivenConfiguration
I tried updating metadata to accept boolean at least but not able to return those in assertion and not sure how to use that at attribute-filter.
Related
I can get a list of custom segments using this code:
List<CustomizationRef> getCustIdResult = client.getCustomizationId(GetCustomizationType.customSegment, true);
if (getCustIdResult == null)
return new ArrayList();
List<?> returnedRows = client.getRecords(getCustIdResult);
But that just gives me the segments names and IDs, but not the list values. How do I get the values?
Per Suite Answer 84991 using SuiteTalk SOAP Web Services you can list existing custom segments using the getCustomizationId operation. To get the custom segment values use the CustomRecordSearch operations.
Suite Answer 84991 also state: "When a custom segment is applied to either a custom record type or one of the other record types on the Application & Sourcing subtab of a custom segment, you cannot retrieve information about the field which was created from the custom segment using its script ID and customizationRef. You can only get the field information through its internal ID." So be mindful of this.
Suite Answer 65812 provides the following example of getting the values from a custom segment:
<soapenv:Body>
<search xmlns="urn:messages_2017_1.platform.webservices.netsuite.com">
<searchRecord xsi:type="ns7:CustomRecordSearchBasic" xmlns:ns7="urn:common_2017_1.platform.webservices.netsuite.com">
<ns7:recType internalId="24" scriptId="customrecord_cseg_example" type="customRecordType" xsi:type="ns8:CustomizationRef" xmlns:ns8="urn:core_2017_1.platform.webservices.netsuite.com">
<ns8:name xsi:type="xsd:string">WS Segment Example</ns8:name>
</ns7:recType>
</searchRecord>
</search>
</soapenv:Body>
I'm creating a simple Rest Api with the basic layering Controller-Service-Repository.
I have the following questions:
Where should I check if the correct parameters are given?
How should I validate thiese parameters e.g throw Response error?
You could validate your parameters on the first middleware (or after the authorization middleware). For example, in an express application you could pass your request body into a joi validation scheme.
Depends on your business logic. You can either set default values for parameters not defined by user or throw error. For example, if a user has not given any username or password parameter, then you should throw an error. All errors should be handled by the last middleware and return a relevant status code (401, 402, etc) with an information message if needed.
New Order Single(D)
Request-
FIXT.1.1:135->PSE, outgoing> (8=FIXT.1.19=14635=D34=449=SendercompId52=20191226-05:19:22.66156=TargetCompId11=157733756231838=10040=154=155=2GO59=060=20191226-13:19:22.645447=I448=135452=3453=010=253)
Response-
FIXT.1.1:135->PSE, incoming> (8=FIXT.1.19=00020535=849=SendercompId56=TargetCompId34=452=20191226-05:19:22.73537=NONE11=157733756231817=TE5368150=839=8103=9955=2GO54=138=10040=1151=014=060=20191226-05:19:22.73158=ERROR.MISSING_EXECUTINGTRADER PartyRole10=240)
ERROR.MISSING_EXECUTINGTRADER PartyRole
Kindly suggest with a proper example which gives correct response for New Order Single(D)
Kindly gives actual values related to parties
quickfix.fix50sp1.NewOrderSingle newOrderSingle = new quickfix.fix50sp1.NewOrderSingle(new ClOrdID(order.getID()),
sideToFIXSide(order.getSide()), new TransactTime(), typeToFIXType(order.getType()));
newOrderSingle.setField(new NoPartyIDs(?));
newOrderSingle.setField(new PartyRole(?));
newOrderSingle.setField(new PartyIDSource('?'));
newOrderSingle.setField(new PartyID("?"));
- List item
Fundamental part of the FIX protocol is the FIX dictionary, which is part of Rules of Engagement (RoE) between your system and the Execution Venue (aka Broker or Counterparty). It specifies what messages are part of the protocol and what fields are required on specific messages in specific scenarios, specifically, what fields are required on the New Order Single (35=D) message.
In your case, the text (tag 58) of the reject message, Execution Report (35=9|39=8) indicates that your application is not sending a mandatory tag PartyRole (452) on the request: 58=ERROR.MISSING_EXECUTINGTRADER PartyRole. But there will be more of them and you should really start from reading the Broker's ROE.
If you are just playing with FIX and coding both ends of the session yourself, check what fields are in use in the QuickFIXj Examples or in examples in my FIXGlue repository. It should get you going.
I am currently programming a REST service and a website that mostly uses this REST service.
Model:
public class User {
private String realname;
private String username;
private String emailAddress;
private String password;
private Role role;
..
}
View:
One form to update
realname
email address
username
Another form to update the role
And a third form to change the password
.
Focussing on the first view, which pattern would be a good practice?
PUT /user/{userId}
imho not because the form contains only partial data (not role, not password). So it cannot send a whole user object.
PATCH /user/{userId}
may be ok. Is a good way to implement it like:
1) read current user entity
2)
if(source.getRealname() != null) // Check if field was set (partial update)
dest.setRealname(source.getRealname());
.. for all available fields
3) save dest
POST /user/{userId}/generalInformation
as summary for realname, email, username
.
Thank you!
One problem with this approach is that user cannot nullify optional fields since code is not applying the value if (input is empty and value) is null.
This might be ok for password or other required entity field but for example if you have an optional Note field then the user cannot "clean" the field.
Also, if you are using a plain FORM you cannot use PATCH method, only GET or POST.
If you are using Ajax you might be interested in JSON Merge Patch (easier) and/or JavaScript Object Notation (JSON) Patch (most complete); for an overview of the problems that one can find in partial updates and in using PATCH see also this page.
A point is that a form can only send empty or filled value, while a JSON object property can have three states: value (update), null (set null) and no-property (ignore).
An implementation I used with success is ZJSONPATCH
Focussing on the first view, which pattern would be a good practice?
My suggestion starts from a simple idea: how would you do this as web pages in HTML?
You probably start from a page that offers a view of the user, with hyperlinks like "Update profile", "Update role", "Change password". Clicking on update profile would load an html form, maybe with a bunch of default values already filled in. The operator would make changes, then submit the form, which would send a message to an endpoint that knows how to decode the message body and update the model.
The first two steps are "safe" -- the operator isn't proposing any changes. In the last step, the operator is proposing a change, so safe methods would not be appropriate.
HTML, as a hypermedia format, is limited to two methods (GET, POST), so we might see the browser do something like
GET /user/:id
GET /forms/updateGeneralInformation?:id
POST /updates/generalInformation/:id
There are lots of different spellings you can use, depending on how to prefer to organize your resources. The browser doesn't care, because it's just following links.
You have that same flexibility in your API. The first trick in the kit should always be "can I solve this with a new resource?".
Ian S Robinson observed: specialization and innovation depend on an open set. If you restrict yourself to a closed vocabulary of HTTP methods, then the open set you need to innovate needs to lie elsewhere: the RESTful approach is to use an open set of resources.
Update of a profile really does sound like an operation that should be idempotent, so you'd like to use PUT if you can. Is there anything wrong with:
GET /user/:id/generalInformation
PUT /user/:id/generalInformation
It's a write, it's idempotent, it's a complete replacement of the generalInformation resource, so the HTTP spec is happy.
Yes, changing the current representation of multiple resources with a single request is valid HTTP. In fact, this is one of the approaches described by RFC 7231
Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource
If you don't like supporting multiple views of a resource and supporting PUT on each, you can apply the same heuristic ("add more resources") by introducing a command queue to handle changes to the underlying model.
GET /user/:id/generalInformation
PUT /changeRequests/:uuid
Up to you whether you want to represent all change requests as entries in the same collection, or having specialized collections of change requests for subsets of operations. Tomato, tomahto.
I'm trying to access a REST service from a function written in the custom code of a report. I don't want to move that code into a separate assembly so the problem is around the custom code, please don't send me to custom assemblies.
Here's the code:
Public Shared Function GetData(ByVal id As String) As String
Dim strURL As String = ("http://..." & id)
Dim webRequest As System.Net.HttpWebRequest = DirectCast(System.Net.WebRequest.Create(strURL), System.Net.HttpWebRequest)
webRequest.Method = "Get"
Dim webResponse As System.Net.HttpWebResponse = DirectCast(webRequest.GetResponse, System.Net.HttpWebResponse)
Dim rdr As New System.IO.StreamReader(webResponse.GetResponseStream)
Return rdr.ReadToEnd
End Function
When I'm using it i receive the error:
System.Security.SecurityException: Request for the permission of type 'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.CodeAccessPermission.Demand()
at System.Net.HttpWebRequest..ctor(Uri uri, ServicePoint servicePoint)
at System.Net.HttpRequestCreator.Create(Uri Uri)
at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
at System.Net.WebRequest.Create(String requestUriString)
at ReportExprHostImpl.CustomCodeProxy.GetData(String what, String id, String defaultValue)
The action that failed was:
Demand
The type of the first permission that failed was:
System.Net.WebPermission
The Zone of the assembly that failed was:
MyComputer
And I suppose that I may have future problems with System.IO too.
I had a look on CAS and I'm totally blurred, I don't know what policy file I have to change, what code group I have to change and how.
My understanding is that this is the code group used for custom code (in rssrvpolicy.config):
<CodeGroup
class="UnionCodeGroup"
version="1"
PermissionSetName="Execute"
Name="Report_Expressions_Default_Permissions"
Description="This code group grants default permissions for code in report expressions and Code element.>
<IMembershipCondition
class="StrongNameMembershipCondition"
version="1"
PublicKeyBlob="002400...CAEDDA2"
/>
</CodeGroup>
but simply setting the PermissionSetName to Fulltrust doesn't make any change.
For anyone experiencing this issue (a year and a half after the fact), if you are receiving this exception when trying to view the report from BIDS, then you need to update the RSPreviewPolicy.config file in your Visual Studio's PrivateAssemblies directory.
There are three security policy files that need to be modified for uses like this (custom code in expression or custom assemblies.) Detailed notes (including a seriously crucial one on where to place new CodeGroup elements!!) can be found on the MSDN page titled (as of today) "Using Reporting Services Security Policy Files". The security config files are the report server config (rssrvpolicy.config), the report manager config (rsmgrpolicy.config) and the report designer config (RSPreviewPolicy.config).
A great test for this is to update one at a time and test all three after each update (after deploying a report to your report server instance of course : ).
You should try PermissionSetName="FULLTRUST" in the codegroup.