Simple question:
Is following payload:
{
"aud": ["aud1", "aud2"]
}
equivalent to:?
{
"AUD": ["aud1", "aud2"]
}
According to the specification in RFC7519 claim names are case-sensitive:
Claim Name:
The name requested (e.g., "iss"). ... This name is
case sensitive. Names may not match other registered names in a
case-insensitive manner unless the Designated Experts state that
there is a compelling reason to allow an exception.
Related
I am uploading an agreement to Adobe Sign that needs password protection. Per https://secure.na1.adobesign.com/public/docs/restapi/v6 I should include
"securityOption":{
"openPassword":"0123456789"
}
The separate article https://helpx.adobe.com/sign/kb/how-to-set-open-password-for-a-signed-document-using-rest-api-adobe-sign.html says the key should be securityOptions, but even when including both in the payload it still doesn't seem to take. Here is the full payload with excessive options filled in:
{
"signatureType":"ESIGN",
"state":"IN_PROCESS",
"participantSetsInfo":[
{
"order":1,
"role":"SIGNER",
"memberInfos":[
{
"email":"xxx#xxx.xxx",
"securityOption":{
"openPassword":"XXXXXXXXXX",
"protectOpen":true
},
"securityOptions":{
"openPassword":"XXXXXXXXXX",
"protectOpen":true
}
}
]
}
],
"signatureFlow":"SENDER_SIGNATURE_NOT_REQUIRED",
"fileInfos":[
{
"transientDocumentId":"XXXXXXXXXX"
}
],
"name":"Passworded Agreement",
"securityOption":{
"openPassword":"XXXXXXXXXX",
"protectOpen":true
},
"securityOptions":{
"openPassword":"XXXXXXXXXX",
"protectOpen":true
}
}
Where am I going wrong with the field(s)?
There are a few different places for security to be applied to the document. The securityOption field at the top only protects management of the document and does not enforce a password for signers. That should be done through participantSetsInfo and the securityOption and must include authenticationMethod as 'PASSWORD'. You can drop the securityOptions fields as well as the article is incorrect and those names are not part of the specification.
Keys are stored in secret as "cosmostablekey" for cosmos table api.
Created another secret stored in key valuets as below.
{
"name": "CosmosDbSQLAPILinkedService",
"properties": {
"type": "CosmosDb",
"typeProperties": {
"connectionString": "AccountEndpoint=https://XXXXXXX.table.cosmos.azure.com:443/;Database=TablesDB",
"accountKey": {
"type": "AzureKeyVaultSecret",
"store": {
"referenceName": "ls_cosmos_key"",
"type": "LinkedServiceReference"
},
"secretName": "cosmostablekey"
}
},
"connectVia": {
"referenceName": "AutoResolveIntegrationRuntime",
"type": "IntegrationRuntimeReference"
}
}
}
when try to create linked service used authentication type as key authentication in adf and tried for test connection got below error.
Error code
9082
Details
The CosmosDb key is in a wrong format.
The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
Activity ID: f0c9c682-12de-4b53-95e9-7abe7ea722b7.
am sure copied key strig properly to key vaults.
Used for refence to connect cosmos db from adf.
microsoftdoctoconnectcosmosDB
Thanks for quick help.
Issue is got resolved
Need to call only cosmostablekey key in linked services for key athentication. More over need to specify endpoint as
https://XXXX.documents.azure.com:443/
instead of https://XXXX.table.azure.com:443/
Working fine for me now..
I am aware of that PACT expects provider data need to be in our control, but I am facing following situation
I have pact contract for multiple consumers, all have some mandatory attribute and some are optional attribute, but business logic suppress all the attribute which are having null value, but according to contract I would still be needing that value as null,
what should I do for it?
Edit 1:
i.e let's say below my contract looks
consumer sent request with below params:
{ "method": "GET", "path" : "/pathOfApi", "headers":{ "accept": "json" } }
Provider responds with below data:
{ "Status": 200,
"body" :[
{"country" : "string",
"countryId" :"string",
"postalcode": "string",
"addressLine1" :"string",
"addressLine2" : "string"
"customerName" : "string",
"customerId" : "string"
}
]
now not all customer has address line 2, now in production if addressLine 2 is null it won't be present in output of api, but for our contract field should be present with null
If your provider does not return a field, but the consumer is expecting null, then either the consumer needs to change their expectation (because it's incorrect) or the provider should update its implementation to return null values.
Just because a consumer asks for something doesn't mean you need to do it!
If in some instances the field is present and other it is not, you need to write two tests to cover each case. I'd suggest covering one case with all of the fields, and another with the minimum set of fields (see https://docs.pact.io/faq/#why-is-there-no-support-for-specifying-optional-attributes).
I am using SimpleSchema (the node-simpl-schema package) in an isomorphic way. Validation messages show up on the client as well as from meteor shell.
My question is whether or not this set up is actually secure, and if I need to also write allow/deny rules.
For example:
SimpleSchema.setDefaultMessages
messages:
en:
"missing_user": "cant create a message with no author"
MessagesSchema = new SimpleSchema({
content: {
type: String,
label: "Message",
max: 200,
},
author_id: {
type: String,
autoform:
defaultValue: ->
Meteor.userId()
custom: ->
if !Meteor.users.findOne(_id: #obj.author_id)
"missing_user"
},
room_id: {
type: String,
}
}, {tracker: Tracker})
In meteor shell I test it out and it works as intended.
> Messages.insert({content: "foo", author_id: "asd"})
/home/max/Desktop/project/meteor/two/.meteor/local/build/programs/server/packages/aldeed_collection2-core.js:501
throw error; // 440
^
Error: cant create a message with no author
Should I duplicate this validation logic in my allow/deny rules? Or can I let my allow function always return true, like I'm doing now?
I have some very simple rules that ensures the application is secure:
Do not use allow/deny rules - deny all client-side write requests.
If the client needs to write something in the database, they must do so through Meteor methods.
Ideally, the Meteor methods would call a function (which can be shared code, or server-specific code), and then check for the validity of the database modifier (using the Schema) would be done inside these functions.
Optionally, you can also create client-side methods, which would clean the object and carry out its own validation using the schema before calling the server-side method.
I am using jsonpath.com to try to use an email address as the KEY.
so my data might look like this:
"phoneNumbers": [
{
"type" : "iPhone",
"bob#gmail.com": 123456,
"number": "0123-4567-8888"
},
however, i am unable to reference the email address:
$.phoneNumbers[0]['type'] // iPhone
$.phoneNumbers[0]['number'] // 0123-4567-8888
$.phoneNumbers[0]['bob#gmail.com'] // no match
$.phoneNumbers[0]['bob\#gmail.com'] // no match
$.phoneNumbers[0]['bob\#gmail\.com'] // no match
how may i specify a jsonPath key using an email address?
The dot in .com is the problem. See this SO answer. It would seem that it should be possible to do $.phoneNumbers[0]['bob#gmail.com'], but not on jsonpath.com
The key statement in that answer:
jsonpath.com is based on an outdated version of JSONPath and is not
reliable for previewing what current libraries would provide you with.