The User-Agent Reduction origin trial is valid from Chrome version 95 to 101 according to the official documentation, but looking at the token acquisition screen, it seems to be valid up to version 111. I am currently on version 109. Is this one excluded?
https://developer.chrome.com/en/blog/user-agent-reduction-origin-trial/
https://developer.chrome.com/origintrials/#/view_trial/-7123568710593282047
Also, this one is intended to test in a situation where the user agent string and javascript api have been completely removed or changed. Is there another way to test before they are completely removed?
We would appreciate it if you could enlighten us.
I have added the necessary settings to the response headers, referring to the official documentation, but it does not work correctly.
https://developer.chrome.com/en/blog/user-agent-reduction-origin-trial/
Related
I'm using the Chrome Web Serial API. So far it's working fine, but now and I'm trying to get the (already opened) port metadata (port name, device ID, etc.) and I'm a bit lost.
Here are the steps to follow:
https://wicg.github.io/serial/#getting-serial-port-metadata
but so far I cannot get the information.
If I try by navigating the port class, the DevTools console trows "ƒ () { [native code] }".
I cannot find a suitable example of how to implement this.
Does anyone have a hint?
Thanks in advance!!
Daniel.
It seems like it hasn't been implemented in Chromium yet. Keep in mind that the specs are sort of guides for vendors to follow when implementing a feature, but the actual shipped implementation can differ.
If you check the Web Serial API's code in the Chromium repo for Chrome 80 (current version at the time of writing) and 84.0.4112.1 you'll see that they only include the following methods:
open
readable
writable
getSignals
setSignals
close
You can read the latest comments on this API here: https://bugs.chromium.org/p/chromium/issues/detail?id=884928
I have looked everywhere for an example of a QSealC signed message, and I could not find any info.
I need to verify the signature of a QsealC signed payload AND I need to sign the responding payload but I understand that the payload is all in json,
Are there examples out there of QSealC signed payloads?
thanks
You will do both the signing and validation as detailed by IETF's draft-cavage-http-signatures, where you should pay special attention to section 4.1.1 for constructing and section 2.5 for verifying the Signature header.
This draft is referenced by both Berlin Group's XS2A NextGenPSD2 Framework Implementation Guidelines and Stet (France). However, note that it's normal that each unique implementation imposes additional requirements on the HTTP Message Signing standard, e.g. by requiring specific headers to be signed or using a specially formatted keyId. I am not sure whether other standardizations such as Open Banking (UK) reference it.
Take note that you do not need actual QsealC PSD2 certificates to begin your implementation work of the neither the signing nor validation process, as you can create your own self-issued certificates, e.g. using OpenSSL, by adding the OID's found in the ASN.1 profile described in ETSI TS 119 495.
However, I strongly recommend you find a QTSP in your region and order certificates both for development and testing, and for use in production when the time comes.
I won't go into details on the actual process of creating the signature itself, as it's very well detailed in draft-cavage-http-signatures, but consider the following example;
You're requesting GET https://api.bank.eu/v1/accounts, and after processing your outgoing request you end up with the following signing string;
date: Sun, 12 May 2019 17:03:04 GMT
x-request-id: 69df69c1-76d0-4590-8f28-50449a21d0d8
psu-id: 289da2e6-5a01-430d-8075-8f7af71f6d2b
tpp-redirect-uri: https://httpbin.org/get
The resulting Signature could look something like this;
keyId=\"SN=D9EA5432EA92D254,CA=CN=Buypass Class 3 CA 3,O=Buypass AS-983163327,C=NO\",
algorithm=\"rsa-sha256\",
headers=\"date x-request-id psu-id tpp-redirect-uri\",
signature=\"base64(rsa-sha256(signing_string))\"
The above signature adheres to Berlin Group requirements as detailed in Section 12.2 in their implementation guidelines (per. v1.3), except some linebreaks added for readability, which in short are ;
the keyId must be formatted as SN={serial},CA={issuer}, but note that it seems to be up to the ASPSP to decide how the serial and issuer is formatted. However, most are likely to require the serial to be in uppercase hexadecimal representation and issuer formatting in conformance with RFC 2253 or RFC 4514.
The algorithm used must be either rsa-sha256 or rsa-sha512
The following headers must be part of the signing string if present in the request; date, digest, x-request-id, psu-id, psu-corporate-id, tpp-redirect-uri
The signature must be base-64 encoded
As developers have just begun to adopt this way of signing messages, you'll likely have you implement this yourself - but it's not too difficult if you just carefully read the above mentioned draft.
However, vendors have begun supporting the scheme, e.g. Apache CXF currently supports both signing and validation from v3.3.0 in their cxf-rt-rs-security-http-signature module as mentioned in the Apache CXF 3.3 Migration Guide. Surely, others will follow.
Validating the actual signature is easy enough, but validating the actual QsealC PSD2 certificate is a bit more cumbersome, but you'll likely have to integrate with EU's List of Trusted Lists to retrieve root- and intermediate certificates used to issued these certificates, and form a chain of trust together with e.g. Java's cacerts and Microsoft Trusted Root Certificate Program. I personally have good experiences using difi-certvalidator (Java) for the actual validation process, as it proved very easy to extend to our needs, but there are surely many other good tools and libraries out there.
You'll also need to pay special attention the certificate's organizationIdentifier (OID: 2.5.4.97) and qcStatements (OID: 1.3.6.1.5.5.7.1.3). You should check the certificate's organizationIdentifier against the Preta directory, as there might be instances where a TPP's authorization is revoked by it's NCA, but a CRL revocation hasn't yet been published by it's QTSP.
DISCLAIMER: When it comes to the whole QsealC PSD2 certificate signing and validation process, I find both Berlin Group and EBA to be very diffuse, leaving several aspects open to interpretation.
This is a rough explanation, but hopefully it give you enough to get started.
I want to check if a user has a valid license for a Windows Store application (desktop bridge). At first the StoreLicense.IsActive[1] property looked promising but the docs state:
This property is reserved for future use, and it is not intended to be used in the current release. Currently, it always returns true.
Interestingly the demo code provided by Microsoft [2] also uses this function, although I can confirm that it always returns true.
What is the proper way to check for a valid license?
Regards,
[1] https://learn.microsoft.com/de-ch/uwp/api/windows.services.store.storelicense.isactive
[2] https://learn.microsoft.com/en-us/windows/uwp/monetize/implement-a-trial-version-of-your-app
It seems like you want to check whether the user currently has a valid license to use the app, in this case, according to this section of the document Get license info for apps and add-ons:
To get license info for the current app, use the GetAppLicenseAsync method. This is an asynchronous method that returns a StoreAppLicense object that provides license info for the app, including properties that indicate whether the user currently has a valid license to use the app (IsActive) and whether the license is for a trial version (IsTrial).
So that from this document you could use StoreAppLicense.IsActive property to check for valid App licence, not StoreLicense.IsActive currently.
More details you could also reference the official sample.
I am planning to add in the message carbon function(when a user is logged into multiple device and send a message or/receive a message, it will sync between all devices) for a chat server, i am running on Ejabberd and using strophe.js...
I am wondering if there are plugin written for Ejabberd that i can install and also for strophe.js???
I looked over https://github.com/processone/ejabberd-contrib and the github for strophe.js
None of them seem to have plugins for message carbon. Wondering if anyone has this implemented before??
I have read that if it doesnt, i should treat it as a groupchat??? I am not sure why that would work??? And not exactly sure if thats good for the resources, and what if it scales up, would that have impact on the overall structure.
If it is treated as a group chat, then i assume each resource/session would be treated as a different user? Then when a message is sent into that group, all of those other session/users are updated, so even there are 2 users??
ejabberd supports message carbons as default in latest version.
This feature is unrelated to groupchat and cannot and should not be treated similarly.
If you read XEP-0280 Message Carbons you should see that sending a packet similar to the following is enough to enable it:
<iq id='enable1' type='set'>
<enable xmlns='urn:xmpp:carbons:2'/>
</iq>
You may find also valuable information in XMPP Academy video #2 at 27m30s.
I came across this code change in Chromium. It says Chromium now supports both handshake versions, which the code seems to confirm. I mean the second version at Wikipedia (draft-ietf-hybi-thewebsocketprotocol-06).
However, when I connect to my server, the only thing I obtain is the old version, i.e. including these headers:
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
but not the new version which would be a request containing:
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
What am I missing here? I downloaded the latest nightly build and it has been included more than two weeks ago, so that cannot be the cause I guess.
How can I make a WebSocket send the new handshake version?
The code link you posted is for the server-side of the handshake (there is a few places this will likely be used in Chrome such as remote debugging and as a proxy for extensions).
If you really want use the new HyBi-07 protocol version you can try using this branch of web-socket-js that I made. Once Chrome switch to the new protocol, web-socket-js will switch by default also. In order to make web-socket-js work in a browser that already has WebSockets support you will need make some minor tweaks to it to use a different object name instead of WebSocket.
I expect Chrome/WebKit will add the new protocol before long. Note that the API changes to add binary support have only recent been decided so Chrome the new protocol may be added before the API fully supports the new functionality enabled by the protocol.
The only browser I know of that implements the 07 protocol is this build of FF4:
http://www.ducksong.com/misc/websockets-builds/ws-07/