Is there a best practice in apiary blueprint to specify field length (size) / format? - apiary

If using MSON, the only way I see to currently include field length would be to include as part of the description. Are there any plans to add support for this or are there any best practices (workarounds) being used for this purpose?
as an example, in the below MSON description, how could I specify that the tokenType max length is say 20 chars? (contrived example)
## accessToken
+ tokenType: `Bearer` (string) - The type of access token that was issued. Currently only 'Bearer' tokens are supported.
+ expiresIn: `1000` (number) - How much time in seconds until the token expires.
+ accessToken: `0.AQAAAVF-mqsiAAAAAAAbd0A71bIG8IUwcgHV7mAYiG7J.EAAQsWDnpqRj7WwyFVLTsdo0yXWh9L4` (string) - The access token to pass in the API call to access the protected resource.

MSON doesn't support specifying validation options such as a maximum length at the moment. The API Blueprint team have been exploring adding these features but this is still open for discussion on the best way to support this. There could be lots of validations so it's definitely a large topic to cover so we will need to find a clear way to express validations, which offers future support for declaring so this can evolve.
There is an open discussion on https://github.com/apiaryio/mson/issues/43 on the topic. If you have any ideas or syntax proposals they would be greatly appreciated.
Currently, you can provide a custom JSON Schema which specifies your validation options. As an example, you can achieve this validation using the following API Blueprint:
+ Response 200 (application/json)
+ Attributes
+ tokenType: Bearer (fixed) - The type of access token that was issued.
+ expiresIn: 1000 (number) - How much time in seconds until the token expires.
+ accessToken: `0.AQAAAVF-mqsiAAAAAAAbd0A71bIG8IUwcgHV7mAYiG7J.EAAQsWDnpqRj7WwyFVLTsdo0yXWh9L4` (string) - The access token to pass in the API call to access the protected resource.
+ Schema
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"properties": {
"tokenType": {
"type": "string",
"enum": [
"Bearer"
]
},
"expiresIn": {
"type": "number"
},
"accessToken": {
"type": "string",
"maxLength": 20
}
},
"required": [
"tokenType"
]
}
I agree, this solution isn't great since you will need to duplicate some information in your MSON attributes and the schema itself. It would be far more idea to be able to specify the validation directly in MSON.
Just wanted to mention, you can use fixed for tokenType to indicate it has a fixed value which does not change. You could also used enum in the future to allow for multiple tokenType options.

Related

Generate itemId when batchUpdating with Forms API

Please what are the constraints in generating an itemId. I generate unique itemId for each item in the form, but the API keeps telling me invalid ID.
https://developers.google.com/forms/api/reference/rest/v1/forms#Item
Please I need help with this
{
"includeFormInResponse": false,
"requests": [
{
"createItem": {
"item": {
"itemId": "4e637fjc",
"description": "First Name",
"questionItem": {
"question": {
"textQuestion": {
"paragraph": false
},
"required": true
}
}
},
"location": {
"index": 0
}
}
},
{
"createItem": {
"item": {
"itemId": "njyf3izr",
"description": "Middle Name",
"questionItem": {
"question": {
"textQuestion": {
"paragraph": false
},
"required": true
}
}
},
"location": {
"index": 1
}
}
},
}
]
When I had tested Google Forms API before, unless I'm mistaken, I had thought that the rule of item ID might be required to be 00000000 to 7fffffff as the hex value. By the way, for example, 0 is used as 00000000.
When I saw your showing request body, you are trying to use 4e637fjc and njyf3izr as the item ID. In the case of these values, the values are not hex values. I thought that by this, an error like Invalid ID occurred.
But, I think that actually, this is not published in the official document. So, I would like to tell this.
Added:
About your following reply,
Do you mean something like this, with Javascript. crypto.randomBytes(256).toString('hex').slice(0, 8)
From your tag, when you want to use Google Apps Script or Node.js, how about the following sample script? Unfortunately, Google Apps Script cannot directly use "crypto". So, I proposed the following sample script.
Sample script:
const res = Math.floor(Math.random() * parseInt("7FFFFFFF", 16)).toString(16).padStart(8, "0");
console.log(res);
In this sample script, the values of 00000000 to 7fffffff are randomly returned.
Missing documentation
I am afraid that since the Forms API is very new there is no documentation about the specific format the ID should have.
I have done a couple of tests with the API and the only thing I was able to figure out is that the ID needs an 8-character-long string to work, otherwise it would not work or would fill out the blank spaces with zeros.
When doing the testing I was also able to find out that sometimes the API would take a specific pattern of letters and numbers, but when changing the numbers and letters it stops working for no reason.
This seems like missing clarification from the documentation, and I would strongly recommend sending feedback about this problem on the API method page. You can do so by clicking the following option at the top right corner of the documentation:
Google tends to check that feedback a lot when talking about missing information. In addition to all that you can also fill out a report in Google's issue tracker so that they investigate the inconsistencies when using the batchUpdate method to update the ID.
References:
Forms Item
Method: forms.batchUpdate

npm jsonwebtoken module generates token with length 10 000

I am using jsonwebtoken v8.5.1 for generating the accessToken for my API.
The exact way I am using it is as follows:
const accessToken = user => {
if(user.iat)delete user.iat;
return jwt.sign(user, config.ACCESS_TOKEN, { expiresIn: '10s' });
}
//user objects has the following structure
{
"_id": {
"$oid": "5f1750046e069f2e6c5b5353"
},
"username": "Hristo",
"firstName": "Hristo",
"thirdName": "Hristo",
"startDate": "2020-07-21T20:28:35.224Z",
"job": "Hristo",
"secondName": "",
"showPassword": true,
"image": "https://placehold.it/208x208"
}
and the config.ACCESS_TOKEN is 64 bit hex string.
The lenght of the string which jwt.sign() returns is 10363 which is giving me the HTTP error:
431 Request Header Fields Too Large
when I try to make a request with header "Authorization":accessToken.
Any ideas what I am getting wrong?
NOTE: the experation time is `10s` for testing purposes.
The generated accessToken:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJfaWQiOiI1ZjE3NGY4M2MyMzA3ZTE1NjQ0ZDRmMTgiLCJ1c2VybmFtZSI6IkljbyIsImZpcnN0TmFtZSI6IkljbyIsInRoaXJkTmFtZSI6IkljbyIsInN0YXJ0RGF0ZSI6IjIwMjAtMDctMjFUMjA6MjY6MjYuMDU2WiIsImpvYiI6IkljbyIsInNlY29uZE5hbWUiOiIiLCJzaG93UGFzc3dvcmQiOmZhbHNlLCJpbWFnZSI6ImRhdGE6aW1hZ2UvanBlZztiYXNlNjQsLzlqLzRBQVFTa1pKUmdBQkFRQUFBUUFCQUFELzJ3Q0VBQWtHQnhBUUR3OFBFQkFQRUE4UER3OFBEeEFQRUE4UUVBNFBGUkVXRmhVVkZSVVlIU2dnR0JvbEd4VVZJVEVoSlNrckxpNHVGeDh6T0RNc055Z3RMaTBCQ2dvS0RnME9GeEFRR2kwZUhSOHZLeTByS3k0ckxTMHJMUzB0TFMwdExTc3VMUzB0S3kwckxTOHJMU3N2TFNzdUt5MHJMU3NyTFNzdEt5c3JLeXd6TGYvQUFCRUlBTGNCRXdNQklnQUNFUUVERVFIL3hBQWNBQUFCQlFFQkFRQUFBQUFBQUFBQUFBQUFBUUlEQkFVR0J3ai94QUJHRUFBQkF3TUJCQWNGQlFZRUF3a0FBQUFCQUFJREJCRVNJUVV4UVZFR0V5SmhjWUdoQnhReWtiRkNVcExCMFdKeWdyTGg4Qll6VTJNamMrSVZKQ1ZFZzVPaXd2SC94QUFYQVFFQkFRRUFBQUFBQUFBQUFBQUFBQUFBQVFJRC84UUFKeEVCQUFJQkFnUUZCUUFBQUFBQUFBQUFBQUVSQWhJaFFWR2gwUk14VW1Id0F5SkNjYkgvMmdBTUF3RUFBaEVERVFBL0FLS1VJQ1ZBSlVKUWdFcUVJQkNFcUFRbFFnRUpVV1FJaExaTFpBMUNkWkZrRFVKMWtXUU5RbldSWkEyeUxKMWtXUU5za3NuMlJaQXl5TEoxa1dRTlNXVHJJc2daWkNkWkZrREVpZlpKWkF3cEUreVN5QnFFdGtxQUNVSlFFdGtDSlV0a3RrQ1dSWk9zaXlCTEpiSmJKYklHMlMyVHJKYklHV1MyVDdKY1VETElzbjRwUTFCSFpGbExpakZCSFpGbExpakZCRlpGbExpakZCRlpGbExpakZCRlpGbExpakZCRFpGbExpakZCRFpGbExpa3hRUldTV1V1S1RGQkZaSlpTbHFRdFFSV1NXVXVLUXRRUldRcE1VSUZEVXVLbERFNE1RUllwY1ZMZ25CaUNIRkdLbkRFb1lnZ3hTNHFjTVM0SUljVVlxY01TNElJTUV1Q253U2hpQ0FNVHNGT0dKUXhCQmdqQldNRXVDQ3ZnbHdWakJMZ2dyWUl3Vm5CR0NDdGdqQldjRW1DQ3RnakJXY0VtQ0N0Z2t3Vm5CSmdncjRKTUZZTEVtQ0N2Z2t3VmpCSmdncjRwdUNzbGlRc1FWc1VtS3M0Sk1FRmJCQ3NZSVFPREVvWXJBWW5ZSUs0WWx3VmpCTGdncmhpVU1WakJMZ2dyNEoyQ253UzRJSU1FdUNud1M0SUlNRXVDbndTNElJQXhPd1V3WWxEVUVJWWx3VTRha2tjMW91NXpXam00Z0QxUVJZSmNGRkp0R0VmYUx2K1d5U1grUUZWSmR2UnQzUTFidjhBMEh0SC93QXJJTkRCR0N3cE9sVFIvd0NYbS9pTFcvcW9UMHYvQU5nZWN2OEEwb09pd1JndWIveGgvc3MvOTcvcFNqcGt6akcwZUVvL1JCMFdDVEJWTmliV2JWa2hqV3NhRFl2a2xpYTNMZllhM2NkZUFLNk1iRmtJdURHN3djZjBRWTJDVEJhYzJ5cG02bU54SE50bmZSVXkxQlhMRW1Dc1lwTVVGY3NTWUt4aWt4UVY4RW1Dc1lKTUVGZkJOd1ZuQkpnZ3I0SkZZd1FnbERFdUNteFM0b0ljRW9hcGJKY1VFV0tYRlM0b3NnanhSaXBiSXNnanhTNHFTeUxJSThVdUtmWkZrRGNVamlBTGtnRG1kRkRWVnpHSEQ0NUxYd2I5a2MzdTNOSHJ5QjNMUGR0QTVkbnR5RGM3YzJQaDJSdzhkNThORUd2aVRxNTNWTTd3REs3d2FkR2Z4WFA3S1UxekkvOEFLWTF2N2J1MUk3K0k2L2x5V0s2YzczSEozb1BCUXZtSlJtMWphVmJOSmNDWWorSCtxNHphTTBna2MxMGpuRWFieU9DNlZ6MXlPMnEvckpEWTlsblpiMzh6OC9vRUVENWU5Uk9tUE5ST2Z1OWU4M1VaS0t2MGtZa05qSmllQUl2Znp1ckZYUUNOaGU2VFFmczd6ODFobDZrbXFaSmpIRUNYRzRBNStDQzFUUDBNaEdqZXpHTy8rbS94S2RUeUZycmd1YnJxV0d6dm1pZHpiTmpacUdhWDRPL2E4emZYbFpTeFF0QXU1NUhneHhBOFRvaXVpcE5wVjhHc05aUHpBZTh5TjhnKzQ5RnEwbnRHZmNOcnFXT2R1N3JJaDFVemZ5UGgyVnpkTStLVEZySkE1elc5b05lNjUzQytKMUg5VkxVN0tKWVhXNGcrdXZvU2lQUk5uUzBsYUNhS2NPa0F5ZFRUMmpuYU9OcjZPSGVOTzlSeVF1YVMxd0lJM2dpeEM4Lzl6ZEgxVXNiakhMRVE1andSZGp4dUk3aU40M0VFamNWNkZERFQ3Y28yT2xhWTZtQitEaXdrR0tVV0pBKy9FNEVFQTgrQkNLaUxFMTlocVNBTzgyVDV0aXNaZTlOR0FEYS9Vc3RmeHNzdmJPd281NHNHQ09KN1hCekh0amJvUmNXTnJHeEIraUM5SEkxMThYTmRiZmlRYmVOay9GWXZSV2htaEU3Wm00bk5yV2tFRVBhQWUwTGNOZUszcklJY1VZcVd5U3lDTEZDbHNoQkpaRmtxRUFoQ0VBaXlFb0cvZG9Ma25RQUlCQ3RiUG9YemF0QkROTE9JUGFITm9POGQrN3ZXN1Q3SmhaOFF6ZHlPdno0SU9aWXd1Tm1nazhnQ1NrbTdCeGRjTys0QVRKK0FkcjBYYUJvSXgwWTM3ck96ZnhLZkYxY1lzeGpXK0FRY3ZRN0lsbEZ3QzBmN2pKV2Z6TkN2L3dDRnlRUVpzVHphMEVqNTZMYmRWSm5Ya29PWlowQWdBSWRWVmJ5NTJUbnVNQWM0OStNWS92VGRvcEc5Q0tab3MyU28vRkY4ejJGdnVxQjN1UGR1V2RYYk1aT1NaOG5NT25WdmtkMVFIZXdFTmQvRUNnNWJhTkJzaUYvVnk3VUVVbTdEM2lrTHdlOFlHM21wWU9obExPQzZIYU5XOXU0bU9YWjVBUGxFdWlwYUtsZ0FiRkZHd0RjMktOa2JSOGdGYmJXSDdMQUxjVHdVUnlSOWx6SFhQdjhBdEhYZ1pLVzNwRXFqL1kvQ04xVFA1aUUvUUJkaFB0dU5wQWtxNFdFbXdhSHRMaWVRQTFUelgwK0xudmxlMWpSY3ZsYStPUDhBRSt3VlY1OVUreVpvK0d0Y1Azb1dPK2tnV2RMN0xKT0ZiR2ZHRnpmbzhyc0s3cDVzcU1rTm1kS1IvcE1MbTMvZk5tK3EwZGc3VnBhNXBkQzY1YWJQamtGcElqKzAwN3ZFYUZRZVhTZXpHck44SjZWd3ZvWE9tYmtPWXN3OS93QWxGRDdQYStFU1B5cFM5emNJM05sa3N5L3hIVmcxeHVCM2xlenlNWURZbTNsb2xxcU5wYlp4c0xqWFJCODg3ZDJMUFN3NXl1aUJ1QU1IT0pQaDJRcHVqZlFTczJsQjd6R0krcXpjeGhtbmV4eExkNUF3ZGR0OU9Hb0s5anJ1ajFGTUN5cERab3o5Z1pBNWNDSE4xYVJ6QlYvWnpxZWxoanA2ZUl0aWliaXhwY2RCZSs4M0oxSk56elZJbW5BZER2WlhKQStTU3NuYUNXaGtiYVE1R3hOM0Z6bnMwM0RRQmR2RjBScFFMT0UwZzNIT1o0QjhReXdXai8yaTQ3bXRIcWozbDU0bjZJWFpLZllWSkhyN3RFYmNYdERyZWJyclVpbFl3V1kxalJ5YUFCNkxKZTIrL1hqdyt1OVNzT2dVR2crb2Fia3RGenZJRmlmUGVxOHJnN1FnRnZKd0Q5UEVwaldtMStDektqYmxNeVZzTHBvaEs3NFl6SXdTTy9kWVRjb0lOclViV0hOZ3MwbXhidkRUM2R5elYwZGU1aHAzdUpHTnREemR3dDVybkxxZ1NJUWdTeVZJbFFMa2pKUTVJTGtFMlNNbFdNaXZiSW9YMUR5R2tCcmJGN2lkUUNlQTQ4VUZPcHFTQzFrYlRKSyt3WXdkNXRkeDRCZGJTN01qYkhFSkdBdmEwRjUzaDBsaGNrYmpydTVMbjlvMUZQc1l6VmRWTjFqSEUrN1JCcmV2bGtJMVlCeWFMREs0Rm5hMk9wNFNUMjAxRGpsN2pEaTV6c1IxNzcyRnRMNDhBUXFQYUhUMjBBUHByNnFJejl4OVAxWGtUUGJISjlyWnpmS3FJUE8xakh2VzFON1VXUlF4enkwYnd5WEFNNnVkanlTNEUyMWFCY1ltK3ZKUWVnbWJ1UDRTanJmSDhMdjBYQVVQdGJwSlhZQ2tyY3JFNmU3YmgzdWtDMUdlMDNab2UyT1gzaUJ6ckgvaXc5bG9KSGFMbWtnRFhVb09wNjBjeDh3cEJydkk4QnFma3JUV2plUG1GRk9HVzdRQjVBZ0ZCR1hFYU5GdlVyT2ZVaHhjR1pTdWJjTzZ1eERDTjRjOGtNYWU0a0h1WERkSmVtdlZ1ZEdXdUJ6bVlLZDBuWVlJNVhSbDB1dVR5UTBQd05tWXlNTm4zdU9RbjZaU1NtWHJ5MWtiV05NWmxjSEZqeGpwQzBBWWtqSzRIWjE0YUZXdWFQVmFtcW4xdExzK21IT1dvWk04Znd0MFdjelpncUpReVd1ZlVPeEVoWkV5UnpReStodVdpT08vQTd6WTJCc3VCNkxVTW0wWE9wbUdjMDJSbE1qaVd4eFhHT1gzWHZzTkxjdGRMcjB5UHFxU050TlRzTFdOM25RdWtkeGM1MjhsTGlDbHlucHFlbi95bzJCOWlPc3hhWDY4M2tYZDlOTndYTGJlNkpOcWlaWnF5ZHhIdzlhR3lBZHpXakVEeUN2VkcwUzBQY1dPT0FKK09CcGZwZXpRNTkzZVFYRmRLdW1FOHNqcUttWVkzOWxycFE0NU1EZ0Rab0xSWnhCMzhPSEFyTzhxdVRuWTFBY1pURTZRYUhyVEpOTHJ6WXpSbzhsZDZOUzdNa3FJNmlqZjFiNHI1TnBwSHN5ak85cjRwTG5EdUdLNEQzV2tpQkR2K0xKWWw3bkd6Y3VPL1VsVTlvYk82ckdxcFNZM3NBa2FHUEJ1Mzd6Q1BVZUlWb2ZTQWZjWEJ1SEM0Ty96V05IRzg5cWFjWk5jN3NCMTlRNDJ2Zlhrc0wyZDlLL2VxWUY0N2JTV3lOSDJaQUxranVjTEg1clYydkswdURtM0hXTkljRHAyZ05QbVA1VkJyZFpEeGsrUWQraVBlb0J4Y2ZCdjZybmV1MENPdFFkR05vUmNHdTg4UithZTNhVFB1SDVoYzQyUlNzbFVzZEg3OHdqNFRyM2hTdHJXY2o4bHp6SlZPSlVzTDAzNlJlNjBUM3hFR1Y1YkZFRHVNcmpadHh5SHhIdWFWNGZWVWxOTm1IT0xxbDJUblR2bEprZkp2SngzRWE3dDl1UzZyMm9iUUpscFliNk1iTE83eDBZMC9MckZ3SmpMUUpBTjRjOXBkY2RxeElBNW5RK1Z1YTFBOU82SWJma3FhRU1tYzUwMU05MEVtUnZjamM3dkpCQUo0a0ZkTEUrN1dubTBIMFhsblJmYVRJWDFWenBJeUY3V2plNXd6QnQ1QUwwYlo4K1VNTHQyVVVicmNyc0JRWDdwTHFIckVkWWdtdWhROVlsUVFkY2tNcW9kY2pya0YweUxRMlJVWVp5QjJMbUFFRUhjTmIrU3d1dVdidE9wWTE5ekpKSEtJWENQRFZrdDNBUGplMjI0alVHK2hiOGc1emFlMG9xK29kVTFra2hkSmZxMjZHT09MSTR0YUI4UG1OK3ZGUDhBZEtCOFppT1pBZDFrVXNMNFd5UlBOZzdSeEF0WnJlZS91QlhHTXErWVBaMC92NUtadGF6aVNQSW9PbC83QmdQd1Z0UXovbVUwY3ZxeDZkVTdHTDJOamZ0SXZZMGd0YkpRMUlEU0FRTEd4NEU4VnpRcW1IN1EraWtaVWE2TytUa0dqVmJDYzNIQ2VDY0UyTFk0cG1QYUxmdGdOQTh3b0g3Q2t0MjNSeHQzOVdIRFh2SiswVkdLbDNCN3IvdkZWNVpISDdUdm1WQjd2N0pkdm1Xak5KSzhPbG84V3NkZTVmVEg0TDk3YkZ2aGl1eGROR1QybnRBNVh1VDVCZUIreTZvTE5vTzRDV21tWllhQWtGangvSVY2M1NiU2liZnJKSTJXL3dCUjdHL1VvTktyaTJhWG1WOU5ETEtRQVpEU05mSTRBV0YzdWJjMjhWWGsyMUJGL2xVYzJtN0NPQ0llaFZLbzZVYlBidnJhWCtHYU4zOHBLeHEzcHZzMFgvNzAwL3VzbWQ5R29MVmYwNGtEckNpdHd5a3FDVGJ3RGZ6VVRkdnl2MTZ1QmwrVE1qODNFcmxxamJNRlU0dWdrekRiWEJhNXBGOXhzNEFxOVRQMFFhRzF0c3VqZ2xsa2Rkc2JIUExRR3REckM0R2x0NXNGNVRzK1Y1RWt4dTZhVXVjNGcyT3VyeUR3NWQyaTZuMmdWV05HR2Y2MHpHbndiZC8xYUZ6bXpaR01wNmd1STZ3VStOT0xFa3l1ZGMyNzdBZk5TWjB4YXhGczNhTVFMZzlwSnpEM0c1dWZoSlB5c1V1ejVPcngwSUR5QnFiMmZqK2VuejdsTEVjR2t5dGMzTE5sOVdsc2NoR1RyRUhYWGp3ZWU1Vko3aHpyWXNZSHRMZFNjUTI5anpjVGU1UE5iUjAzczhxT28yaE5DUGdsWUh0SGUwZ2owYzRlUzlNcW5YYWViVGtQTGY2WEhtdkpPanIvQVB4S2tjTnpvNWdmSnN2OUY2b0pGbVJHdzZEd0gwVHhma1YwTkJVMElpWVhrTmUwQnJtbHJpYmdXMHNOeVdUYnRHejRJblA4ckQxUDVJTUprYnp1YTc1RlRzcHBmdUZXYW5wZTFndUlvSXh6a0lQNkxGclBhRzF1K29hTzZGZy9tQS9OU2hydHBwT0xTRTJTVEhRa2VSdXVSbTZlUnYzWnVQT1Y0YjZhbjBVTHVrMlF2bEUwZnh1UDVmUktIT2RQNThxOTV0a0dVOExDTFgweUxqcC9FdWRxTWp2YUNBWGxvY0RvQ2I2QTk2MDlxMUptcTVYWkFtU051SnRZWERMQWVpejN4U0VOMGRrTGI3NmJyalhnTlBEeldvQzBCYzU1TnUwWXVBdHZMaHVDOVcyUFVCMEVWdEMxakdPSDNYTmFBUXVRMkRzSXRJbWtMUUhzYlpvdm1OWEVpKzRiK0hMZ3VwaWtEUUd0QUFHNERRQkYycHA1b3pXZjd3bDk0UkYvTkNvZThKVUVHU0xxUEpHYUNXNjU3cEpNT3RpR3VRRHI4ckhVSDBQb3QwT1hLOUlObVRaT2tqemNYT3lEbVh6YWVSdHc0SXNSZms0c1JISWdnalV1MTVjRkhNTGFMWHFObFR0dTUrVnphN3VxbSt1T2lxc2pqQjFleS9lSFgraWpVNFRleWsxb1A5LzMvZkJQd1dxSW1uN2NKNVhleHY4QU5aUE96amE0anlITmxuaTM4Tndsd2VIbnlZeGJ4VTBMYmtBN2lSNjZmbndWdDlLM2tSNW02aGRFQmUxNytQRlZtTnBhL1FkNWoyclRDNXNUSzM4VUVqZnpYV2RMWkFRN1FFcms5a0ZqYXVsbkx3TUpZM1NiK3lDYlAxQXNkQ1Z0ZElLK09UTEY3WGFjRHZXWTNkZnJZUmpsOXN4TVQ1TTdadGJSUnNJcWFHU3Brekp6YlZHbmFHWTJEY0d0TzQ2M3YvV3k3YnV6UURqc2FJWERnT3NyYXQ5aVdnRGNSZXhCUG53WE5QYzc3Z0hpNEtJNWZjYitKcTNiaTZUWjIwSTVheHo0cWVLbVk2SzNWUXVlNW9zVzYzY2JrNkg1cnM2ZDJpODM2T3ZJcVdYc0xodzBJNVg0ZUM2amF1MitxYmhHUVpEdk84TUg2ck1pcjdRNWRLVm5NeXUrV0EvK3hXYlQ0bWpxMmt0RHNZSE1MdDVJZnFCNUFxbnRtZVNSclh5T0xpSDJCTnRBUWRCOGdwOW1Caml3dUFjTEVXTzYrOEUrR3A4Z3M1WTZvcjlmMVltbFp6WHlReHRPb2pkWjNhMVlYM0xRUWRTYk4wSGNRcUVzV1FMbUV1R2x4eEd2MDNLL3RPb2FaSHVhUmc1OGJlenBlelQyaDRYOVFvWUlEMXBJK3kwT0pIM3BHNk45VDVBcmFOTG8vTXlPcmdkSTROYXlua2RjODNPY0I2RmRyL2lhRGMwbDNvRjVpK1puV3VMbkV0Rm1ERUc5bWdEVDVLMjNhOGJQZ2lKNzN1VWFqSDNkalc5SUpTVDFWckhrd2x3ODdrZWl4NTlvVlQ5OHJ3UDJYVytZWitpd1p0dVRPMEdEUndzMjl2eFhWWjlSSy80blBkNGsyK1NGWXh4K2ZQWnJ5TkY3dmsxNDZnRS9VK2lhMldGdjJjdkcvd0Nlbm9zdGtidVNuWlRPNXFseHlhUTJpQjhNY1E3OEFUK2lwVnUwSlBza0FIZ0dDLzBUbVU5dWFmN3VDZFFocm5nelJVUExnNDVGdzQySzZYWjFhSmV5NXJHdmNBMTBqbWhzam1qN09YRUtnSUJ5VXJXMjRJeTdPTnhBQXZ1NEtRT1hQVSswbml3TmpZRGZlNjJLZVVsb0pBRjlkT1NDem1reVRNa1pJSk1rS1BKSWdma2tMMDI2YVNnazZ4UlMxSkhCQ3BWTlhZbG9icU9lNUFTN1NjTzVabTBOcGRrbHdEaDNnSDZwMDByM2ZkSGtxbGZIazBYQUZ0OXVKUWM3VlRCemljV3QvZGFBUFJWOHRiOFZxU1VJVURxRkJDM2FFZzBMaVJ5Y1M0ZXFkNzJEOFRiZDdkUFJCb2ltR2xkeVNtL0V5NDdndGlkYzVrSGs1aFBxRWdoaS93QlFmaGYraWFZSGNpbTlVZVNocmoweDE3cGhERDk4ZmhmK2ltRDR1TCtBSHd1M0R5VlBxenlLVHF6eVExUjZZNjkyakRVUk1PUWNjaHVObkJPaXJZUWJ2TWp1NWpSOVhGWndpUElwemFZbmdVb2pPSS9HT3ZkcjF1MW9Yd3VpWkNXa2xwRDN5QXViWTMwQUZ2OEE5VmFocU1kTDIzV3R2QnZvVldiUUh2Q25qb1Q5NCtpc2JNNVpYTFVNTUx3TGgwWnVTVEhqcVNOU0FSMmIyRjdmSUtIYUU0YTBNWm9iV0E0dEZyWk9QRTIvc0prY0JBK0ozei9SUEZNRlVaREtNcWRsQ3ROa1BjcFd3cURPWlJqa3AyVTQ1SzhJazlzSjRCQlViQXBXd3E0Mm5QRlN0cGg0b0tJakNrYkNlU3ZpSURnbkJpRExsWlk2OGttS3UxRVd2a0V4c0tCc0VSUG90K0lXYTN3Q3pxV0t5MDI3a0NwVWlFQ3BVeEtnYmRGMDFDQlZSMmlOMWhyelY1VjZrWHNneDNncU56Q3I3bzlVMHhJTTB4SnZVclRNU1RxZTVCbWRTazZsYVpnU2RRZ3plcFIxUGN0THFPNUhVZHlETTZqdVIxSGN0UHFPNUhVZHlETkVIY25DRmFUYWU2Zjd0YmdneStwVG13clNkQWdRSU04eEp6STFmNmhIVUlLY2NIYXNyTGFWV0lvdFFyQVlncXNnSEpTQ0pUNEpjRUVBWWx3VStLV3lDQVJwMkNsc2xzZ3JTUnBvaVZvaEpaQWtUTEt3bU1DZWdFSVFnRUl1aEF4Q0VJRlVVd1FoQldMVVlvUWdNVVlwVUlEQkFZaENCUXpWUExVSVFOREVvalFoQTlrZXFmZ2xRZ2E2TUpNRUlRSVdKTUVJUVBZMVBzaENBc2xTSVFDRWlFQWhDRUNYU1hTb1FQYW5YUWhBWFNYUWhBWFNJUWcvLzlrPSIsImlhdCI6MTU5NTU5MzU5NSwiZXhwIjoxNTk1NTkzNjA1fQ.FaHXkhO5-dBg92ZqEceruboiMFGHZ5pQanwf6bt1VG8
You added the whole user object to the token. The user object contains an image property with a URL, which seems to be resolved into a base64 representation of the image in the token.
The resulting payload contains:
"image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD...
That's what blows up you token.
You can inspect your token on https://jwt.io
Generally try to limit the contents of the token to the minimal necessary data that you need to identify the user. Just the ID of the user plus expiration time for a start and then build up from there (issuer, audience, roles etc.
You might also find this introduction useful.

Self-defined Function while creating a Digital twin?

It is possible to add a self-defined function while creating a digital Twin in Ditto as shown below.
"attributes": {
"location": "Germany"
},
"features": {
"temperature": {
"properties": {
"value": 100
}
},
"humidity": {
"properties": {
"value": 100
}
}
},
"BuiltinFuntion": {
if(Temparature > 20){
alert("Some message")
}
}
Note: One solution is to constantly check with Ditto HTTP APIs value and give alert message whenever it cross the threshold value. But I do not want to hit the APIs everytime. So please let me know if there is any alternate solution.
In order not to poll Ditto's API for changes, there are various other APIs supporting push-notifications.
For example, you can use the WebSocket API and use an filter expression defining filter=gt(features/temperature/properties/value,20) when subscribing for events.
Or you can use the SSE (Server Sent Events) API to do the same.
Both, the WebSocket and SSE API may directly be used in the browser - I suppose your alert you want to show is JavaScript, so I assumed your target environment for receiving push notifications is a browser.

Cannot change workitem's parent through the azure devops api

I'm trying to programatically change a workitem's parent using the azure devops api but it's not working as expected.
I tried using update link endpoint and also remove link endpoint but none of them seem to be the correct one given that there is no way I can get a relation ID for the parent-child relationship to use in the request path.
The "relation ID" to send in path: is just the index of the relation being changed or removed in the WorkItemRelation[] on the Work Item being PATCHed.
Use the $expand=Relations argument in the query string of the GET operation for the work item whose parentage you want to change (Get Work Item).
https://dev.azure.com/{YOUR_ORG}/{YOUR_PROJ}/_apis/wit/workitems/{Child_ID}?$expand=Relations&api-version=5.0-preview.2
note: I'm not exactly sure, but I think the {YOUR_PROJ} value can be omitted.
With the resulting workitem object, get the index of the relation where the relation type is Hierarchy-Reverse, and use this as the leaf of the "path": "/relations/{index}" property sent in the PATCH body with op: "remove".
Get response (abbreviated):
{
"rel": "System.LinkTypes.Hierarchy-Reverse",
"url": "https://dev.azure.com/{YOUR_ORG}/_apis/wit/workItems/{Parent_ID}",
"attributes": {
"isLocked": false
}
}
Patch request (body):
[
{
"op": "test",
"path": "/rev",
"value": 1
},
{
"op": "remove",
"path": "/relations/0"
}
]
The examples in the documentation tend to perform a test on the revision of the work item before executing the remove or add operation. This isn't necessary, but it's probably a good idea.

Is Apple Pay token transactionId globally unique?

I'm investigating a possibility to use Apple Pay transactionId in defence for replay attacks across the same payment gate. The defence should rely on a field that participates in the signature and is unique.
But Payment Token Format Reference describes paymentData.header.transactionId as
Transaction identifier, generated on the device.
which is not enough to treat it as globally unique.
Here is a test example of ApplePayJS token:
{
"paymentData": {
"version": "EC_v1",
"data": "...",
"signature": "...",
"header": {
"ephemeralPublicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE6jY12R9PoL7bzaC3/ibs6q6+g/cqjSkiO3GVFld2NVUA6kRlq0iJRT+XzfmGFvRs/G2qwgmWY8fKu7p6Ktgxug==",
"publicKeyHash": "AJiEM3d+czut7s1t4QdtRBPjSOxw0D6iWSp1MUdXueM=",
"transactionId": "f8f0c804922303decba1a8a4f7c503df1a6314e44e8db5ae7eb6b7fe0323513b"
}
},
"paymentMethod": {
"displayName": "MasterCard 1471",
"network": "MasterCard",
"type": "debit"
},
"transactionIdentifier": "F8F0C804922303DECBA1A8A4F7C503DF1A6314E44E8DB5AE7EB6B7FE0323513B"
}
In practice it always has the top level transactionIdentifier field matching case-insensitive the nested paymentData.header.transactionId.
And the docs say:
transactionIdentifier
A unique identifier for this payment.
This identifier is suitable for use in a receipt.
Google search also finds How do I process returns with Apple Pay:
In Japan, you can also use the transaction ID on the receipt to find the purchase and process the return.
Also transactionId is 64 hex chars or 32 full bytes long. Which is longer than Unique Transaction Identifier format. So there is enough room for being truly globally unique.
Still looking for more direct credible proofs.

Resources