New API Proposal - Consent URL API

What type of PR is this?
New API Proposal
What this PR does / why we need it:
API for retrieving a Consent Capture URL (name TBC), improving the integration and experience of developers and users in this process.
Which issue(s) this PR fixes:

Fixes #68

Apologies - didn't mean to approve just yet. Still reviewing.

Why isnt't the developer starting the authorization code flow or CIBA flow with the needed scopes and purpose at user-onboarding time?
The authorization server then redirects to the telco's authentication and consent collection page, thus achieving the same effect as this API?
There is no need to actually use the the access token to call the API during end-user onboarding time.
If the access token is not valid anymore when the API call is made, then the developer can use the refresh token to retrieve a valid access token.
Why do we need this proposed API, when developers can use the above procedure?

Hi @AxelNennker,
In fact, the proposal is focused on solving that gap, that current auth mechanisms do not allow a developer to launch a consent with the user (unless in a front-end flow, which relies on the proper OGW device been involved).
The issue with that approach is that you always need to count on a flow where the user's terminal is involved, it is, front-end flow (authcode), while CIBA "only" triggers a mechanism in which the telco is in charge of reaching the user with its own channels, no so adaptative to the developer's use cases. This is a proposal for standardizing a mechanism that solves the gap in CIBA, for cases where the developer is the one who knows where and when to show the consent capture process (while operator gets still in charge of the how and the control).
So there is no other standard approach to provide a webview to the developer that can be shown to a final user, and it doesn't cover scenarios like:

Pure backend services where no user device is involved, it is, no possibility for a frontend flow. There are a lot of antifraud use cases that do not require a pure user action to be executed, therefore we cannot count on the user been on a device APP.
Services that are executed over a device which has no user interaction possibilities.
Consent capture campaigns without frontend flows.

Maybe... I don't read what you wrote in your comment from the API summary.
Please rephrase.
Also, I, personally would never enter my login credentials into some device when there is no user-device.
I do not see how your use cases can work e.g. "over a device which has no user interaction possibilities". CIBA was invented for use case like a gas pump at a gas station, but there somehow the gas pump and your authentication device have to communicate over the telco provider.
Maybe add use cases? I do not see it.
For consent the telco has to authenticate the user and then collect consent. How can the authentication work if there is no device with user interaction?
I think I am missing something. Please explain

Hi Axel,
Maybe I didn't explain properly in the last comment, since I think I cannot disagree with what you are saying.
Those scenarios that I mentioned before are those that this API is intended to solve, by enabling the developer to request for a consent capture API from a backend that then can be shown to the end user in a valid channel, of course the OGW device may not be valid in those cases.
If the device is not accessible or do not accept human interaction (as you said, a gas pump or a smart tag), or the device is not able to be used in the moment when the consent wants to be captured, or there is no app to be executed in the device... or simply because the developer identifies a better experience to capture the consent, the API allows the developer to ask for a URL that later can be exposed in a webview in any device, computer, other smartphone... where the user can indeed authenticate with the carrier credentials and provide a clear consent acceptance.
The API is to be triggered from the backend of the developer, and the result (the URL) will be then shared to the user in the channel that developer considers as the best one to reach the user.
Let me know if it's clear now and we'll rephrase the API template if required.

I assume this is then a client credentials based only API?
Does the URL depend on the API's input parameters? client_id, technical-scopes, purpose
Or this the result URL fixed?
If it is fixed then the URL could be a field in the openid-configuration.
e.g. add a new field to https://mobileconnect.telekom.de/.well-known/openid-configuration
consent_url: https://AZ/consent-url

Some openid providers split the user-authentication and consent collection from the "core" openid/oauth2 token handling.
https://connect2id.com/products/server/user-authentication

The Connect2id server doesn't deal with user credentials directly. Instead, it delegates the task of user authentication via a web API to an external handler.

The connect2id documentation is written from the POV of the server tenant, but maybe the consent-url you propose here is "similar" but from the POV of the client?!

I assume this is then a client credentials based only API?

Yes, it should be.

Does the URL depend on the API's input parameters? client_id, technical-scopes, purpose Or this the result URL fixed? If it is fixed then the URL could be a field in the openid-configuration. e.g. add a new field to https://mobileconnect.telekom.de/.well-known/openid-configuration consent_url: https://AZ/consent-url

This URL must be a temporary and non-predictable URL. It is NOT fixed and will depend on the client_id, the scopes, the purpose (W3C DPV value), and the target user whose consent is required for the requested scopes under the specified purpose for the corresponding client_id.

Should the API make sure that it can't be used as a telco-finder?
Should the API make sure that it can't be used to determine that a phonenumber is in use?
Should the API make sure that a end user is a customer of a telco?
If the client posts the same parameters, is the returned URL the same, or every time different?
If the returned URL is the same, then is it every time the same or for, say, for the next week?

The “consent” gap identified in this document is accurate. This gap is referenced in the “Consent and Measurement” API proposal submitted last November.

The "consent and measurement" API proposal focus on the legal requirements for client / brand usability and uses a consent string while bridging both online and offline brand/client requirements for  regulations in regards to opt-outs by people.
The existing framework of the CAMARA Consent APIs do not meet the legal requirements for client/brand to adopt which would be a major revenue driver.
@

Including some slides to complement the high-level API descriptor:
https://github.com/camaraproject/APIBacklog/raw/31cd6506c18aeee55247c29f55b9e98fa720fb10/documentation/SupportingDocuments/Out_of_Band Consent Capture URL.pptx

@AxelNennker The current propsosal is designed to log the subscriber’s usage of the device, such as websites visited.
Please note that if data leakage occurs downstream due to the developer’s mishandling of data via weak endpoints (e.g., CrowdStrike), the liability for leakage according to GDPR flows upstream. Regulators will fine the data source.
@jgarciahospital what is the purpose  for logging the usage of the device?

Should the API make sure that it can't be used as a telco-finder? Should the API make sure that it can't be used to determine that a phonenumber is in use? Should the API make sure that a end user is a customer of a telco?
If the client posts the same parameters, is the returned URL the same, or every time different? If the returned URL is the same, then is it every time the same or for, say, for the next week?

Hi @AxelNennker,
For the first 3 questions the response is a simple and absolute YES, and just in the same kind of approach as for the endpoints in CIBA or Authcode where same considerations shall be established. So, we don't expect different risks or considerations to be applied in this Out Of Band approach.
For the URL question, not sure whether the API specification need to enter in that kind of details that may be more dependant on the implementation of each operator, since it is directly bound to the operator-to-subscriber relationship. In fact, operators can just follow similar strategy as with the Authcode Flow consent capture process, for the creation of this webapage where user will be redirected.

@AxelNennker The current propsosal can be moused as a way to log the subscriber’s usage of the device, such as websites visited.
Please note that if data leakage occurs downstream due to the developer’s mishandling of data via weak endpoints (e.g., CrowdStrike), the liability for leakage according to GDPR flows upstream. Regulators will fine the data source.
@jgarciahospital what service or enhancement is this providing?

Hi @nickvenezia,
None of the current consent capture mechanisms, neither this out of band approach, are targeted to log the subscriber's usage of the device. Quite the opposite, the objective is to ensure a proper privacy management by leveraging the operator's control and ownership on the privacy management of our subscribers. I don't see how a consent capture, controlled by the operator with its proper and secure subscriber authentication can be used to log website historical...
The intention of this new out of band proposal is to maintain that control but taking advantage the knowledge of the developer about the use case and nature of their customers, ensuring that reaching the customer for that purpose is feasible and agile leveraging the channels of the third party. But always maintaining the ownership of the telco in the process, webpage is from telco, authentication of the user/subscriber with telco credentials is from telco...

@jgarciahospital and @jpengar Did you guys have any particular reason to not have a "regular" consent management API instead of the proposed consent url api?  Just wanted to know the thought behind.

@jgarciahospital and @jpengar Did you guys have any particular reason to not have a "regular" consent management API instead of the proposed consent url api? Just wanted to know the thought behind.

From my point of view, the proposed API is not intended to do consent management against the operator, it is specifically intended to provide an out-of-band consent capture mechanism to the API client (via a consent URL). By "regular" consent management API, I assume you mean an API to perform CRUD operations on consent records on the operator side, which is a completely different feature with a completely different scope. The consent URL allows the operator to collect consent through an operator channel. With a CRUD API on consent records, the operator would be exposing the ability to create, update, or delete consent records to third parties, so that consent management could be delegated. This is completely outside the scope of this API.

Hi,
This would be like operating with a delegated consent mode, which the partner would retrieve and then transmit to the operator.
I have several questions about this mode:
how to manage the life cycle.
Which identifier will match the user.
How to ensure that the user who has given his consent is the one who is the first owner of the identifier for which consent will be stored (since it is not the partner who will authenticate the user from login/password belonging to the operator).
What happens in case of revocation of consent? (the partner must display a consent page again?)
Consent is, imho, a very sensitive subject, and I always tend to be suspicious when it's delegated outside of the operator.

Hi,
This would be like operating with a delegated consent mode, which the partner would retrieve and then transmit to the operator. I have several questions about this mode:

how to manage the life cycle.
Which identifier will match the user.
How to ensure that the user who has given his consent is the one who is the first owner of the identifier for which consent will be stored (since it is not the partner who will authenticate the user from login/password belonging to the operator).
What happens in case of revocation of consent? (the partner must display a consent page again?)

Consent is, imho, a very sensitive subject, and I always tend to be suspicious when it's delegated outside of the operator.

hi @sebdewet, as we tried to clarify in the slide set and in the backlog meeting, this mechanism is not intended at all for privacy or consent delegation. That is a red-line of the operators and Telefonica is totally positioned in the side of the telco always remaining in charge of managing privacy and consent, basically because of the problems that this would bring as you detailed.
The proposal is meant for maintaining the telco as the one gathering the consent, using the subscriber authentication and providing a webview of the telco as well,  but allowing the application/developer to show it to the customer in the best moment and channel posible. So the API only generates a URL of the telco that the developer can show to the customer.

Does the URL depend on the API's input parameters? client_id, technical-scopes, purpose Or this the result URL fixed? If it is fixed then the URL could be a field in the openid-configuration. e.g. add a new field to https://mobileconnect.telekom.de/.well-known/openid-configuration consent_url: https://AZ/consent-url

This URL must be a temporary and non-predictable URL. It is NOT fixed and will depend on the client_id, the scopes, the purpose (W3C DPV value), and the target user whose consent is required for the requested scopes under the specified purpose for the corresponding client_id.

Why does it have to be temporary and non-predictable?
In ICM examples we have this:
GET /authorize?
    response_type=code
    &scope=openid%20dpv%3AFraudPreventionAndDetection%20sim-swap%3Acheck%20sim-swap%3Aretrieve-date
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com

Why not turn this into the following for the purposes of this API proposal? No client authentication is needed if the URL is standardized in this way...
GET /consent?
    &login_hint=tel%3A%2B34666666666
    &scope=openid%20dpv%3AFraudPreventionAndDetection%20sim-swap%3Acheck%20sim-swap%3Aretrieve-date
    &client_id=s6BhdRkqt3 HTTP/1.1
Host: server.example.com

Sorry, for the many questions. I am not against the idea to decouple consent collection from API usage and accss-token-creation. Though, I do not understand why this needs an API. @jgarciahospital Maybe update this PR with the collected answers?

Hi @AxelNennker,
Regarding the first question on the URL format, we maintain that having not-consistant urls will help to avoid third parties to create their own without the control of the telco, and that having specific ones for each request will help telcos to provide their own security mechanism. In any case, I think that is a good discussion to be held during the API specification, so we can leave it open now during the backlog review.
Regarding the need of this API, it's just to support the backend use cases where operator may not have the best knowledge of the customer nature when reaching the user for consent gathering, so developer/application can better take that role while keeping the control on the telco.
We'll try to update the template according to the discussions, and will continue in the next session. Of course, once the scope is clarified, best approach is to continue the detailed discussion directly in the subproject (I&CM?)

Regarding

will help telcos to provide their own security mechanism.

If more security is required than url-parameters can provide then the client can send a signed request object. If the request object is signed the authorization server knows which client sent it.
https://openid.net/specs/openid-connect-core-1_0.html#SignedRequestObject
Or use RFC9101 https://datatracker.ietf.org/doc/rfc9101/ which also provides encryption.
The whole point of OpenId Connect is standardizing the protocol, the URL, for authentication and consent, and to decouple authentication and consent from API usage. So, why create a temporary and opaque URL? Doesn't RFC9101 solve that?
Also, it is the whole point of OAuth2 to decouple authorization  from API usage. So, why this Consent-URL API?
Coming back to your scenarions:

So there is no other standard approach to provide a webview to the developer that can be shown to a final user, and it doesn't cover scenarios like:
* Pure backend services where no user device is involved, it is, no possibility for a frontend flow. There are a lot of antifraud use cases that do not require a pure user action to be executed, therefore we cannot count on the user been on a device APP.

This is a proposal for standardizing a mechanism that solves the gap in CIBA, for cases where the developer is the one who knows where and when to show the consent capture process (while operator gets still in charge of the how and the control).

I fail to see a gap in CIBA. In CIBA the deveoper/client is in control when to start the CIBA authentication request. So, the client can choose the "where and when". What is the use of a consent-URL when there is not authentication device?
The content-URL's content has to be shown somewhere.
If there is no user device, then how can the user be authenticated? And if the user is not authenticated, then no consent can be collected. I do not get this scenario.
Could you please be more specific than "pure backend services"? What is the user story?

* Services that are executed over a device which has no user interaction possibilities.

That sounds like the OAuth2 picture frame example or the OAuth2 photo printing example. The picture frame has no interaction capabilities and no way to know which photos to show and needs to be authorized to access the photos.
The printer has no interaction capabilites and no way to know which document to print...
OAuth2 was developed with devices without user interaction possibilities in mind.

* Consent capture campaigns without frontend flows.

The consent capture has to happen somewhere, and when there is no user device, then the user consent collection must happen on a 3rd-party device. Which might have user interaction capabilities. The user might not be willing to enter their user credentials on a device that they have not control over.
Please provide a more specific scenario.
Regarding Anti-Fraud scenarios, could you please provide a more specific scenario that uses the proposed Consent-URL API?

@AxelNennker leaving technical details apart until definition phase can start, we can focus on a requirement discussion as per backlog scope. So I prefer to go over the specification details when the proposal has started and the scope is ready.

I fail to see a gap in CIBA. In CIBA the deveoper/client is in control when to start the CIBA authentication request. So, the client can choose the "where and when". What is the use of a consent-URL when there is not authentication device?
The content-URL's content has to be shown somewhere.
If there is no user device, then how can the user be authenticated? And if the user is not authenticated, then no consent can be collected. I do not get this scenario.

With CIBA, developer can choose the "when" but not the "where/how", since the process is managed by the operator once the developer has started the request. So, there is not possibility for the developer to choose the channel where to reach the user if in a backend flow.
Let's imagine again a case of location API service where the SIM is installed in a tracking device. Consent is required and if operator tries to reach customer by SMS or similar, it is clear that this SIM is not going to be reachable this way. With consent URL API the developer can ask for a consent capture link and present it in the tracking configuration app/interface, where the user will introduce the telco credentials and provide the consent.

That sounds like the OAuth2 picture frame example or the OAuth2 photo printing example. The picture frame has no interaction capabilities and no way to know which photos to show and needs to be authorized to access the photos.
The printer has no interaction capabilites and no way to know which document to print...
OAuth2 was developed with devices without user interaction possibilities in mind.

Again, I think we don't need to provide a technical definition of how the operator will create the webpage for authenticating users or gathering consent, for sure not in this stage but maybe even neither in the technical specification phase. If we think again on this mechanism as a way to provide to the backend  the frontend capture page used in authcode (step 7 of the authcode flow), we just need to define the mechanism for retrieving that webpage URL, but not the webpage details (as neither defined in authcode right now).

The consent capture has to happen somewhere, and when there is no user device, then the user consent collection must happen on a 3rd-party device. Which might have user interaction capabilities. The user might not be willing to enter their user credentials on a device that they have not control over.
Please provide a more specific scenario.

Most of the use cases will be just the user interacting in one of their devices (not the OGW device) providing the consent after logging in a trusted telco webpage. Again, it's exactly the same as happens in a authcode flow but without the restriction of this happening in the OGW device. BUt yes, developer can choose to show this webpage in a nother device during a user interaction phase. Let's imagine again a location service for car tracking, where the user provides the consent during the purchase of the car in the car dealer premises, or in the configuration webpage of the dealer just including one additional screen in the process. It is clear the the user experience will be much clear than a backchannel mechanism from the operator, and that the current CIBA flow do not allow it.

Regarding Anti-Fraud scenarios, could you please provide a more specific scenario that uses the proposed Consent-URL API?

Any consent API can use this mechanism, not restricted to any service or category. I don't see any difference from antifraud to marketing.
Included changes in the API proposal as well as a draft User Story

@jgarciahospital I am going into the technical details because I am trying to understand whether there are already standards that could be used. If the technical standards already exist then this API is not needed.
Regarding this use case:

Let's imagine again a case of location API service where the SIM is installed in a tracking device. Consent is required and if operator tries to reach customer by SMS or similar, it is clear that this SIM is not going to be reachable this way. With consent URL API the developer can ask for a consent capture link and present it in the tracking configuration app/interface, where the user will introduce the telco credentials and provide the consent.

This sounds like the use case of a primary device (Smartphone with Tracking App ODSA) and a companion device (tracking device)  which are paired. (That could be viewed like OAuth2 where the picture frame has a SIM-card.)
That standard would bei TS.43.
https://www.gsma.com/newsroom/wp-content/uploads//TS.43-v11.0-Service-Entitlement-Configuration.pdf
TS.43 also standardizes using OIDC if more than EAP-AKA is needed.
Maybe this proposal is going to render TS.43 ODSA use cases obsolete, because this is much simpler.
I do not think that the technical details can be skipped. The technical details discussion is something like "prio art" in a patent application, I think. The patent should explain why it is new and not like that prior art.

Hi all :)
Vonage and Ericsson have been pondering the need for an API similar to this for a while, so it's great that this is being proposed. Vonage sees a need to expose an API that provides metadata linked to a Application/Scopes/Purposes per Subscriber/CSP at runtime, and this API should incorporate a Consent capture URL for the use cases described above.
We agree that there will sometimes be a need for Consent to be captured or revoked for application use cases upfront, out-of-band, and also Consent to be collected at runtime, in-band.
As stated before, we do not believe that collecting consent using a web portal in the frontend flow is viable, as it will materially deteriorate the End-User experience and will not be acceptable to most ASPs - the introduction of this mechanism will likely severely damage the market. Instead, frontend flows should always use upfront Consent capture using an API like this, or rely on a non-Consent-like legal basis.
Whilst the Consent URL API SHOULD be authenticated using OAuth 2.0 Client Credentials flow, the URL supplied by this Consent URL API MUST NOT have any guise of security, authentication MUST happen after the URL has been loaded, otherwise it could always be background loaded by a malicious app; therefore we do not see that there's a need for this URL to include dynamic one-time-use or secure components.
The mechanism of authentication would depend on what the URL loads, but this is a per-CSP decision that this API would permit. One could imagine that the URL could be a link to the CSP's website where username/password/MFA auth is used, or in the case of iOS a Universal Link that launches the CSP's installed app where authentication has already been completed; there are also other better options and mechanisms that can be discussed separately.
With respect to the API itself we have additional proposals for how it should work, for example, we suggest that optionally Scopes and Purposes could be included in the request and embedded within the URL in the response, or without providing these fields the URL's invocation would show all relevant privacy options for the application's registered use cases.
Lastly, I think that this API could be expanded to a general Consent API where Consent states for Scopes/Purposes could also be retrieved - this would guide the ASP on which APIs are available for each Scope/Purpose for the subscriber and CSP without further Consent capture, and where Consent capture will need be triggered preparing the End-User for an interruption to their usual scheduling.

@jgarciahospital I am going into the technical details because I am trying to understand whether there are already standards that could be used. If the technical standards already exist then this API is not needed.
Regarding this use case:

Let's imagine again a case of location API service where the SIM is installed in a tracking device. Consent is required and if operator tries to reach customer by SMS or similar, it is clear that this SIM is not going to be reachable this way. With consent URL API the developer can ask for a consent capture link and present it in the tracking configuration app/interface, where the user will introduce the telco credentials and provide the consent.

This sounds like the use case of a primary device (Smartphone with Tracking App ODSA) and a companion device (tracking device) which are paired. (That could be viewed like OAuth2 where the picture frame has a SIM-card.) That standard would bei TS.43. https://www.gsma.com/newsroom/wp-content/uploads//TS.43-v11.0-Service-Entitlement-Configuration.pdf TS.43 also standardizes using OIDC if more than EAP-AKA is needed.
Maybe this proposal is going to render TS.43 ODSA use cases obsolete, because this is much simpler.
I do not think that the technical details can be skipped. The technical details discussion is something like "prio art" in a patent application, I think. The patent should explain why it is new and not like that prior art.

The reason why to focus in the requirements instead on the solution is first the scope of the backlog group and second the main purpose of this proposal, which is enhancing current CAMARA auth/consent process, in which we have identified this gap (no possibility for a developer to show a consent webpage to a customer in any other device than the OGW device during a frontend flow).
The TS.43 companion device is a good example, but it shows more or less a CAMARA frontend flow with device authentication: main device is authenticated employing EAP-AKA mechanism (due to the sensibility of the SIM onboarding) (instead of authcode redirect network identification as in CAMARA) and later a websheet is exposed to the customer for the authentication as a CSP subscriber, and to validate the activation of the service in another device. So it is a parallel flow as the frontend that we have in CAMARA, even though there is a second device in which the service is finally executed.
But, in any case, here we are only focusing on the second step, reaching a websheet/webpage URL of the telco in which the consent can be provided, similar to the product activation in TS.43.
Following previous statement, once we understand that this mechanism is required we can decide on which solution is better to solve it, whether a TS.43 approach or any other market existing one, but for sure now it's not covered in CAMARA and that is what we need to confirm and start working on the solution.

@chrishowell thanks for the feedback, really welcomed.

Hi all :)
Vonage and Ericsson have been pondering the need for an API similar to this for a while, so it's great that this is being proposed. Vonage sees a need to expose an API that provides metadata linked to a Application/Scopes/Purposes per Subscriber/CSP at runtime, and this API should incorporate a Consent capture URL for the use cases described above.
We agree that there will sometimes be a need for Consent to be captured or revoked for application use cases upfront, out-of-band, and also Consent to be collected at runtime, in-band.
As stated before, we do not believe that collecting consent using a web portal in the frontend flow is viable, as it will materially deteriorate the End-User experience and will not be acceptable to most ASPs - the introduction of this mechanism will likely severely damage the market. Instead, frontend flows should always use upfront Consent capture using an API like this, or rely on a non-Consent-like legal basis.
Whilst the Consent URL API SHOULD be authenticated using OAuth 2.0 Client Credentials flow, the URL supplied by this Consent URL API MUST NOT have any guise of security, authentication MUST happen after the URL has been loaded, otherwise it could always be background loaded by a malicious app; therefore we do not see that there's a need for this URL to include dynamic one-time-use or secure components.

I believe we are mostly aligned with your authentication strategy, and main purpose of the URL one-shot proposal is to ensure it cannot be generated by anyone else than the telco.

The mechanism of authentication would depend on what the URL loads, but this is a per-CSP decision that this API would permit. One could imagine that the URL could be a link to the CSP's website where username/password/MFA auth is used, or in the case of iOS a Universal Link that launches the CSP's installed app where authentication has already been completed; there are also other better options and mechanisms that can be discussed separately.
Agreed that final subscriber authentication is part of each CSP strategy and mechanisms. I'd prefer to avoid device-dependant solutions, allowing options where a non-CSP device is used.

With respect to the API itself we have additional proposals for how it should work, for example, we suggest that optionally Scopes and Purposes could be included in the request and embedded within the URL in the response, or without providing these fields the URL's invocation would show all relevant privacy options for the application's registered use cases.
We need to take care on how this API could be used to request for information instead of its main purpose of gathering consent. Information exposed about existing consents/lawful bases shall be limited, and of course around telco finder.

Lastly, I think that this API could be expanded to a general Consent API where Consent states for Scopes/Purposes could also be retrieved - this would guide the ASP on which APIs are available for each Scope/Purpose for the subscriber and CSP without further Consent capture, and where Consent capture will need be triggered preparing the End-User for an interruption to their usual scheduling.
Same as previous comments, let's try to avoid information to be exposed by this API, otherwise we may enter in the chicken-an-egg situation of this API requiring consent itself because of the information it's exposing. But let's keep it open for discussion when we start working on the details, for sure.

I still don't get why the standard OIDC get-accesstoken page is not enough.
The developer can show this page whenever they like and whenever they think consent for this client, this scopes and purpose is best to be collected. Best means best UX, no interruptions, ....
The authorization server delivers that page/pages to whatever device the developer chooses.
The client knows that the page content was created by the authorization server because of the TLS certificate.
API usage is completely decoupled from accesstoken retrieval in OIDC.
To @nickvenezia comment: the page can be branded and must take all legal requirements into account. The page is easily adaptable to the client. Actually, I think, it always must be adapted to the client because the user has to take an informed decision when they provide their consent. "SupaClient wants to retrieve the location information of your kid's SupaTelco tracker for the next 4 weeks, do you consent?"
To @jgarciahospital comment:

main purpose of the URL one-shot proposal is to ensure it cannot be generated by anyone else than the telco.
There is no such assurance. The hacker can always build a look-alike page to fool the user. Random, one-shot urls are no protection. Even if the developer downloads a signed zip-file from the user-consent url and validates the signature, there is no way to stop a hacker who fakes the device and collects the user credentials.
What is the threat model? What are we protecting against?
I think random, one-shot urls provide no security.

This reminds me of the qrcode cross-device login case. The hacker tries to login, gets presented a qrcode, modifies the users qrcode page to show the hacker's qrcode. If the user authenticates and consents then the user consents to the hacker's login. (Which is why passkey's qrcodes are Bluetooth-protected)
Considering the above: Why is the standard OIDC "page" not enough?

@AxelNennker the The existing identity and consent APIs do not meet the legal requirements for client/brand adoption. Brands can not adopt Camara until addressed.

I assume that by "existing identity and consent APIs" you mean OIDC and CIBA?
Please explain what legal requirements for client/brand adoption means.
The authorization server gets an OIDC/CIBA authentication request and knows exactly which client is requesting an access token for which scopes and purpose. The authorization server then has the obligation to show the user an authentication page so that consent can be collected by that user can give their informed consent.
(Some GDPR related requirements on the consent page https://www.bfdi.bund.de/EN/Buerger/Inhalte/Allgemein/Datenschutz/Einwilligung.html)
I do not see a gap that needs to be closed. OIDC provides it all. The implementation details of authentication and consent collection are the responsibility of the authorization server

Under the GDPR you have to make the revocation of user consent in a way which is as easy as giving consent.
It may therefore be a good idea that next to an out of band API for consent collection there is also an out of band API for revoking consent, and an API for checking what the consent status is.
That way the ASP can provide the complete consent customer lifecyle out of band, preferably on the pages where it is collecting consent for its own processing.

I still do not see the need for a Consent URL API.
At some point in time the user has to give consent at the telco.
The user has to authenticate before they can give consent.
Consent is most probably about a Camara API.
Consent needs user interaction and user interaction need some user input e.g. for authentication. Then the user is on a front channel anyway.
When the user is on a front channel the API consumer can use OIDC authorization code flow.
If the user is not (yet) on a front channel then CIBA can trigger that front-channel interaction.
If the Camara API the client needs consent for involves a different SIM/IMEI/device/subscription than the authentication device or the consumption device, then that is a unsolved problem.
I think the consent url API is not solving that problem.
Nobody yet wrote a user story that shows the need for the consent url API.
Please (somebody) provide such a user story.

If you talk about an out-of-band revoking consent API, then we might start talking about a general consent management API (out-of-band or other). I think all telcos and Camara participants would benefit from a consent management API.
We could continue the W3C https://github.com/w3c/dpv work or contribute there.

@AxelNennker There are some API's in which you can't have user interaction during the API call, because the user interface is busy at that moment in time, for example for making a phone call.  In these cases you will have to acquire user consent way before the actual API call, and for that you may want to have a set of separate calls defined to handle consent.

@AxelNennker There are some API's in which you can't have user interaction during the API call, because the user interface is busy at that moment in time, for example for making a phone call. In these cases you will have to acquire user consent way before the actual API call, and for that you may want to have a set of separate calls defined to handle consent.

@HuubAppelboom The user interaction is when consent is granted or not, and that is code/accesstoken generation time.
I never claimed that user interaction is during the API call.

@AxelNennker Yes, I understand that the consent is acquired during code / access token generation time.  What I am referring to is that sometimes you may want to acquire user consent long before the actual API is needed.  For example, you may want to acquire the user consent for certain checks when opening a bank account. And that the checks are actually performed during transactions weeks later.
Now, you can try to use the same consent acquisition during the account  opening and transaction time (and generate a code and acces token which are never used), but most likely you would need to provide different information to the end user because the context is different. For example, if the API is about location verification, during onboarding you will ask whether the end user will agree to location verification when doing transactions in the future, while during a transaction you will ask for permission to check location now (otherwise the transaction does not happen) and during future transactions.
Context is everything when communicating with end users, and you need to be transparant about the consequences. Hence I do see a need for an a priori consent acquisition and an on-the-fly consent acquisition, so you can diffentiate communciation and what is relevant at that point in the user flow.

@HuubAppelboom The API consumer can ask for consent as often as they like and provide the context as appropriate.
How does the consent URL help?
I am guessing (again): Maybe the consent-url is pre-authenticated user consent collection? I think that does not count because the consent-url is not under control of the user. The API consumer could use the consent-url without the knowledge of the user.
I think the user needs to be authenticated by the telco every time the API consumer asks for consent. For that the user needs an interaction with the telco.
To pickup your example: Why is the API consumer/bank not asking for both consents when the account is opened?
How does the consent-url help when asking for the second consent? And how can the telco be sure that it is really the user giving their consent when the consent-url is used?
I would kindly ask supporters of this API proposal to provide one or two example use cases that can't be done with OIDC or CIBA. Everything I heard in this thread and other discussions about consent-url does not explain the benefit or the need of the consent url API. All the proposed use cases are vague and I got the impression consent-URL API is expected to solve a different problem than user consent collection.

@AxelNennker In the example that I mentionned it is not the idea that you ask consent twice, just once will do.  So it is either in the onboarding that consent is acquired, or at the moment of transaction (in case the consent is not there yet).
The consent is acquired is presented by the API Consumer, but is given to and stored by the CSP.  I think the consent question should be controlled by the MNO, because that is the only way you can ensure it meets the legal requirements, for which the CSPis responsible. Otherwise you rund the risk that the API Consumer may change the question for example to a less sensitive matter to  get a higher conversion rate.  Now the MNO does not know the context, so how is this going to work ?

My two cents.
I fully agree that an Authorization Code or CIBA authentication flow can be initiated at any time, depending on the use case and the application's capabilities, to capture consent. In fact, consent capture doesn't need to happen precisely when the API is consumed.
The key benefit of the Consent URL API is that it offers a significant advantage by enabling a fully decoupled, out-of-band mechanism for consent capture. This API allows the application to control the user experience entirely. The application can generate a consent URL from the Operator, which the user must authenticate with. However, the application has the flexibility to deliver this URL to the user through the most appropriate channel or medium, tailored to the user's current context.
Importantly, this API doesn't delegate consent capture to a third party but rather empowers the third party (the application) to present the Operator's consent capture URL at the most opportune time and place. The actual consent capture occurs within the Operator's secure environment, ensuring the user's authentication with the Operator.
Historically, in uses cases for CAMARA, the Authorization Code flow was thought to be used primarily for network authentication (a.k.a. silent authentication), where user interaction was minimal. Partners have often raised concerns about the user experience, especially when the user is directed to an Operator portal for authentication or consent within the Authorization Code flow—a point also highlighted by @chrishowell. Furthermore, the Authorization Code flow assumes the availability of a front-end device for the user, which isn't always the case.
While CIBA does provide an out-of-band method for user authentication and consent capture, it relies on the Operator reaching out to the user through channels under the Operator’s control, like SMS or push notifications (If the Operator Management application exists and is available to the target user). This approach can be limiting.
The Consent URL API adds a layer of flexibility to the consent collection process, allowing applications to integrate and customize the consent experience more seamlessly without intending to replace existing CAMARA OIDC flows. Instead, it enhances these flows by providing more options for when and how consent is captured.

@AxelNennker In the example that I mentionned it is not the idea that you ask consent twice, just once will do. So it is either in the onboarding that consent is acquired, or at the moment of transaction (in case the consent is not there yet).
The consent is acquired is presented by the API Consumer, but is given to and stored by the CSP. I think the consent question should be controlled by the CSP, because that is the only way you can ensure it meets the legal requirements, for which the CSP is responsible. Otherwise you rund the risk that the API Consumer may change the question for example to a less sensitive matter to get a higher conversion rate. Now the MNO does not know the context, so how is this going to work ?
@HuubAppelboom

How does consent URL API help?
The current flows allow the CSP to capture consent. The API Consumer determines when the consent is captured, and for what scope, purpose. The CSP knows the scope(s) and the client_id, and maybe the request is even signed.
This provides all the context the CSP needs to present the best possible UI to capture consent.
The API consumer can never change the "question". The UI of the consent-page is fully under control of the CSP. The only context information the API consumer provides are the standard request parameters which contain no text.
The API consumer can ask once for all scopes or many times for each single scope.
There is no relation with consent-url API in that.
How does consent URL API help?

@jpengar

This API allows the application to control the user experience entirely.

I would question "entirely". The application MUST not control the UX entirely.
The consent-URL is just a URL produced by the CSP.
I still have not seen a use case here which can't be done with the standard flows.
@jgarciahospital proposed a dog tracker use case but I think that also can be done with the standard flows and there was never a user story that benefited from the consent-URL API.
Every consent collection has to be done by an authenticated user because otherwise the CSP does not know who grants consent. The consent-URL cannot be pre-authencticated because the API consumer controls the consent-URL and the CSP does not know whether the CSP:User uses the consent-URL or some employee of the API Consumer.
For a user authentication the user has to be interacting with the CSP, preferably one a device the user controls and the device is not under the control of the API consumer because the API consumer could then steal the CSP:User's CSP-credentials.
The claim that the consent-url API has a ton of benefits is quite abstract.
Can somebody please provide a user story / example that uses consent-URL API as required by API_backlog?
Story ourtline:

API consumer is onboarded for some Camara APIs and one of them is consent-url
user buys device from vendor who is the API consumer
user uses their laptop and opens vendor device registration page
...
k) API consumer uses consent-url API
...
o) API consumer sends consent-url to user via whatever channel.
p) user opens consent-url in brower on some device
q) user authenticates to CSP e.g. using username and password

u) user can use device
v) API consumer has access token to use some Camara API
Probably the device contains a SIM issued by CSP and owned by CSP:User.
Some step above proves to the CSP that the user is in control of the SIM.
Please argue why the story benefits from consent-URL.
Please argue why a similar story that uses standard consent collection is worse.

As shared offline, new slide set with detailed explanation and user stories has been included in this PR.
Out of Band Consent Capture URL v2

@jgarciahospital Could you please turn the pptx into md documents, maybe each user story in a separate supporting document?
pptx is hard to version control and to review.

@gmuratk as API is to be brought to next TSC, please include new information to be reviewed.


Print date between messages if they are from different days

I made small change to my local build because I was missing the date limiters from Slack web client.
My rough change looks like this:

If there is enough interest for this feature or we just agree that it would be nice to add, I can prepare a PR when I catch some time.
P.S.: awesome project! :)

Please do the pull request :-) :+1:

Can you share your code?

Oh I didn't even see this issue before I posted #157 .
Neat.


Download button in Qrgenerate

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
What problem is this feature trying to solve?
How do we know when the feature is complete?

Kindly update the details for the feature request.

@Sulagna-Dutta-Roy  I updated the feature 😀kidly review back for any changes to do

@P-lavanya16 This extension was created by me, and the download button was already there. It appears once you generate the QR Code. Also, there's no use of the Download button before generating the QR Code.
@Sulagna-Dutta-Roy Kindly check!

Hello there, the download button is working for me too.

@Sulagna-Dutta-Roy theres only generate button,I have updated for download button so that if we want for further purposes we can download it for future use!!🙂

Thank you for assigning😊 @Sulagna-Dutta-Roy !!

@P-lavanya16 @Sulagna-Dutta-Roy Kindly have a look!
Also, @P-lavanya16 Enter a URL, and generate the QR, you'll get to see the Download button :)

@Sulagna-Dutta-Roy hok after generate button I vl add download button or either by clicking on generate button simultaneously it vl get to download ,in which approach I go for?

I'm new to it you have said that about some pull request changes I didn't
get it so could you help me in that please
On Wed, May 15, 2024, 21:23 Sambit Mondal @.***> wrote:

Screenshot.2024-05-15.212125.png (view on web)
https://github.com/Sulagna-Dutta-Roy/GGExtensions/assets/138088550/91a73037-24a2-4ba7-bd90-50d3fb76b892
@P-lavanya16 https://github.com/P-lavanya16 @Sulagna-Dutta-Roy
https://github.com/Sulagna-Dutta-Roy Kindly have a look!
Also, @P-lavanya16 https://github.com/P-lavanya16 Enter a URL, and
generate the QR, you'll get to see the Download button :)
—
Reply to this email directly, view it on GitHub
https://github.com/Sulagna-Dutta-Roy/GGExtensions/issues/180#issuecomment-2112913060,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCWTO7RTJHS7WFG5COTYKZTZCOAGDAVCNFSM6AAAAABHYB5NNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJSHEYTGMBWGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@P-lavanya16 It's your Idea how you can Implement this. Also the best approach you think ,it will be best.
Because we're in open source. Feel free to add your suitable changes

@P-lavanya16 It's your Idea how you can Implement this. Also the best approach you think ,it will be best.
Because we're in open source. Feel free to add your suitable changes

@P-lavanya16 This extension was created by me, and the download button was already there. It appears once you generate the QR Code. Also, there's no use of the Download button before generating the QR Code.
@Sulagna-Dutta-Roy Kindly check!

Also in this case, people can contribute or enhance some more changes in your projects. So that I assigned her.

Ohh, we can enhance changes in others extensions too! I didn't know this 🙂
Sorry for the inconvenience! @Sulagna-Dutta-Roy @P-lavanya16


spdx-utils: Regenerate SPDX enums to update to license list version 3.12

Done by running "./gradlew :spdx-utils:generateSpdxEnums". For details
see https://github.com/spdx/license-list-XML/releases/tag/v3.12.
Signed-off-by: Thomas Steenbergen<EMAIL_ADDRESS>Please ensure that your pull request adheres to our contribution guidelines. Thank you!

Something weird is going on in SpdxLicenseTest, but I did not have the time to look at it yet.

@tsteenbe, I've taken the liberty to force-push the fix to your PR.


Download button in the Expenses Tab

When I click the download icon, i could download a json file.
I think its not relevant.
What feature should we have to come up with when we click on this icon?

We can generate a spreadsheet instead of a JSON.
It would be helpful to lots of people, right?

I believe the export as json is intended for future use as part of an export/import functionality.
An additional option for downloading the transactions as a csv/spreadsheet file seems a good idea - feel free to raise a PR for review.

Hi! I also have this question: could ticket images be part of the export? Thanks.

Export to spreadsheet would definitely be helpful! I went looking for this feature today.


Add annotations for Event Publisher and Subscriber, and Command

@EventSubscriber, @EventPublisher, @Command

See the discussion in #18.


How to change favicon in docker?

Attempted Debugging

[X] I have read the debugging page

Searched GitHub Issues

[X] I have searched GitHub for the issue.

Describe the Scenario
Use custom favicon. Isn't there a way to do this by adding a volume entry in the Portainer stack?
I have tried numerous lines but none work. For example:
...
 volumes:
      - /path/to/local/config:/config
      - /path/to/local/favicon.ico:/bookstack/public/favicon.ico
...

...
 volumes:
      - /path/to/local/config:/config
      - /path/to/local/favicon.ico:/public/favicon.ico
...

If I use the following, the favicon appears to have been replaced but I only get a "File not found" error on the page and I cannot access the site:
...
 volumes:
      - /path/to/local/config:/config
      - /home/docker/bookstack/favicon.ico:/app/www/public/favicon.ico
...

Exact BookStack Version
v22.11.1
Log Content
No response
PHP Version
Whatever comes with the Docker image
Hosting Environment
AlmaLinux 8.7 host, Portainer, Nginx Proxy Manager
image: lscr.io/linuxserver/bookstack

I had a question similar to yours
https://github.com/BookStackApp/BookStack/issues/3973
I use docker to deploy the website just like you. Adding some custom content should not be done in dockerfile or docker-compose.yaml, it needs to be placed in a custom theme folder. Anyway, I implemented it

@liuhuanshuo
Thanks for the info. I understand the basics of how BookStack theming works but I do not see how one can change the favicon via a custom theme. I see that there is a favicon.ico in the /public directory but i do not see it referenced in any of the files under the /resources directory or referenced in any of the other files for that matter.

Definitely not an ideal solution but it works.

You are right, replacing files is not the best solution
I searched for more related questions and finally I found the answer
https://www.reddit.com/r/BookStack/comments/xqp41o/changing_favicon/
As mentioned in the above link, we only need to add a line of code in the settings of the web version, and it works for me.
<link rel="icon" href="https://pic.liuzaoqi.com/picgo/202301221818310.ico" />

I searched for more related questions and finally I found the answer
https://www.reddit.com/r/BookStack/comments/xqp41o/changing_favicon/

I actually tried that before posting this issue. It did not work for me when I first tried it. Since you confirmed it worked for you, I removed my override base.blade.php and tried adding that line of code in the admin settings and it worked this time! I'm guessing my browser cache did not fully clear the last time I tried it.
Still, I wish there was a simple way to use an internal image file instead of pulling the icon from an external site.

So here is how I am currently using an internal image:

Manually upload the favicon image file to the same directory as your custom logo.

My host path: /.../config/www/uploads/images/system/2022-12/favicon.svg
The resulting URL: https://example.com/uploads/images/system/2022-12/favicon.svg

Add this line to the Settings->Customization->Custom HTML Head Content input box in the BookStack admin:

<link rel="icon" href="uploads/images/system/2022-12/favicon.svg" sizes="any" type="image/svg+xml">

Anyone, please feel free to comment if there is a better way.

@jeffshead Glad to see you found a solution.
I've just merged in #3994, to be part of the next release, so that png-based favicon can be set directly from the settings in the same way as the app logo.


fix(backend): Fix getToken() from getAuth() return value in v5

Description
Change SessionApi.getToken() to return consistent { data, errors } return value
and fix the getToken() from requestState to have the same return behavior as v4
(return Promise or throw error).
This change will fix issues in @clerk/nextjs / @clerk/remix with getToken():
Example:
import { getAuth } from '@clerk/remix';

const { getToken } = await getAuth(...);
const jwtString = await getToken();

Also a breaking change in the clerkClient.sessions.getToken()  was introduced as the return value was changed. To keep the existing behavior use the following:
const { data, errors } = await clerkClient.sessions.getToken(...);
if (errors) {
  throw errors;
}
const jwt = data.jwt;

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[ ] @clerk/backend
[ ] @clerk/chrome-extension
[ ] @clerk/clerk-js
[ ] @clerk/clerk-expo
[ ] @clerk/fastify
[ ] gatsby-plugin-clerk
[ ] @clerk/localizations
[ ] @clerk/nextjs
[ ] @clerk/clerk-react
[ ] @clerk/remix
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/themes
[ ] @clerk/types
[ ] build/tooling/chore

!snapshot

Hey @nikosdouvlis - the snapshot version command generated the following package versions:

Package
Version

@clerk/backend
1.0.1-snapshot.v298b880

@clerk/chrome-extension
1.0.1-snapshot.v298b880

@clerk/clerk-js
5.0.1-snapshot.v298b880

@clerk/elements
0.0.3-snapshot.v298b880

@clerk/clerk-expo
1.0.1-snapshot.v298b880

@clerk/fastify
1.0.1-snapshot.v298b880

gatsby-plugin-clerk
5.0.1-snapshot.v298b880

@clerk/localizations
2.0.1-snapshot.v298b880

@clerk/nextjs
5.0.1-snapshot.v298b880

@clerk/clerk-react
5.0.1-snapshot.v298b880

@clerk/remix
4.0.1-snapshot.v298b880

@clerk/clerk-sdk-node
5.0.1-snapshot.v298b880

@clerk/shared
2.0.1-snapshot.v298b880

@clerk/themes
2.0.1-snapshot.v298b880

@clerk/types
4.0.1-snapshot.v298b880

Tip: Use the snippet copy button below to quickly install the required packages.
@clerk/backend
npm i<EMAIL_ADDRESS>--save-exact

@clerk/chrome-extension
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-js
npm i<EMAIL_ADDRESS>--save-exact

@clerk/elements
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-expo
npm i<EMAIL_ADDRESS>--save-exact

@clerk/fastify
npm i<EMAIL_ADDRESS>--save-exact

gatsby-plugin-clerk
npm i<EMAIL_ADDRESS>--save-exact

@clerk/localizations
npm i<EMAIL_ADDRESS>--save-exact

@clerk/nextjs
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-react
npm i<EMAIL_ADDRESS>--save-exact

@clerk/remix
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-sdk-node
npm i<EMAIL_ADDRESS>--save-exact

@clerk/shared
npm i<EMAIL_ADDRESS>--save-exact

@clerk/themes
npm i<EMAIL_ADDRESS>--save-exact

@clerk/types
npm i<EMAIL_ADDRESS>--save-exact

Closed in favor of https://github.com/clerk/javascript/pull/2539


[FEATURE] Add delete post on post page

Description
On the post page currently, the user can't delete the post. I want to add the delete post also there so that he/she doesn't need to navigate to the home page for deleting post.
Screenshots
No response
Additional information
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I have checked the existing issues
[X] I'm a GSSoC'23 contributor
[X] I want to work on this issue

Description
On the post page currently, the user can't delete the post. I want to add the delete post also there so that he/she doesn't need to navigate to the home page for deleting post.
Screenshots
No response
Additional information
No response
Record

[x]  I agree to follow this project's Code of Conduct
[x]  I have checked the existing issues
[x]  I'm a GSSoC'23 contributor
[x]  I want to work on this issue

sure, you can go ahead!


Added CountOption and getOrElse

CountOption allows for cache invalidation while looking through the cache map to save on memory usage.
and getOrElse can be used to make autoUpdating cache for databases.

there's no point in placing it outside the forEach and have it loop twice.

there's no point in placing it outside the forEach and have it loop twice.

No why would it loop twice? Just remove the else if block and place an if block after the for each and do this.invalidateCache(null, {full: false})


F#3157 improve configure schema performance

Description
Improve configure schema and metadata column details performance
Related Issue : #3157

How Has This Been Tested?

Go to datasource details and column details.
Click 'Please configure the schema'.
Click anywhere and check if it operates normally without error.
Go to management - exploration - metadata
Go to a detail page and click Column details tab.
Click anywhere and check if it operates normally without error.

Need additional checks?
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] I have read the CONTRIBUTING document.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have added tests to cover my changes.

Additional Context

deploy to 2


Crash to title on attempt to get items via recipe+ in JEI

DW20 1.19.2 Pack version 1.1.1, FT version 2.0.2, JEI version .5.2.1000
Tried a shortcut to get the prismarie shards for the base star (goal being Flight Trinket) by clicking + with the recipe open in JEI. The game crashed to the title screen, I was able to re-log with no loss.
While it may not have been a good idea to try this I would expect it to fail rather than crash the game.
It also made me a little gun shy so I can't confirm if adding the items to the Experience Crafter? works using the + option.

Do you have a crashlog?

sorry it took a while, I've just got home from an afternoon trip to hospital with mum, then I thought "why not get a fresh crash report by recreating" so I did what I did before and again crashed to title BUT it did not generate a new report so this is the one from 27th
crash-2023-01-27_09.26.02-client.txt

It's actually crashing in NaturesAura:
at de.ellpeck.naturesaura.items.tools.ItemArmor.isFullSetEquipped(ItemArmor.java:42) ~[NaturesAura-37.4.jar%23612!/:37.4] {re:classloading}

Please about 1 thing .....that is the impression I got from reading the report. Funny thing is...... I am not wearing any natures aura armor, in fact I just removed all armor and trinkets and tried again and it still crashed and there was no new crash report. Maybe the report I sent is not related..... maybe a report has never been created for this crash. The image is the on screen error and it is sending me "Back to a server list" but I am playing single player. Also I logged back in an searched JEi and my inventory/backpack and I have no Natures Aura armor.

Really simple (and probably something I should not do)
Open DW20 1.19.2 modpack v1.1.1 with Trinkets installed (I may have added it, don't recall)
Go to JEI crafting grid, have prismarine shards in a drive, search for the "base star" using JEI (oddly that displays all 4 stars) select the base star with a left mouse click to bring up the crafting recipe.
Then click the + which has the hover over text "Move Items".
That is it, all over, crash to the earlier posted screen shot, from there it is a click on "back to server list" to "locate server" another click on cancel and your back to the "Fancy Title" chose single, multi etc which I am calling a crash to title because it is not making me relaunch the modpack in FTB app.

'shards in a drive'? What is a drive?
Also JEI crafting grid in what device? The XP crafter?
Still confusing me

No ..... I am so sorry I've been writing that wrong.... my mistake. The crafting grid is Refined Storage as is the drive, a Hard drive 4k is enough, an external storage on a chest is also something that should work.
JEI is just a mod that you use to search for recipes. The XP crafter is not in this at all.
Basically I tried to get the correct number of shards from my storage system by clicking "Move Items" from within my storage system .... Refined Storage so I could then go to the XP crafter to complete the craft.
Between me making errors and you almost exclusively using RFTools for inventory systems we had no chance of making sense of this.
Below is the rectified description
Really simple (and probably something I should not do)
Open DW20 1.19.2 modpack v1.1.1 with Trinkets installed (I may have added it, don't recall)
Enter Refined Storage crafting grid UI by right click, have prismarine shards in a Hard Drive or some other Refined Storage connected storage, use the search bar for "base star" (oddly that displays all 4 stars) select the base star with a left mouse click to bring up the crafting recipe.
Then click the + which has the hover over text "Move Items".
That is it, all over, crash to the earlier posted screen shot, from there it is a click on "back to server list" to "locate server" another click on cancel and your back to the "Fancy Title" chose single, multi etc which I am calling a crash to title because it is not making me relaunch the modpack in FTB app.

https://www.youtube.com/watch?v=x_uqJHEmZjM
Hi McJty, I thought it would be easier to show you, I thought I would be getting my vocals on this but looks like it did not work so I will Narrate in text.
Please forgive the 80 second delay before the actual video starts I have not done this in nearly 10 years.
I am showing the devices that I was referring to but naming wrongly previously.
I then show how I have used the process previously using the Cyclic Amber as an example. I click to bring up the recipe then click move items to move them to the 3x3 where I remove them to perform the craft in the Cyclic machine.
I then try the exact same thing but with the base star and I get a completely different result.
I can also confirm the I did this 3 times today, once without a mike connected, once I thought was recording but wasn't and the 3rd when I discovered no narrative was recorded ..... none created a crash report.

There should have been a crash in the client console. Maybe try by opening that?
Then again, I don't see how this has anything to do with my mod though

It may not be..... but I have only seen it using your "Crafting" recipe.
I am not sure what you mean by "Client Console" I am not playing on a server and the location I look for crash reports is /instances/"giberish"/crash-reports
as in -  AppData\Local.ftba\instances\b9be2473-b55c-42ed-b3e8-a3e592172358\crash-reports

I mean the actual console of your launcher. Whatever that is

OH ....... the launcher is the FTB app/OverwolfLauncher, I normally close that after the game loads. I just had a look and it contains a "Crash ReportER" but I can see no crash report. OK so FTB app displays the "log" progress in the app, I started the game and a message saying backup started then another saying skipping as no player on since last backup I then made it crash again. I then located the log (AppData\Local.ftba\instances\b9be2473-b55c-42ed-b3e8-a3e592172358\logs) BTW and copied the text from the backup messages as the previous would have no relevance.
I can not see WHY it is crashing, you are likely right and it coincidental that your mod has a recipe that the game is crashing on (when used wrongly), I think JEI* might have a problem with large recipes in this version, I know it didn't in 1.18 Stone Block2 with extreme crafting (like you are seeing in SSDD). At least I know what not to do and it won't be a problem for others in DW20 pack ....... unless Fancy Trinkets gets added.
Consolelog.txt
*Search JEI or Just Enough Items on CurseForge if you are not familiar with the mod - it is very popular.
I am sorry to take your attention away from more serious issues it seemed like something you should be aware of.
Thank You

Of course JEI is popular. FancyTrinkets even integrates with it :-)
I know it well

I know it that well I even call other mods JEI sometimes :(


Included templates only discovered if they are in the same directory

I have a project layout with a top-level templates directory containing base.html, and within apps I have template directories containing templates which extend the global base.html. When I run the plugin, base.html is not included in coverage. If I move base.html into the app template directory, it is included. As an example (where base.html is not included): https://github.com/jessamynsmith/eggtimer
If I move eggtimer/templates/base.html into eggtimer/periods/templates/base.html, then it shows up in coverage.

This was due the .coveragerc file having a setting of "source = api, eggtimer, periods", but the template was in "templates/base.html", so it was excluded by the source rule.  Adding "templates" to the source option fixed it.


What do "FDA", "PCA" and "SPM" stand for?

FDA = Functional Data Analysis
PCA = Principal Components Analysis
SPM = Statistical Parametric Mapping


Fix stream decoding for null/true/false value

fix https://github.com/goccy/go-json/issues/199
fix https://github.com/goccy/go-json/issues/196
The #199 was caused by #196 . Since there is not enough buffer in the middle of reading null, rereading is performed, but at this time it became an invalid buffer.

Codecov Report

Merging #208 (2034757) into master (82cc22a) will decrease coverage by 0.00%.
The diff coverage is 49.09%.

@@            Coverage Diff             @@
##           master     #208      +/-   ##
==========================================
- Coverage   82.16%   82.15%   -0.01%
==========================================
  Files          49       49
  Lines       21761    21771      +10
==========================================
+ Hits        17879    17887       +8
- Misses       3018     3023       +5
+ Partials      864      861       -3

Works for me.


Custom URLs gets overwritten without warning

Describe the bug
When custom urls are same, the older link gets overwritten without warning
To Reproduce
Steps to reproduce the behavior:

Go to Admin Panel
Click on add buttton
Enter same custom URL as the one you already have
The new URL replaces the older URL

Expected behavior
If the provided custom URL already exists, show a warning before overwriting.

I want to work on this issue.
A javascript function will check if the current shorturl is  already existing on not.
I will create the warning dialog box which will ask the user if he wants to replace the existing one or try renaming again.


Eagerload docblock is incomplete

DataList::eagerLoad() dockblock doesn't explain what the method does
PRs

https://github.com/silverstripe/silverstripe-framework/pull/10827

PR merged


Inconsistency for successive references in schemas and parsing

The schemas in data/ are parsed by two tools: dump-swagger.py to generate OpenAPI JSON files and hugo to generate https://spec.matrix.org. Each tool has different expectations when it comes to successive relative reference resolution. Consider the following example:
example: {
  "$ref": "examples/foo.json",
  "key": [{"$ref": "bar.json"}]
}

dump-swagger.py will look for bar.json in a path relative to the one of foo.json, i.e. bar.json needs to be in the examples directory for this to work.
hugo on the other hand will look for bar.json in the same directory as examples.
The schemas are not consistent either. Some work one way, some others work the other way. For instance:

data/api/server-server/invites-v2.yaml line 133, ../../event-schemas/examples/invite_room_state.json is relative to data/api/server-server/ which contains definitions/.
This is compatible with hugo. It results in the example body for the 200 response for /v2/invite to contain the invite_room_state array. It however breaks dump-swagger.py which gives a FileNotFoundError for /home/afranke/src/matrix/matrix-doc/data/api/server-server/examples/../../event-schemas/examples/invite_room_state.json (the examples/ from examples/minimal_pdu.json a few lines above is creating the problem).
data/api/server-server/transactions.yaml line 72, edu.json is (as pointed out by the comment there) relative to the examples/ directory, from line 71.
This works with dump-swagger.py but breaks for hugo, as can be seen by the lack of (required) edus field in the request body example for /v1/send.

I looked it up online and failed to find which way is The Correct One™, but I have to say I find the dump-swagger.py one confusing (“relative to another path that I used somewhere above”⁉).
We need to decide on one of the two ways (I recommend the hugo one), and then we need to patch both the other tool and the schemas that were aligned with that tool.

agreed, the search path for $ref should not depend on other things earlier in the document.


Feature/search button

This fixes #53.

1. Add some margin/padding to the bottom of the button.

Done. Used margin as padding expands the button

2. Ask a UX/UI designer (or 2) what he thinks about the wording. I suspect something like "Search" would be better. Please discuss.

As per a discussion we had before, I changed it to "Run", maybe search is confusing as it requires an input?


Availability slots in availability form not read by screen readers

The toggles in the availability form are not read by screen readers. Blind users of our website don't know if a toggle is set to "available" or to "unavailable".

I looked into this briefly and I think I understand what is happening.
The available/unavailable toggles seem to be handled by this bootstrap plugin. The plugin seems to take a normal checkbox input and essentially replaces it with stuff that looks nice but isn't accessible at all.
I don't have time to fix it right away (maybe this weekend I'll try again to get a dev environment going), but I think the simplest idea might be to just wrap the checkbox with a div with an aria-label, then hook into the events on the checkbox to update that aria-label (the github for the plugin makes it seem like this would be easy, but who knows).

https://github.com/Lichess4545/heltour/blob/13160c63eaeb9f0c27856d9835d3687e2d5fb5c3/heltour/tournament/templates/tournament/availability.html#L44-L56 is the relevant place in the form.
https://github.com/Lichess4545/heltour/blob/13160c63eaeb9f0c27856d9835d3687e2d5fb5c3/heltour/tournament/views.py#L1797 is the related view class.


libssl.so.1.1:  cannot open shared object file  what should i do

ityfuzz: downloading latest ityfuzz binaries
##################################################################################################################################################################################### 100.0%
/root/.ityfuzz/bin/ityfuzz: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
ityfuzz: command failed: /root/.ityfuzz/bin/ityfuzz --version
ityfuzz: installed -
ityfuzz: done!
/root/.ityfuzz/bin/ityfuzz: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
ityfuzz: warning: failed to run ityfuzz
ityfuzz: please consider installing 'libssl-dev' or other missing dependencies

If you are on Ubuntu, run apt install libssl-dev

i tried, but

If you are on Ubuntu, run apt install libssl-dev
i am on wsl , Ubuntu,
i tried ,but
root@isaac:/mnt/c/Users/isaac# apt install libssl-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libssl-dev is already the newest version (3.0.2-0ubuntu1.15).
0 upgraded, 0 newly installed, 0 to remove and 50 not upgraded.
and
root@isaac:~# dpkg -l libssl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name             Version           Architecture Description
+++-================-=================-============-================================================
ii  libssl-dev:amd64 3.0.2-0ubuntu1.15 amd64        Secure Sockets Layer toolkit - development files
un  libssl-doc               (no description available)
un  libssl1.0-dev            (no description available)
ii  libssl3:amd64    3.0.2-0ubuntu1.15 amd64        Secure Sockets Layer toolkit - shared libraries
--

https://stackoverflow.com/questions/72133316/libssl-so-1-1-cannot-open-shared-object-file-no-such-file-or-directory
Be careful there might be some risks as it suggests

https://stackoverflow.com/questions/72133316/libssl-so-1-1-cannot-open-shared-object-file-no-such-file-or-directory
Be careful there might be some risks as it suggests

It worked, thank you very much!!!!!!!!


Update Omnibus tooling to support Python checks defined by a pyproject.toml file

Motivation
Part of ongoing effort to modernize integration packaging, see https://github.com/DataDog/integrations-core/pull/11233
Additional Notes
Usage:

https://github.com/DataDog/datadog-agent/blob/7.33.x/omnibus/config/software/datadog-agent-integrations-py2.rb#L259-L260
https://github.com/DataDog/datadog-agent/blob/7.33.x/omnibus/config/software/datadog-agent-integrations-py3.rb#L263-L264

CI should be fixed by #10696, I am testing that


vfredusum_vs_f32m1_f32m1 not supported by gcc10.1

Is vfredusum_vs_f32m1_f32m1 supported in gcc?  Which version?

I would suggest you to use this version GCC: https://github.com/riscv-collab/riscv-gcc/pull/334. This version support all C api intrinsics in this https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/new-policy-proposal   proposal

We have regular intrinsics both available in latest GCC and LLVM.
vfloat32m1_t vfredusum_vs_f32m1_f32m1 (vfloat32m1_t dest, vfloat32m1_t vector, vfloat32m1_t scalar, size_t vl);
vfloat32m1_t vfredusum_vs_f32m1_f32m1_m (vbool32_t mask, vfloat32m1_t dest, vfloat32m1_t vector, vfloat32m1_t scalar, size_t vl);

Also policy intrinsics if you care about tail elements of the destination register. These are now available in latest GCC and going to land soon in LLVM.
vfloat32m1_t vfredusum_vs_f32m1_f32m1_tu (vfloat32m1_t merge, vfloat32m1_t vector, vfloat32m1_t scalar, size_t vl);
vfloat32m1_t vfredusum_vs_f32m1_f32m1_ta (vfloat32m1_t vector, vfloat32m1_t scalar, size_t vl);
vfloat32m1_t vfredusum_vs_f32m1_f32m1_tum (vbool32_t mask, vfloat32m1_t merge, vfloat32m1_t vector, vfloat32m1_t scalar, size_t vl);
vfloat32m1_t vfredusum_vs_f32m1_f32m1_tam (vbool32_t mask, vfloat32m1_t vector, vfloat32m1_t scalar, size_t vl);


Analysis framework detect namespaces with invalid "istio.io/rev" annotation

As part of https://github.com/istio/istio/issues/21934 users will expect to know if a namespace with istio.io/rev annotation is not being handled by an Istio control plane because no control plane matches that Rev.
This is an example of a K8s API object that needs validation from Istio.  As part of this work Galley and/or Istiod are expected to set the .status field of the namespace if analysis is enabled.
The mechanism to decide if a control plane is valid will be approved by UX for Multiple Control Planes doc.

Already implemented with https://github.com/istio/istio/pull/22755


design: asynchronously load tokens on both wallets

Feature Name: Load tokens asynchronously on the wallet-desktop and mobile
Author: André Abadesso<EMAIL_ADDRESS>
Summary
We should download token information asynchronously on the wallets, changing the UX accordingly to inform the user that the balances may not yet have been downloaded
One point note mentioning is that the changes proposed on this document are specifically for the new wallet-service facade, so no changes should be made when the wallets are using the old facade
Motivation
Currently, while using the wallet-service facade, our wallets download the token balances and history synchronously, downloading one token a time, as we can see on this wallet-desktop example:
  async fetchWalletData(wallet) {
    // First we get the tokens in the wallet
    const tokens = await wallet.getTokens();

    const tokensHistory = {};
    const tokensBalance = {};
    // Then for each token we get the balance and history
    for (const token of tokens) {
      /* eslint-disable no-await-in-loop */
      // We fetch history count of 5 pages and then we fetch a new page each 'Next' button clicked
      const history = await wallet.getTxHistory({ token_id: token, count: 5 * WALLET_HISTORY_COUNT });
      tokensBalance[token] = await this.fetchTokenBalance(wallet, token);
      tokensHistory[token] = history.map((element) => this.mapTokenHistory(element, token));
      /* eslint-enable no-await-in-loop */
    }

    // Then we get from the addresses iterator all addresses
    return { tokensHistory, tokensBalance, tokens };
  }

Only after that complete download, the dashboard screen is displayed with the downloaded balances and history.
Another problem is that we download the balances and history for all the tokens the user has ever interacted with, even if they are not registered
This is a problem for users with multiple tokens as the perceived loading time of the wallet is very big
Guide-level explanation
The idea is to show the main screen of the wallet as soon as the token set as default on the config and the hathor token balance is loaded and start downloading asynchronously the list of tokens the user has registered on his device.
We also should change the behaviour of the wallet to only download the history of transactions when the user effectively clicks the token to see it, also displaying a loading indicator until the page is downloaded
UI Changes
Dashboard screen
We should display a loading indicator right next to the names of the registered tokens, indicating that the balance for this token is still being downloaded.
This download will be triggered by default when the user enters this screen for each token he has registered.

Unknown tokens screen
On the desktop wallet, we have a screen that displays all the tokens that have not been registered yet, including their balances and history

If the user clicks the Show history button and the balance was already loaded, we should display only the Loading history... spinner

If the user clicks the "Hide history" button before the history download finishes, we will continue the download in background and the next time the user clicks the "Show history" button, we will show the downloaded history.
History screen
Since the history will only be downloaded from the wallet-service lambda when the user clicks the token to see it, we should show a loading indicator until the current page of transactions is downloaded
Once the history is downloaded, we should not trigger a download when the user clicks to see the details for a token

On the desktop wallet, since we have multiple downloads on the same screen, we should have a single loading that will be up until every request is successfully resolved

If any of the requests fail, we should display an error screen with a button to retry

Send token
While on the SendAmountInput screen, after clicking the select button to change token, we should also display the loading indicator instead of the balance so the user knows that it is still downloading

Reviewers: @msbrogli @pedroferreira1

For me this Guide Level is approved, I like the new UX.
For the low level, one important note is that this might affect the real time update from the ws. With this change, we must update the internal history only if the new real time tx has one of the loaded tokens.

The Guide Level is approved for me. I think we should have a low level design to discuss how we will handle all loading tasks internally. I feel we should replace all "integer fields" by "object fields" with a status (stopped, loading, loaded), last update time, and value. We should also discuss the updating policy for these fields.

From my point of view, the UX is clear and adequate for this solution.

I like the reference level design in general, just some comments:

How are we going to handle real time updates? We should only update the tokens that are already loaded, right?

Check if the updatedAt of the last stored information is higher than TOKEN_HISTORY_TTL

If false, do dispatch TOKEN_FETCH_HISTORY_SUCCESS to set loading to false and break

When are we going to use this? If the history/balance has been loaded a long time ago, should still be fine because of the real time update, right?

I think a small section about the old facade would be good. Just to explain that it will continue loading all tokens before the wallet gets ready but the UI/UX and methods changes will be for both facades.

One note about the real time

We should refactor this to dispatch actions to download the balances and history for the registered tokens only and also only for the tokens involved in the transaction

We should dispatch the actions only if the token has already been loaded, right? Actually I'm not sure about the wallet service facade, when do we start getting real time update? We wait until the wallet is ready, or until the wallet loads all tokens nowadays?

When are we going to use this? If the history/balance has been loaded a long time ago, should still be fine because of the real time update, right?

You are right, I guess that this time to live does not make sense as we will always have the updated history because of real-time updates. I will remove this part, but wait until @msbrogli reads this

@pedroferreira1

We should dispatch the actions only if the token has already been loaded, right? Actually I'm not sure about the wallet service facade, when do we start getting real time update? We wait until the wallet is ready, or until the wallet loads all tokens nowadays?

I agree that we should dispatch the load balance and history actions only if the token has already been loaded, will update the design
Currently on the wallet service, we are only setting up the connection after the wallet is ready (the wallet start lambda returns 'ready') but before the history and balances are loaded

@andreabadesso I like the idea of using saga. Good job! Here are some thoughts:

As far as I understood, you are replacing old integer values (e.g., a token balance) by a dict with keys status (loading, ready, and error), value, and updatedAt. Is that right? I assume that for the old face, you will always populate those values with {status: "ready", value: balance, updatedAt: now}. Is that right? This part is missing from the low level design.

I feel you should explicitly explain that the new interfaces will be the same for all implementations. So you will have to update both the old facade and the wallet service facade.

I feel you should explicitly say that all screens will be adapted to a new async interface. The old facade will resolve the promises at once while the wallet service will request information from the backend.

@msbrogli
Thanks for your review

As far as I understood, you are replacing old integer values (e.g., a token balance) by a dict with keys status (loading, ready, and error), value, and updatedAt. Is that right? I assume that for the old face, you will always populate those values with {status: "ready", value: balance, updatedAt: now}. Is that right? This part is missing from the low level design.

That is correct, I described the new data structure for tokensBalance and tokensHistory on the State and reducers  section of the design
I added this note to make it clearer what will happen on the old facade:
On the old facade, since we will already have this information loaded on the facade (after the address scan is done), status for the tokensHistory and tokensBalance will always be populated with ready
What do you think?

I feel you should explicitly explain that the new interfaces will be the same for all implementations. So you will have to update both the old facade and the wallet service facade.

I agree, updated the Old facade section

I feel you should explicitly say that all screens will be adapted to a new async interface. The old facade will resolve the promises at once while the wallet service will request information from the backend.

Also added a note for that on the Old facade section

Approved

@andreabadesso Thanks!
This design is approved by me.


Faster VMWare Fusion Box

The VMWare Box has not enough RAM and CPU, this will give it some extra boost 🐰

Does it really need more than the VBox version or shall we bump that one as well?

Was soll der Geiz, we will bump that up, too!


To get the [CartFacadeHookFactory and PriceFactoryFactory object] in the [api-storefront hook and api-storeapiresponse hook]

... and to be able to read and manipulate the shopping cart
1. Why is this change necessary?
[form request object] not available in [cart hook], so we make the cart and price hook available in the [api-storefront and api-storeapiresponse hooks]
2. What does this change do, exactly?
Core

Changed src\Storefront\Framework\Script\Api\StorefrontHook.php added CartFacadeHookFactory::class and PriceFactoryFactory::class, to getServiceIds function.

Storefront

Changed src/Core/Checkout/Cart/Hook/CartHook.php added CartFacadeHookFactory::class and PriceFactoryFactory::class, to getServiceIds function.

3. Describe each step to reproduce the issue or behaviour.
services.request.query is not available in the cart hook, so we add the cart and price hook to the StoreApiResponseHook and StorefrontHook
{% if services.request.query.foo === 'bar' %}
{# clear the cart #}
{% endif %}
4. Please link to the relevant issues (if any).
5. Checklist

[x] I have rebased my changes to remove merge conflicts
[ ] I have written tests and verified that they fail without my change
[x] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

🤖 Generated by Copilot at de5b40a
This pull request adds new dependencies to the StoreApiResponseHook and StorefrontHook classes to enable cart and price manipulation in the API and storefront. It also updates the changelog file to document the change.

🤖 Generated by Copilot at de5b40a

Add new dependencies to hook classes (link, link)
Document the change and the issue in the changelog (link)

This won't work as the hook needs to implement CartAware for CartFacadeHookFactory::factory to return an instance of CartFacade.  An then the hook needs to be instantiated with the cart. However the hook is dispatched after the cart has already been persisted. So even if you instantiated the hook with the cart, any changes to it would not be persisted. In theory, CartRuleLoader::loadByCart would then have to be called again, to go through all the rule invalidation iterations once more after the possible changes, and finally persist the cart for the second time within the process. This is all way too much to handle imho.
I still feel like adding RequestFacadeFactory to the services of CartHook is viable. Just allow it to return null instead of an instance of Request. It's non-breaking for everyone that already uses it and from then on  it should just be noted that services.request may yield null.

It's non-breaking for everyone that already uses it and from then on it should just be noted that services.request may yield null.

Allright, I will revert the changes and open a new pull request like the one before. Thank you David.

Suggestions to get around master request being null:
Remove the assert in RequestFacadeFactory.
In RequestFacade
public function __construct(private readonly ?Request $request)
{
}

Change all the methods to return nullable.
public function scheme(): ?string
{
    return $this->request?->getScheme();
}

Change all the methods to return nullable.

Could it come to an issue if I return null here?
/**
 * The method `headers` returns all request headers as an array.
 * It is possible to access only the following headers: content-type, content-length, accept, accept-language, user-agent, referer
 *
 * @return array<string, array<int, string|null>|string|null> request headers
 */
public function headers(): array
{
    $headers = array_change_key_case($this->request?->headers->all());

    return array_intersect_key($headers, array_flip(self::ALLOWED_PARAMETERS));
}


Additional steps to fully launch on a new chain

I wanted to provide some notes on what we went through deploying Safe, finally, on the Shyft network, in addition to the steps described to add an official entry in safe-deployments.
I'm not sure that these are sensible as a PR, except maybe safe-global/safe-transaction-service#3:

Nethermind requires additional configuration settings besides just turning off pruning. Bug filed separately about that.
We had to add an entry to cgw.env mapping the chain ID for our chain to the name it is known as at coingecko: prices.chains.7341.nativeCoin=SHFT This was incredibly difficult to figure out.
The default nginx 502 error page is unsightly, and is shown for several minutes while the ui server does a build and run (!).  Separately, the chain logo is not kept in the docker image we upload it to.  These changes address this point:

docker-compose.yml:
add to cfg-web volumes:
      - ./docker/media_chains:/app/staticfiles/chains/

add to nginx volumes:
      - ./docker/pages:/pages

revise docker/nginx/nginx.conf:
server {
...
    error_page 500 502 503 504 /500.html ;
    location /500.html {
        root /pages/;
    }
    location /cfg/media {
        alias /nginx-cfg/staticfiles/chains;
    }
...
}

Create docker/pages/500.html with the desired 500 error page and docker/media_chains/7341/currency_logo.png  (where 7341 is our chain ID) with our chain logo.
Manually log into the cfg-db container, and revise the logo. This is not possible with the django UI as it is.
update chains_chain set chain_logo_uri='7341/currency_logo.png' where id=7341

Thanks for the feedback, we really apreciate it.
Could you link the bug issue that you mentions in the point 1?

When I tried on my install, I can't configure anymore a chain because it throws the error [Errno 2] No such file or directory: '/app/src/media/chains/10242/currency_logo_fETmRCD.png' so it confirms it's not possible to upload the logo with the Django UI but I didn't expect it to break the possibility to configure the chain.

I've made it for the logo without modifying cfg-web by just modifying nginx configuration to serve /cfg/media/chains from a new media-chains mounted volume added in docker-compose.yml
I will create a PR for that to let others review it.


Minimum & Maximum Date Time

how to select minimum & maximum date time

Do you want to select the minimum and maximum time from the UI? I haven't come up with the idea to display it yet, so currently you can only do it grammatically.

How to set minimum date with code?