Clients policies for wildcards in redirect-uris #9278

stianst · 2021-12-21T11:37:00Z

stianst
Dec 21, 2021
Maintainer

Keycloak currently allows wildcards in the redirect-uri by default, and allows any scheme to be used in redirect URLs as well. Some examples of valid redirect-uris that can be configured for clients:

*
https://example.com/app/*
custom://something

This can lead to insecure configurations that are open to a number of vulnerabilities. For more details refer to OAuth 2.0 Security Best Current Practice.

The OAuth 2.0 Security Best Current Practice and OAuth 2.1 adds more restrictions on matching of redirect-uris, and suggests that they should always be a strict string comparison, without allowing any patterns to be registered in the client configuration.

However, there are some use-cases when this strict string comparison is problematic, for example:

Multi-tenant applications that use sub-domains (https://{instance}.theapp.com)
Development environments

In addition the Keycloak client adapters themselves have been implemented badly from this perspective. Keycloak adapters allow any URL of the client to serve as the OAuth callback endpoint, which is the reason for supporting wildcards in the context-path in the first place. According to best-practices there should be a dedicated OAuth callback endpoint (https://myapp.com/oauthcallback for example), while the application can then leverage the state parameter to encapsulate what page the user should be redirect to after handling the callback.

By leveraging client policies we can allow both for security as well as flexibility. Allowing configuring different client policies for different clients. Where examples of options can be:

No wildcards
Wildcard in subdomains
Wildcards in context-path
Open redirect

The Open redirect option should only be available in developer environments, where for the Keycloak.X distribution there is now an explicit option to run the server in production mode or development mode that can enable/disable this option.

The Wildcard in subdomains options should only be enable for clients that explicitly requires this, and should not be enabled by default, or for most clients.

In summary by default in developer mode we should permit wildcards in redirect-uris, while in production no wildcards should be permitted at all, and it should be easy to allow wildcards in subdomains or context-paths for individual clients (or groups of clients) that require it.

The next thing we should consider is the scheme that is permitted. According to best practices custom scheme should not be permitted, and https is the only scheme that should be used. Again, this may be too restrictive in practice, so we should again leverage client policies to allow configuring this. Options for permitted schemes should include:

https only
https and http
Any scheme

In developer mode both https and http should be available, while in production mode by default only https. For native applications that are using custom schemes as redirect-uri they should ideal be improve to not leverage these, but it should be possible for an admin to explicitly allow custom schemes for specific clients.

stianst · 2021-12-21T11:42:19Z

stianst
Dec 21, 2021
Maintainer Author

@mposolda @pedroigor FIY

0 replies

mposolda · 2021-12-22T08:59:15Z

mposolda
Dec 22, 2021
Maintainer

In addition the Keycloak client adapters themselves have been implemented badly from this perspective. Keycloak adapters allow any URL of the client to serve as the OAuth callback endpoint, which is the reason for supporting wildcards in the context-path in the first place. According to best-practices there should be a dedicated OAuth callback endpoint (https://myapp.com/oauthcallback for example), while the application can then leverage the state parameter to encapsulate what page the user should be redirect to after handling the callback.

By leveraging client policies we can allow both for security as well as flexibility. Allowing configuring different client policies for different clients. Where examples of options can be:
* No wildcards

* Wildcard in subdomains

* Wildcards in context-path

* Open redirect

I am not sure if we need also the option Wilcard for fragments ?

My point is, that Keycloak built-in JS applications security_admin_console and account_console use wildcard in context-path right now. But in fact, they don't need context-path, but fragment.

I see the approach you described above (single callback URL for the client with path handled in the state parameter) will work fine for server-side clients. But will this work also for the JS applications?

For example can we do something in our keycloak.js adapter, which will make sure that adapter will "handle" URL like:

http://localhost:8081/console/callback#state=foo&code=bar

and translate it to the URL like:

http://localhost:8081/console/#/realms/myrealm/clients/123

If not, we may need to have this wilcard for fragments option though.

The Open redirect option should only be available in developer environments, where for the Keycloak.X distribution there is now an explicit option to run the server in production mode or development mode that can enable/disable this option.

This is more generic question, but how exactly we detect that Keycloak should use development mode? Will it be strictly hardcoded to the quarkus dev profile? I wonder if some guys want to use more development profiles, which slightly differ in some properties. Hence they have something like dev and dev2 . In this case, we may also want to support something like start --profile=dev2 to be considered as the development mode.

The Wildcard in subdomains options should only be enable for clients that explicitly requires this, and should not be enabled by default, or for most clients.

In summary by default in developer mode we should permit wildcards in redirect-uris, while in production no wildcards should be permitted at all, and it should be easy to allow wildcards in subdomains or context-paths for individual clients (or groups of clients) that require it.

The next thing we should consider is the scheme that is permitted. According to best practices custom scheme should not be permitted, and https is the only scheme that should be used. Again, this may be too restrictive in practice, so we should again leverage client policies to allow configuring this. Options for permitted schemes should include:
* https only

* https and http

* Any scheme
In developer mode both https and http should be available, while in production mode by default only https. For native applications that are using custom schemes as redirect-uri they should ideal be improve to not leverage these, but it should be possible for an admin to explicitly allow custom schemes for specific clients.

6 replies

stianst Dec 22, 2021
Maintainer Author

Also, worth when commenting on discussions to separate different topics into separate comments to make it easier to read and comment on.

mposolda Dec 22, 2021
Maintainer

+1 for the dev profile in separate discussion.

For the JS adapter, it uses redirect_uri parameter with fragment in the OIDC authentication request. So currently it does not work well without wildcard permitted in the redirect URL. So we would need some work for the JS adapter if we want to support redirect URLs without wildcards. And maybe for other adapters as well (depends if we want to support them or we just remove support for server adapters entirely).

Not sure if we need to encode the fragment into the state parameter? We can just save it into JS storage, which allows to lookup fragment (and other things) when the state param is used just as the "lookup key" in the local storage? But this is implementation detail though...

stianst Dec 22, 2021
Maintainer Author

@mposolda If we use fragment in current adapters then I agree we should add this option, but should refactor adapters to not require it, and yes the JS storage would probably be ideal there as we already have an entry associated with each authz request, so can easily add fragment part there if it's not already there. Honestly wonder if we should have a special fragment or something to clearly identify a callback. Like 'https://app.com/#oauth-callback'.

mposolda Dec 22, 2021
Maintainer

@stianst If we use something like 'https://app.com/#oauth-callback', it means that client on Keycloak side will need to be configured with redirect URI like 'https://app.com/#oauth-callback' . Do we want this? There is also option to use our keycloak.js adapter in the "query" mode, which uses query instead of fragment...

Isn't it more clear if redirect URI is configured just as https://app.com ? With such URL, the Keycloak would redirect to something like https://app.com/#state=foo&code=bar, which adapter can process and rewrite to something like https://app.com/#/realms/foo/app-specific-fragment-here .

stianst Dec 22, 2021
Maintainer Author

@mposolda the reasoning behind adding the #oauth-callback is that we don't need to infer that it is a callback based on query/fragment parameters, and also allows the application itself to easily distinguish between a regular request and an oauthcallback. Additionally if you have multiple IdPs (not that we support this right now, but..) then there should be a separate redirect-uri for each.

jangaraj · 2021-12-30T14:34:24Z

jangaraj
Dec 30, 2021

I would like to see option for my current permitted scheme:
any scheme expect http, http allowed only for localhost/127.0.0.1 (allowed localhost IPv4 and IPv6 IPs - we use it in our production, where users are forced to use https, but devs still can develop on the localhost without proper TLS setup

0 replies

JPMoresmau · 2022-07-21T15:37:37Z

JPMoresmau
Jul 21, 2022

The comments on #8187, especially #8187 (comment) are spot-on for our use case here, where we want to deploy our UIs automatically in branches and we have dynamic URLs under our top domain, so allowing wildcards in hosts is a must for testing, and we certainly don't want the too general '*'.

0 replies

Thomasdezeeuw · 2022-07-21T15:39:54Z

Thomasdezeeuw
Jul 21, 2022

To add to that we would like to support Vercel preview deployments. For it's preview deployments Vercel uses a (partially) random subdomain: my_app-*-my_org.vercel.app, e.g. my_app-br13n9dfs-my_org.vercel.app. To actually use these deployment we'll have to use the * wildcard, but that's not ideal (even in staging/testing). It would be really useful for use to be able to support subdomain wildcards, or even a pattern of some kind.

We would also understand that from a security perspective that wouldn't be ideal, but this can be noted in the documentation.

2 replies

graste Jul 27, 2022

For GitLab CI Review Apps one gets similiar URL patterns with the need for * within a subdomain name (depending on requirements and deployment/hosting options).

pedroigor Aug 8, 2022
Collaborator

@mposolda Can correct me if I'm wrong. But client policies should allow conditionally enforce rules for redirect URI. Not sure if the OOTB settings are enough for all cases, but providing custom policy executors can help.

jethrogillgren · 2022-08-16T07:59:17Z

jethrogillgren
Aug 16, 2022

Hi, thanks for considering this feature. I wanted to add another production use case for wildcarding subdomains to hopefully help prioritise this work.

In my case keycloak is almost working great as a single sign on for kubernetes clusters with ISTIO and oauth2-proxy. We have control over our domains, and have new services being spun up dynamically on subdomains multiple times daily. Everything authenticates via Keycloak using a single client. Great!
But the issue is where the Gateway has dozens or hundreds of valid domains: managing keycloaks redirect URIs becomes a nightmare. In the (very common) case where you control your own domain, and want to have single-sign-on across that domain, It seems like you'd want keycloak to trust your root domain rather than having to enumerate every possible subdomain?
Our current planned workaround is to have a script watching the list of subdomains used (which we can get from ISTIO VirtualServices), and automatically update the redirect URIs when new subdomains are added... but this involves an automated tool getting access to the keycloak admin console which isn't ideal. Alternatively we could teach every service we deploy to create their own keycloak clients, but that would double the complexity of many of our microservices.

Any ideas on better approaches would really be appreciated.

2 replies

pedroigor Aug 16, 2022
Collaborator

Is it a good thing to share a single client to different domains and potentially different services? I would guess you are doing that to avoid complexity and managing those services, right?

W.r.t. to the redirect URIs, considering your use case it would be nice if we could have a custom client policy executor that dynamically resolve and validate URIs based on queries to Kube APIs.

jethrogillgren Aug 16, 2022

I would guess you are doing that to avoid complexity and managing those services

Yeah correct, we have ISTIO/oauth2-proxy with its own client intercepting requests and doing all the auth, and every service behind that "auth wall" then only receives authenticated requests. We set that client up once when deploying our cluster, and then our dynamic changes to the services being run/hosted there don't need new clients being added/removed constantly.

Most services don't know anything about the auth wall in front of them (except ones that need to read authorization information). If they all had their own keycloak clients, I guess they'd then also all need their own ISTIO gateway and deployment logic to configure keycloak when being deployed.

Yeah, an external lookup for a list of approved URIs would be ideal!

lexcao · 2022-08-16T16:23:58Z

lexcao
Aug 16, 2022

I'd like to add 2 use cases from my side.

Case 1
There are a few testing env and domains, which are

https://testing-a.mydomain.com/redirect-uri
https://testing-b.mydomain.com/redirect-uri
https://testing-c.mydomain.com/redirect-uri

Can I configure it like testing-{wildcard}.mydomain.com/redirect-uri?

Case 2
For development only, the front end may have different ports for localhost, which are

localhost:8080/*
localhost:8000/*

Can I configure it like localhost:*/*?

0 replies

kherock · 2022-09-07T01:23:31Z

kherock
Sep 7, 2022

I'm in the process of migrating some applications from Auth0 onto a Keycloak platform. We're used to being able to specify a wildcard in the subdomain that we use for various testing environments on a non-production tenant. I think the rules around its usage sound reasonable to me: https://auth0.com/docs/get-started/applications/wildcards-for-subdomains#wildcard-url-placeholders

I'm trying to recreate the same ability in a non-production Keycloak realm, but it looks like I'd have to use * to accomplish this without some serious refactoring of our deployment infrastructure. I don't have any need for wildcards in any other part of the URL!

1 reply

silviokennecke Sep 9, 2022

Hi, I created a PR for that. It's currently on hold, as the redirect uri should first be covered by client policies, so administrators can prohibit wildcards. @stianst just noticed a PR which allows specifying regular expressions for the verification of redirect uris.

Wildcard hostname PR: #14118
Regex redirect uri client policy PR: #8236

stianst · 2022-09-09T09:35:12Z

stianst
Sep 9, 2022
Maintainer Author

Is anyone interested in working on this one? I don't think it would take all that much effort to get something sorted out. I think we can break this into:

Redirect URI Client Policy Executor

Implement a configurable Redirect URI client policy that allows configuring the policy around redirect-uris, maybe options like:

Option	Type	Default	Notes
Allow Private-Use URI Scheme Redirection	boolean	false	https://www.rfc-editor.org/rfc/rfc8252#section-7.1
Allow Loopback Interface Redirection	boolean	true	https://www.rfc-editor.org/rfc/rfc8252#section-7.3
Allow HTTP	boolean	false
Allow wildcard in context-path	boolean	true	Mainly for compatibility with Keycloak adapters
Permitted domains	List		List permitted domains, with support for regex, if enabled will allow wildcard in hostname, and check that configured redirect-uri matches one of the patterns
Allow Open Redirect	boolean	false

The client policy would only check the configured redirect-uris for a client when created or updated.

Support wildcard in host

Make it possible to configure a redirect-uri with a wildcard in the hostname part. I think this is basically what #14118 has done.

Additional client policy conditions

We may want some addition client policy conditions for example by client-id like what's done in #8236

Out of the box configuration

We should probably consider adding some out of the box configuration around this, maybe some built-in client policy profiles. Maybe also have something enabled by default for all clients, and perhaps that could vary if you are running in dev-mode (start-dev) or prod mode (start).

5 replies

lexcao Sep 10, 2022

Hi, @stianst
I am interested in this.
I have not implemented such a new feature since I joined the community, I wanna give it a try.

Where should I get started?
The following steps I think could be:

create an issue
make some detailed designs about features and code
clarify some opening questions from the design
coding
reviewing

stianst Sep 12, 2022
Maintainer Author

I'd break it into the steps I mentioned, and open separate issues for those, with separate coding/PRs for each.

Basically:

Executor that allows configuring the policy
Allow wildcards in hostname (we already have a PR for this)
Figure out how it should be configured by default
See if some additional client policy conditions are needed to make it all manageable

lexcao Sep 13, 2022

Issues are created. #14380
I am going to add a more detailed design for Redirect URI Client Policy Executor.

1-alex98 Jan 8, 2024

@stianst 4. -> #25956

1-alex98 Jan 8, 2024

@stianst @mposolda

Is anyone interested in working on this one?

Would also be really interested. #25956 and #14659 are the first two steps to the solution. But I am worrying a little if you will acctually look at my PRs and whether I will do all the work for nothing.

grstreten · 2023-02-16T13:30:43Z

grstreten
Feb 16, 2023

After this too, for compatibility with Coolify PR previews, formatted as [pr-number].[primaryfqdn]. Consider this my '1 up'! 👍

0 replies

ClintonMorrison · 2023-03-24T20:07:54Z

ClintonMorrison
Mar 24, 2023

Hey everyone! Is this still being worked on? I'm very interested in being able to use wildcards in the hostname for a multi-tenant app, e.g. *.app.com

I'd be happy to help too!

0 replies

slominskir · 2023-05-10T19:00:12Z

slominskir
May 10, 2023

Tangentially related: the Elytron client built into Wildfly has decided to simply strip query parameters from the redirect_uri (client-side) in response to the OAuth Best Practices mentioned above. That obviously causes havoc (and still is). See: https://issues.redhat.com/browse/WFLY-17324 and https://issues.redhat.com/browse/ELY-2340

0 replies

pedroigor · 2023-05-18T17:53:18Z

pedroigor
May 18, 2023
Collaborator

Are there people using response_mode=form_post when using the authorization code flow in mobile apps? Or POST is not supported at all?

0 replies

aelgn · 2023-05-31T11:30:35Z

aelgn
May 31, 2023

Hey. Being able to use wildcard for subdomain is very interesting to us. Being able to provision nodes (xyz.app.qwop.com) without also editing the oidc client configuration would be wonderful.

Is there any movement on this @stianst ?

0 replies

vlgutv22 · 2023-06-15T13:05:41Z

vlgutv22
Jun 15, 2023

Hi! Being able to use wildcard for subdomain is very crucial to us. @stianst any updates here?

1 reply

Yayg Jul 10, 2023

Hi and thanks to all this community for bringing such great tool by the way :)

Is this issue limited to wildcard on subdomains or does URIs beggining with a wildcard in general?

I see some usecases where we don't necessarily have the possibility to make subdomains and need to gather multiple environments suffixed by something like "-environmentA.example.com"
So being able to wildcarld like: "*-environmentA.example.com" in redirect uris and web origins would be useful.

Also is there a plan to add this feature in any of the next releases?

Thanks for any answer!

saalihou · 2023-07-12T11:32:19Z

saalihou
Jul 12, 2023

Here is another use case, we use deploy previews for netlify which have the following stucture:
https://deploy-preview-9--my-app.netlify.com. Obviously the deploy-preview-9 part is generated automatically and incremented on each PR. Right now for every PR we would have to add the deploy preview URL to the redirect URIs.

0 replies

alexted · 2023-07-13T14:16:53Z

alexted
Jul 13, 2023

Good afternoon, honored ones! This topic is already a year and a half old. Could you please tell me if there is any solution to this issue? I would like to be certain about the issue.

0 replies

alexdelprete · 2023-09-23T17:08:07Z

alexdelprete
Sep 23, 2023

No updates for #14380. So I guess the implementation never really started. Subdomain wildcards are an important missing functionality, I can't switch to Keycloak until it's implemented. And I bet many homelabbers are in the same position. Hope there will be some progress...thanks for creating Keycloak, it's a nice product, hope one day I'll be able to replace Authelia with it. :)

0 replies

naglm · 2023-11-20T13:44:34Z

naglm
Nov 20, 2023

The ability to use wildcards in redirect URIs would be also of great importance to us. +1 on this topic 👍

0 replies

markusmoormann · 2023-11-24T13:52:15Z

markusmoormann
Nov 24, 2023

is there any ETA on the wildcard topic (espacially for the hostname part)? I've read all related discussions but I'm not sure what's next. I would be able to contribute if help is needed

5 replies

1-alex98 Feb 22, 2024

few month for keycloak 24. #25637 There you can register regexes for domains if that is what you are looking for

markusmoormann Feb 23, 2024

I'm not sure if this allows wildcards for subdomains? I want to allow *.mydomain.com as valid redirect Urls

1-alex98 Feb 23, 2024

I think it should. Allows regex for domains

1-alex98 Feb 23, 2024

https://github.com/Hitachi/keycloak/blob/748200165d02c7eea67789a28c654ca05488d1ea/services/src/main/java/org/keycloak/services/clientpolicy/executor/SecureRedirectUrisEnforcerExecutorFactory.java#L136

markusmoormann Feb 23, 2024

nice, thanks a lot for searching

1-alex98 · 2024-02-22T13:22:53Z

1-alex98
Feb 22, 2024

Seems like #25316 will solve most if not all issues discussed here in keycloak version 24

2 replies

markusmoormann Feb 28, 2024

is there already a release date for Keycloak24?

1-alex98 Mar 8, 2024

turns out it is not fully implemented

christophenoel · 2024-02-27T14:36:15Z

christophenoel
Feb 27, 2024

Seems like #25316 will solve most if not all issues discussed here in keycloak version 24

Very interesting but I don't see such subdomain wildcard related to OAuth 2.1

4 replies

1-alex98 Feb 28, 2024

https://github.com/Hitachi/keycloak/blob/748200165d02c7eea67789a28c654ca05488d1ea/services/src/main/java/org/keycloak/services/clientpolicy/executor/SecureRedirectUrisEnforcerExecutorFactory.java#L136

1-alex98 Feb 28, 2024

it does not say so directly in the issue but if you look into the code ...

andrew-definely May 14, 2024

As far as I understand enforcer is a validator for when editing a client - it doesn't enables wildcard subdomains during login flow

1-alex98 May 15, 2024

yes. that's the issue

christophenoel · 2024-02-28T09:05:52Z

christophenoel
Feb 28, 2024

Thank you very much, I see.

            .helpText("If some domains are filled, the redirect uri host must match one of registered domains. " +
                "If not filled, then all domains are possible to use. The domains are checked by using regex. " +
                "For example use pattern like this '(.*)\\.example\\.org' if you want clients to register redirect-uris only from domain

7 replies

1-alex98 Mar 8, 2024

#14118 But it was closed with reference to #25637

1-alex98 Mar 8, 2024

Maybe closing it with respect to #25637 was a mistake

bakerdr Mar 8, 2024

Yea thanks @1-alex98, I forgot to mention the reason I expected wildcard subdomains to be working in 24.x was due to #14118 being closed in reference to this.

1-alex98 Mar 8, 2024

same

krankkkk Aug 1, 2024

@stianst Are you aware that this is still not implemented?

christophenoel · 2024-03-08T11:36:42Z

christophenoel
Mar 8, 2024

Damn, I was waiting for it :)

2 replies

1-alex98 Mar 8, 2024

same

1-alex98 Mar 8, 2024

But I think maybe something like #14118 is the only missing part 🤔
Maybe @mposolda knows what now is missing to get our beloved wildcards in subdomains

ishaiboro · 2024-10-28T10:22:20Z

ishaiboro
Oct 28, 2024

Any progress here? thanks 👍

2 replies

1-alex98 Oct 29, 2024

Opening a issue ticket explain the situation to get attention would probably be the thing to do....

1-alex98 Oct 29, 2024

No progress

Lonzak · 2025-03-31T13:22:58Z

Lonzak
Mar 31, 2025

I am interested in the progress, too. Didn't read all the PRs, Issues and the like which seems quite extensive. To allow subdomains like *.domain.com/* is a vital feature for keycloak. But it seems that support for subdomain wildcards is not coming...?

For us this is really cumbersome since a partner is hosting the service with a keycloak. So we have to write them every time a new system is installed so that they add it to the client:

systema.domain.com/app
systemb.domain.com/app
...
systemz99.domain.com/app

0 replies

SniperCZE · 2026-03-12T12:40:00Z

SniperCZE
Mar 12, 2026

Hello,
is there any progress/ETA about allowing wildcard/regex in redirect uri hostnames? With a NIS2 arriving on place, we have to implement OIDC and SSO on many internal systems and enumerate all of them is....non-sense.

0 replies

aqeelat · 2026-03-31T11:32:12Z

aqeelat
Mar 31, 2026

I opened #47570 to solve this issue.

0 replies

Ketec · 2026-11-06T12:22:09Z

Ketec
Nov 6, 2026

Looks like there is still no progress. Adding dozens or 100s of subdomains not only is very manual work heavy, it also bloats JWT - they become massive with all the individual URLS present.

This further leads to header size issues.

0 replies

Clients policies for wildcards in redirect-uris #9278

Uh oh!

Uh oh!

stianst Dec 21, 2021 Maintainer

Replies: 29 comments · 39 replies

Uh oh!

stianst Dec 21, 2021 Maintainer Author

Uh oh!

mposolda Dec 22, 2021 Maintainer

Uh oh!

stianst Dec 22, 2021 Maintainer Author

Uh oh!

mposolda Dec 22, 2021 Maintainer

Uh oh!

stianst Dec 22, 2021 Maintainer Author

Uh oh!

mposolda Dec 22, 2021 Maintainer

Uh oh!

stianst Dec 22, 2021 Maintainer Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pedroigor Aug 8, 2022 Collaborator

Uh oh!

Uh oh!

Uh oh!

pedroigor Aug 16, 2022 Collaborator

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stianst Sep 9, 2022 Maintainer Author

Redirect URI Client Policy Executor

Support wildcard in host

Additional client policy conditions

Out of the box configuration

Uh oh!

Uh oh!

stianst Sep 12, 2022 Maintainer Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stianst
Dec 21, 2021
Maintainer

Replies: 29 comments 39 replies

stianst
Dec 21, 2021
Maintainer Author

mposolda
Dec 22, 2021
Maintainer

stianst Dec 22, 2021
Maintainer Author

mposolda Dec 22, 2021
Maintainer

stianst Dec 22, 2021
Maintainer Author

mposolda Dec 22, 2021
Maintainer

stianst Dec 22, 2021
Maintainer Author

pedroigor Aug 8, 2022
Collaborator

pedroigor Aug 16, 2022
Collaborator

stianst
Sep 9, 2022
Maintainer Author

stianst Sep 12, 2022
Maintainer Author