movewindow dispatcher and noborder window rule

System Info and Version
 System/Version info
Hyprland, built from branch  at commit cba1ade848feac44b2eda677503900639581c3f4  (props: bump version to 0.40.0).
Date: Sat May 4 15:42:32 2024
Tag: v0.40.0, commits: 4606

flags: (if any)

System Information:
System name: Linux
Node name: aphe-pc
Release: 6.9.3-4-cachyos
Version: #1 SMP PREEMPT_DYNAMIC Sat, 08 Jun 2024 12:08:37 +0000

GPU information:
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [Radeon Vega Series / Radeon Vega Mobile Series] [1002:1636] (rev c2) (prog-if 00 [VGA controller])

os-release: NAME="CachyOS Linux"
PRETTY_NAME="CachyOS"
ID=cachyos
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://cachyos.org/"
DOCUMENTATION_URL="https://wiki.cachyos.org/"
SUPPORT_URL="https://forum.cachyos.org/"
BUG_REPORT_URL="https://github.com/cachyos"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=cachyos

plugins:

Bug or Regression?
Bug
Description
I use these keybinds :

bind = $mainMod, left ,movewindow, l
bind = $mainMod, right ,movewindow, r
bind = $mainMod, up ,movewindow, u
bind = $mainMod, down ,movewindow, d

and these rules

windowrule=float,title:^(.Picture-in-Picture.)$
windowrule=noborder,title:^(.Picture-in-Picture.)$

For tiled windows everything works as expected. But for floating window, the movewindow right doesn't work. The 3 others directions works as expected.
How to reproduce
windowrule=noborder,title:^WINDOW$
bind = $mainMod, right ,movewindow, r
and try to move the floating window without border
Crash reports, logs, images, videos
No response

https://github.com/hyprwm/Hyprland/assets/25272247/ca6b01fb-1cdb-4058-b755-4c55f4018ee3
don't know why bordersize reset but anyway


Release v5.2

Added IbanCountry.NativeName property which returns the country name in native language, if available.
Changed the IbanCountry.DisplayName property to return the native name, if available; otherwise returns the English name.
Regenerated WikipediaRegistryProvider to include Sudan (SD).
Implemented IEquatable<T>.
Implemented IFormattable with format strings E, P and O for Electronic, Print and Obfuscated respectively.
Upgraded registry to October '21 release 91 (added Burundi (BI) and updated Sudan (SD))

Codecov Report

Merging #55 (57517f5) into master (ce67132) will decrease coverage by 0.24%.
The diff coverage is 97.22%.

Impacted Files
Coverage Δ

src/IbanNet/Registry/IbanCountry.cs
96.15% <0.00%> (ø)

src/IbanNet/Iban.cs
83.78% <100.00%> (-3.32%)
:arrow_down:

src/IbanNet/Validation/Rules/IsValidLengthRule.cs
100.00% <100.00%> (ø)

src/IbanNet/Validation/Rules/Mod97Rule.cs
92.30% <100.00%> (ø)


[10.x] Bring translatable error messages to closure based rules

This PR brings the translatable validation error messages from the Invokable validation rule to Closure based rules for the next version of Laravel.
public function rules()
{
    'foo' => [
        function ($attribute, $value, $fail) {
            $fail('validation.translation.key')->translate();
        },
    ],
}

Targeting master as I feel there are two (minor) breaking changes here...

Calling $fail more than once now appends to an array, so if you were calling it twice in a closure (which is probably a bug where you forgot to return), the behaviour would change.
$fail now returns an object , rather than void / null, so if you have typehinted your closure and are returning the result of the $fail call, it would break.

What's the benefit of passing a translation key as a parameter and then calling the "translate" method on the result over just $fail(trans('validation.translation.key'))?

@timacdonald I'm also a bit curious about the question above

Hey folks, sorry I didn't reply sooner. Got side tracked. So this was my reasoning as to why I wanted to introduce this functionality.

Translation is a first party concern for validation errors, yet there is no affordance given for rules to perform such translation. The only option we have is reach out into the global world with helpers, facades, etc. This is, as we know, functionally the same, but it forces you to do this. I love that Facades and global helpers exist (love 'em in my views), but I also love the "you can use them if you want to" approach that Laravel provides. So this functionality is about promoting a first-party solution for translating validation error messages. You can still use helpers if you want, or you can use this solution.
It is not a 1:1 mapping to $fail(trans('validation.required')), as the trans helper is lax. The new functionality is the opposite. It is strict, ensuring that the user does not actually see the validation error "validation.required", when it should have seen the translated "Is Required". The $fail()->translate() functionality is strict and will throw an exception when there is no translation present. I've seen this plenty of times and would love to not silently fail so it can be addressed.
The way I see it, Validation objects are value objects...

return [
    'options' => new InRule([5, 6, 7])
];

Having value objects rely on global state or be half value object / half service object by injecting the translater itself is clunky as heck - yes, this is possible as the rules() method does support dependency injection, but it feels hacky and weird to me.
public function rules(Translator $translator)
{
    return [
        'options' => new InRule([5, 6, 7], $translator)
    ];
}

Hopefully you can see how this is, IMO, a valuable addition to the framework.
$fail('rant.over')->translate();

@timacdonald @taylorotwell might it be worth a thought to think about how this could include parameters and pluralization? As far as I can see this approach only supports single-fixed translation strings. So one would still have to use both (translate method on the result and global helpers when using parameters and pluralization)

@dennisprudlo see https://github.com/laravel/framework/pull/42689


Basic Level: Completed

https://github.com/askeroff/rejection
https://askeroff.github.io/rejection/
I am not really comfortable with the result. I used TDD for the first time and I'm not sure how correct it is. At some point, I thought, I should've used React or something. Maybe if I'll decide to go on and advance this app, I will.
For now, will appreciate any feedback.

Cool UI!
UX design
The explanation really only needs to be seen the first time you run the app -- after which you should be able to dismiss it completely. Try looking at the app on your cell phone -- the form should be front and center with the call to action (accept/reject) buttons clearly inviting users to add questions.
Instead, the screen is dominated by text that doesn't need to be there after the first time the user has seen it.
I recommend designing your UI using a mobile view by default, which you can emulate in Chrome Dev Tools. Make sure it looks good on mobile, first -- particularly because this is a game you should take everywhere with you so you can add questions as they are asked and answered in the course of your day.
Separation of concerns
I noticed you have a bunch of unit tests that look roughly like this:
  it('checkScore should give the right score for accepted and rejected buttons', () => {
    const inputFirst = addElement('input');
    const inputSecond = addElement('input');
    inputFirst.className = 'accepted-button add';
    inputSecond.className = 'rejected-button add';

    assert.equal(1, checkScore(inputFirst), 'should give 1 for accepted');
    assert.equal(10, checkScore(inputSecond), 'should give 10 for rejected');
  });

The problem with this test is that you're testing domain logic:

Given an accepted or rejected answer, what should we add to the score?

Why then are we manipulating the DOM to do it? The reason is that you're using the DOM to store and retrieve application state. The problem is that the DOM is like a giant global variable. Anything can reach out and mutate it at any time, and those manipulations may change the results of calling this function.
Ask yourself: Does calculating a score have anything to do with the state of what's being drawn to the screen?
The answer is No. You could have a list of questions in an array, with answers. You could calculate the score by reducing over that array and adding up the results, so you know the complete app state before you ever draw to the screen -- in fact, being able to load and save state in an explicit requirement.
Domain logic, such as state calculations, should be made up of pure functions -- that means they can't rely on external mutable state such as the DOM. See "What is a Pure Function?".


Use nuke on bosses on high levels (if not raining gold level)

Anyone assigned to this one yet?

Feel free to take it

What level should I use to start triggering this?

See CONTROL.speedThreshold

This one can be closed as it implemented with https://github.com/SteamDatabase/steamSummerMinigame/pull/241


switch to gpt35

We're using 4o right now but I think 3.5turbo would be just as good for our use case, cheaper, and of course less resource intensive.

all set https://github.com/learntocloud/azure-project-generator/commit/e7f8eba89f1c2d6fb2442c6b32eeedd97559688c


ZUN -Bad Apple!! (ft nomico)

Song Name
Bad Apple!!
Artist Name
ZUN (ft. nomico)
Source
Youtube
Youtube Link
https://www.youtube.com/watch?v=FtutLA63Cp8
Direct File Link
No response
Song ID
10011422
Start Offset [ms]
No response
Extra
Used in 109046518
https://x.com/Masterous112/status/1823821885899211182?t=02C5xo-GvsvC4th6hgaZ0A&s=19

accept

accept


Slow relations initialization

Context
PostgREST version : <IP_ADDRESS>
PostgreSQL : 9.6.3
OS : Gentoo & RHEL 6.9
The source of the problem is unclear and I cannot provide a simple reproducible case.
( I provided @ruslantalpa with a minimal database dump )
Observation
On a particular database, requesting resource embedding for the first time causes a significant computation over a long period of time. On the sample provided, it takes ~30sec on my box and PostgREST was using ~40% of CPU load the whole time. Although that was after a cleanup, before I simply didn't wait long enough (> 10min). The query itself seems unimportant, as asking for an invalid relation triggers this problem. Hence, the exposed schema to test this simply contains one table such as
create table my_api.test ( col int );

And the problem happens when issuing a query like
curl 'http://localhost:3000/test?select=*,test(*)'

Debugging
Everything involves the whole database and does not involve the schema exposed to PostgREST.

Trying to scope down the cause, it was found that :

Dropping one specific table completely removed the delay, albeit the table is nothing special at first glance
Dropping a couple views in a particular schema improves the delay gradually

Requesting for a single entity while PostgREST is under this computation works without any delay.

With a bit more troubleshooting and a dose of luck, I have found the potential culprit.
The table which caused the problem to disapear contains 2 foreign keys which are exactly the same reference, they only have different names. Of course this is an error and shouldn't be there, but by dropping any of the two, the problem goes away.
Now I tried recreating a simple case with only 2 tables, but it does not cause any noticeable delay.
My guess is that it probably starts to mess up when there are a certain amount of references to be analyzed.

Interesting case, although i think there are valid cases for 2 Fks to the same table so this still is interesting to investigate.

After more testing it seems my assumption was incorrect, the problem is likely related but not exactly caused by identical FK duplicates.
I could find out by diffing a local database that I had fixed doing this with a preproduction version that was slightly altered from my version, where the problem still showed up after applying the above change.
In the diffing process, I found a FK that after being dropped, fixed the problem again. But this is a valid FK constraint that applies on a different column of the constrained table, but to the same reference.
The FK is on a character(8), that's the only particularity I can see.
Again I'm not able to reproduce with a minimal case ...
Another finding was that dropping all the RULES on a test improved the init time from 12s to 3s.
So it seems like there is a relation in the graph that causes everything else to slow down by an important factor.
At this point, Im going to start learning some haskell and dive into the code !

Here's a profiling of an unfinished initialization of a few seconds :
COST CENTRE                         MODULE                SRC                                            %time %alloc

addManyToManyRelations.combinations PostgREST.DbStructure src/PostgREST/DbStructure.hs:256:5-63           86.4   99.4
addManyToManyRelations.links        PostgREST.DbStructure src/PostgREST/DbStructure.hs:253:5-117           6.0    0.0
addManyToManyRelations              PostgREST.DbStructure src/PostgREST/DbStructure.hs:(251,1)-(265,29)    5.8    0.0

Something odd to me, is that many-to-many takes so much time, but when I drop a FK that is a one-to-many, to problem disappears. After dropping that constraint, none of the sections above appear in the profiling.

This is a very good lead, at the root of combinations we have subsequences
The subsequences function returns the list of all subsequences of the argument.
subsequences "abc" == ["","a","b","ab","c","ac","bc","abc"]

which would be very inefficient on big arrays.
In this particular case, i think big arrays happen when there is a specific table with relations to multiple other tables, i.e. many of its columns are FKs to other tables.
I'll confirm that with your schema (you can also do that) then we'll think of another way to write that function which more optimal

I placed a Debug.Trace at the exit of subsequences, I will try to compare the results when that FK is present vs not.

Now, we found out that the definition of addManyToManyRelations.combinations can be improved for cases where alot of relations have to be computed.
I will try a some alternative definitions and compare them, then I'll open a PR.

After reading #796, it reminded me of a thought I also had;
If it would be possible to make allRelations (or create a new request if needs be) return only relations that are linked with the exposed schema ?
The problem is not so much the query itself, but rather how it can leverage the mapping done by addManyToManyRelations so that the minimum required relations are fetched.
If I compare some metrics I collected with changes in #926 between 2 databases :

allRelations [count]
Startup time approx. (first query) [ms]

51
12

458
331

Ratio~
9
28

It simply shows that the time doesn't scale linearly with the amount of relations, and more importantly, independantly of the exposed schema. If at least it would scale directly with the relations exposed by the schema, it becomes easier to control the complexity and even to draw a parallel between what you control and the impact on the initialization.
This is just a thought, and I also consider this idea to be potentially overkill, and having a negligible benefit.

Negligible effect, for 1 request. This is overthi king it. It's good as it is now

Fixed in #926


When site is updated and staticData json files change, application requests missing files

Is this a bug report?
Yes / kind of?
Environment

React Static: v5.1.8
Node: v8.9.0
Yarn v1.3.2 / NPM v5.6.0

OS / Browser: any, I'm on Chrome & Safari on OSX 10.13.3
Steps to Reproduce / Example / Explanation
I have a route, eg:
/my-routes/route-1

And when I build and deploy, information about that route ends up at
/staticData/random-hash.json

But when the content changes and I rebuild and redeploy
/staticData/different-random-hash.json

This becomes an issue in a browser when an existing session is running, when browsing, the browser continues to request non-existent files.
Error: There was an error retrieving a prop for this route! hashID: Z1OkurK
main.7bf4f1fc.js:6 Error: Request failed with status code 404

But this happens once for each page in the site, so in this case 120 times on navigating to a page.
Additionally, incomplete data is passed to react components which triggers errors in those components.

On speaking in the Slack group

tannerlinsley [1:55 PM]
It sounds like the route info file needs a hash suffix

For which I will open a pull request in a moment...

Should be fixed now :)


Federated identity credentials support for wildcards

Is your feature request related to a problem? Please describe.
We are porting  our product from AWS to Azure and in AWS you can use wildcards in your trust relationships between your serviceaccount and a role (similar to azure ad application in azure) as follows:
  statement {
    actions = [
    "sts:AssumeRoleWithWebIdentity"]
    effect = "Allow"

    condition {
      test     = "StringLike"
      variable = "<oidc_url>"
      values = [
      "system:serviceaccount:environmentprefix-*:saprefix-*"]
    }

    principals {
      identifiers = [<oidc_arn>]
      type = "Federated"
    }
  }

Is this something that you are considering as well? At the moment it is rigid to work with federated identity credentials in Azure:

1 ad application can only have 20 federated identity credentials
you need to create a federated identity credential when deploying an application to a different aks environment.

Describe the solution you'd like
It would be great if the federated identity credential had support for wildcards to for example allow multiple environments or allow creating a dedicated service account for each pod.
An example of a credential could be as follows:
resource "azuread_application_federated_identity_credential" "app" {   application_object_id = azuread_application.object_id   display_name          = "uuid"   audiences             = ["api://AzureADTokenExchange"]   issuer                = var.oidc_issuer_url   subject               = "system:serviceaccount:*:service_account_name-????" }
wildcard support: * for any string or ? for 1 random character
Describe alternatives you've considered
The other path we are thinking of is managing the federated identity credentials using a kubernetes operator. This way we can dynamically create the federated identity credential, when an application is deployed to a new environments.
Issues we see there are:

We could bump to the limit of only allowing 20 federated identity credentials per ad application.
Our clients might want to keep control over the federated identity credentials that get created for an azure ad application.
We notice a delay between the creation of federated identity credential and when it can be used, this might impact the jobs being launched on a new environment.

Additional context

I really need this. I was going to go down the creating of federated credentials but the limit of 20 is going to kill me. I need my pods to use different service accounts and sometimes these are dynamically created.
Anything you can do to add in support on AAD side to allow wildcards on this would be HUGE! Thanks.

@aramase I see you added the label aad -- is there a change this gets supported, especially since this has nothing to do with the kubernetes webhook and everything to do with the aad side of things in Azure? Thanks!

Thank you for the feedback. I've shared this issue with the AAD team and will update the issue here once I hear from them.
cc @udayxhegde

@aramase any update from the AAD team? Thanks.

@ekristen thanks for the feedback! We will consider this support in our future planning cycles. Right now, we are heads down on completing the work needed to allow customers to use this capability in production for both app registration and managed identities.

@udayxhegde appreciate the information and that you are heads down. I think without supporting wildcards you are going to extremely limit people's ability to use this. Service Accounts are often created in larger quantities per workload even to help with permission restrictions and other needs, not being able to wildcard service accounts is very very limiting.
Has there been any further discussion in supporting this and if so any ETA? Thank you.

Hi @ekristen : thanks for your feedback. In our initial release we will not be able to support wildcards unfortunately. The additional support in the form of wildcards or custom claims is indeed very important: but there's no ETA for that support.

@udayxhegde alright, that's unfortunately. I'll have to fallback to using secrets or certificates, with the limit of 20 federated identities and no wildcards, while this is the preferred way to auth, it's not usable which is unfortunate. If there's someone I can elevate this to to get higher priority via my company, please let me know. Thanks.

@ekristen : are there no other options to consider here? Since each pod can only use one service account, what is causing you to intentionally use different service accounts or create them dynamically? I am sure there is a good reason why this is being done, just trying to understand it.

changing by that order of magnitude is not practical: another alternative is to use multiple service principals, but that is not easy to manage either.

The wildcard is the best approach and least amount of work for the Azure team by far. I'm unfortunately going to have to use certificates or shared secrets until wildcards are supported which is a huge bummer. Hopefully it won't take long to implement, it's not a very complex mechanism and is going to unlock you and your customers a ton to do more amazing integrations.

@udayxhegde following up on this, I thought of another user-case/reason this is needed. For teams that are helping to manage or do things in multiple tenants.
Use Case: I'm a company with a product to help people with Azure, our software is deployed and managed on k8s and needs to use a single service principal (or two) to talk to dozens if not hundreds of other tenants.
AZWI would be the best from a security perspective, but since only the service account can change the tenant being targeted, and since wildcards aren't supported and the limit on federated identities is 20 this can't be used, unfortunately that means hard coded certificates or secrets. :(

@udayxhegde any movement on this feature request?

Just hit this after a few GitHub repos converted. What's the recommended best practice for a GitHub repo? One per repo? Was hoping one per team would be sufficient, especially when the team repos would be given the same permission to Azure and app resources.

You have to do one federated identity per repo and limited to 20 per app, then you have to create another one. Unfortunately this is a very painful feature to use.

@udayxhegde is there anyone we can elevate with this on the Azure side and put in direct contact with. To be very honest, this feature is useless at scale.  Without wildcard support, it's just easier and better to use hard coded client secrets/certificates which is a shame.

Hey @ekristen - would you maybe be willing to have a chat with me on this? I'm not on the Azure Identity team, but I am the PM for Workload ID at Microsoft, so I'd really love to be sure I've got your use case well understood and documented to maybe help push this forward.
If you're on Kubernetes Slack you're welcome to ping me there (@Xander), otherwise xgrzywinski @ microsoft.com

Hey @ekristen - would you maybe be willing to have a chat with me on this? I'm not on the Azure Identity team, but I am the PM for Workload ID at Microsoft, so I'd really love to be sure I've got your use case well understood and documented to maybe help push this forward.
If you're on Kubernetes Slack you're welcome to ping me there (@Xander), otherwise xgrzywinski @ microsoft.com

Absolutely! I'll reach out.

Sorry @ekristen for the late reply... I recognize this capability is important to manage things at scale, but unfortunately, we don't have any updates on this yet.

This is holding me back as well. We deploy resources dynamically at request with a pre-existing managed identity. The namespace name is dynamic and is unique for each deployment. The service account is created in this namespace. It is really cumbersome to have to create/delete the federated identity credential for each deployment, and of course there's the limit of 20 credentials. A wildcard for the namespace name would fix this problem.

I had a call with a PM a few months back on this. I said match what AWS does, allow wildcards anywhere, or StringLike matching. This is still a HUGE pain point.

@salaxander So no plan for implementing this for now? Is there a workaround?

@kevinharing I had a call with a product person from Microsoft to explain the situation and they seemed responsive. Unfortunately that was 6+ months ago.  I unfortunately have taken the position that this will never be addressed.

@kevinharing @ekristen Sorry for the confusion here folks! I did remove this from our roadmap project board because the limitation is on the AAD side, and so it's not an actionable feature item on our roadmap. I have been told by AAD that they will support wildcards though. I don't know a timeline, but I do know that it they are planning to do it. I'll pin this issue on the repo though for visibility.

@kevinharing @ekristen Sorry for the confusion here folks! I did remove this from our roadmap project board because the limitation is on the AAD side, and so it's not an actionable feature item on our roadmap. I have been told by AAD that they will support wildcards though. I don't know a timeline, but I do know that it they are planning to do it. I'll pin this issue on the repo though for visibility.

Thank you for the quick reply!

@kevinharing wildcards is very necessary. For now, we have multi(more than 20) namespaces in aks. Within all of these namespaces, we need to access different Azure Resources. Besides, these namespaces have same prefix naming.
However, we hope to only aissgn credential in single 3rd party app. we don't want to create multi 3rd party app, which will be very hard to manage.

A recent feature release in Terraform now allows for the use of OIDC auth with Azure and required a federated credential and this limit of 20 has quickly become an issue.  We need the wildcard capability to be prioritized quickly as this is a huge hold up on our deployment of using OIDC with Terraform Cloud.  https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/azure-configuration

Where can we elevate our request for AAD supporting wildcards and increasing the maximum credentials in flight per identity? My client wants to use user managed identities rather than application registrations due to access concerns (subscription owner level access is not sufficient to create applications and service principals for role assignment and group membership). The limitations discussed at length above are a blocker for us as well.

A recent feature release in Terraform now allows for the use of OIDC auth with Azure and required a federated credential and this limit of 20 has quickly become an issue. We need the wildcard capability to be prioritized quickly as this is a huge hold up on our deployment of using OIDC with Terraform Cloud. https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/azure-configuration

Facing this exact same issue, the absence of wildcards combined with the limit of 20 federated credentials per app registration makes this feature pretty useless at the minute. Would love an update on expected timeframe?

@udayxhegde @aramase do you guys know if this issue is in the right place/being looked at currently?

Met with a Microsoft rep ~2 weeks ago who reported that they knew this solution is entirely unsuitable for real world use cases at even the smallest of scales and that we should continue beating the drum about how completely useless it is. There is no public roadmap to this being resolved and nothing internal either. Federated identities are not ready, just mint and rotate your own tokens using app registrations and service principals and move on.

Hey folks - I'm not sure who on our end reported that there wasn't an internal plan to solve this, but I'm going to assume they were mistaken. We're definitely aware of this limitation, and there is an internal plan to solve this (I am one of the folks directly involved). That said, the solution won't be to raise the 20 federated identity credential limit (which is what I'm assuming the rep @tkellen talked with was referring to). Instead, there will be expression support that'll allow FIC's to map in a 1:many manner between entities instead of the current 1:1 mapping limitation affecting you all. We're nearing the finish line on a design for this that, alongside some other behavior, will allow you to configure a wildcard-like expression (we're using prefix matching) to match against the subject claim in incoming tokens from external IdP's. So, in the context of AKS, you'd be able to configure an expression such that any service account name or namespace/service account name combination would be authorized.
I can't really comment on the timeline as there are still some things for us to figure out, but I can assure you all that this is something we're actively working on. I'm also more than happy to discuss this further with anyone, so if you have interest in chatting more feel free to shoot me an email at<EMAIL_ADDRESS>

Thanks for the update @nickludwig. If the 20 token limitation isn't raised, would you agree that a workload with more than 20 instances running concurrently would need to mint multiple identical federated identities (in all but name)? Also that it will be the onus of the consumer to intelligently "load balance" which identity is used to account for this?

Thanks for the update @nickludwig. If the 20 token limitation isn't raised, would you agree that a workload with more than 20 instances running concurrently would need to mint multiple identical federated identities (in all but name)? Also that it will be the onus of the consumer to intelligently "load balance" which identity is used to account for this? For example, if you require 50 replicas of a given pod an operator will need 3 identical federated identities (first 20 replicas use the first identity, second 20 the second, and last ten the third with 10 tokens available on reserve).

why? you create fic per service account, so for one workload you'll need one fic, the number of replicas of this workload is irrelevant, they are all using the same service account

You're right of course, @timown. Got a bit turned around about the resources involved.

@nickludwig Something like a wildcard would be very useful for GitHub OIDC federated identity setups that trigger workflows on push (rather than pull_request). Today, you have to create a federated identity credential for each branch. There is no way to allow a push to any branch to use the federated identity.

@dghubble yup, agreed. We intend to cover GitHub scenarios with this work.

@nickludwig thank you for your time the other day. Just wanted to make note of our issue with prefix matching, in case others have the same.
Prefix matching doesn't allow matching a service account across multiple namespaces, which is a requirement in our workload. Something that wildcard support does.

Just curious how it is possible to make Workload Identity GA when we have this limit of 20 FI per MI and no support of wildcard per namespace

@nickludwig Something like a wildcard would be very useful for GitHub OIDC federated identity setups that trigger workflows on push (rather than pull_request). Today, you have to create a federated identity credential for each branch. There is no way to allow a push to any branch to use the federated identity.

maybe O.T. but you can configure what GitHub will issues in the token. In my case I'm using one one fic for each environments and the environment (not the branch) is emitted in the token issued by GitHub, works like a charm for me

@ilmax the comment was about using GitHub push events for workflow triggers. Other event types may or may not be suitable for a repo.

@dghubble just want to clarify my initial comment. We intend to cover GitHub Actions scenarios with this work, but what we're able to do is limited by what is returned in the subject claim in the incoming token from GitHub. That said, the scenario of push events (where the subject claim is based on branch, i.e., repo:contoso/contoso-repo:ref:refs/heads/branch-foo) would fit into this model.

@nickludwig yeah, in my case, the subject claim from GitHub looks like repo:myorg/myrepo:ref:refs/heads/somebranch" and I'd like to match against repo:myorg/myrepo:ref:refs/heads/*`, so that a push to any branch can use a federated identity. Hopefully that fits the upcoming model.
Today, my GitHub pushes can be associated with a Google Cloud workload identity or AWS OIDC, but Azure has this caveat I'm hoping can disappear.

Also want to add my use case here.
Our application is automatically deployed (via ci tools using a helm chart) multiple times to different namespaces. For pull requests and different public versions.
Right now, using AadPodIdentity, the pods in all namespaces use the same binding. But with the current state of WorkloadIdentity, we can't easily migrate to it.
Being able to put a wildcard for the namespace would allow us to keep the same infrastructure setup.

@nickludwig yeah, in my case, the subject claim from GitHub looks like repo:myorg/myrepo:ref:refs/heads/somebranch and I'd like to match against repo:myorg/myrepo:ref:refs/heads/*, so that a push to any branch can use a federated identity. Hopefully that fits the upcoming model.
Today, my GitHub pushes can be associated with a Google Cloud workload identity or AWS OIDC, but Azure has this caveat I'm hoping can disappear.

@nickludwig Just want to voice support for implementing this. At Cilium we would also like to be able to have the subject claim match any branch, since we have cases where the CI needs to run against arbitrary references. Up to now this wasn't a blocker but due to recent CI changes we will have to move back to using client secrets until this is supported as the only available workaround would be adding bogus environments to all of our workflows' jobs and use that to match with an environment subject claim.
For what it's worth, before finding this issue I've tried to manually edit the subject identifier to the following values, as I expected I could somehow make it work (because what is the point of being able to edit the subject identifier otherwise 😅):

repo:cilium/cilium:ref:refs/heads/* (I assumed this would match any branch)
repo:cilium/cilium:ref:* (I assumed this would match any reference)
repo:cilium/cilium:ref (idem)
repo:cilium/cilium (I assumed this would match anything coming from the cilium/cilium repository)

@floge07 / @litvinolek - thanks for putting your scenarios, it's super helpful for us to see the different use cases. I do have a question for y'all - our current design is centered around prefix matching instead of wildcards. So, you'd be able to achieve flexible namespaces with prefix matching, but you'd also need to authorize any service account name as well. Essentially, you'd match against system:serviceaccount:, and then namespace/service account name could be anything.
Would this be a blocking issue for you all?

@nickludwig yeah, in my case, the subject claim from GitHub looks like repo:myorg/myrepo:ref:refs/heads/somebranch and I'd like to match against repo:myorg/myrepo:ref:refs/heads/*, so that a push to any branch can use a federated identity. Hopefully that fits the upcoming model.
Today, my GitHub pushes can be associated with a Google Cloud workload identity or AWS OIDC, but Azure has this caveat I'm hoping can disappear.

@nickludwig Just want to voice support for implementing this. At Cilium we would also like to be able to have the subject claim match any branch, since we have cases where the CI needs to run against arbitrary references. Up to now this wasn't a blocker but due to recent CI changes we will have to move back to using client secrets until this is supported as the only available workaround would be adding bogus environments to all of our workflows' jobs and use that to match with an environment subject claim.
For what it's worth, before finding this issue I've tried to manually edit the subject identifier to the following values, as I expected I could somehow make it work (because what is the point of being able to edit the subject identifier otherwise 😅):

repo:cilium/cilium:ref:refs/heads/* (I assumed this would match any branch)
repo:cilium/cilium:ref:* (I assumed this would match any reference)
repo:cilium/cilium:ref (idem)
repo:cilium/cilium (I assumed this would match anything coming from the cilium/cilium repository)

Hey @nbusseneau - thank you as well! This scenario is accounted for in our design.

@floge07 / @litvinolek - thanks for listing your scenarios, it's super helpful for us to see the different use cases. I do have a question for y'all - our current design is centered around prefix matching instead of wildcards. So, you'd be able to achieve flexible namespaces with prefix matching, but you'd also need to authorize any service account name as well. Essentially, you'd match against system:serviceaccount:, and then namespace/service account name could be anything.
Would this be a blocking issue for you all?

No, that would work.
By specifying system:serviceaccount: we would essentially trust all jwt issued by that Kubernetes service, right?
But what if I wanted to contrain the subject identifier a bit further, would the prefixing logic also allow system:serviceaccount:myapp-? Or must it end with a colon?
Now that I think about how the "Subject identifier" gets kinda useless when matching everything, why is that field even mandatory on the Azure side?

If I add the URI of an OIDC Issuer that I say I trust, shouldn't that already be enough?
I mean sure it's nice to optionally constrain it further to specific subject values with a prefix or equal match, but are there security concerns I'm not seeing right now? (I can only think of when using a shared kubernetes with multiple apps and rbac)
But why stop with the sub claim? To have support to check for any arbitrary claim would probably be useful.
After all, Kubernetes already adds its own claim there. Even includes the pod name.

There are certainly oidc issuer services out there that will just put a random id into sub and the maybe important stuff into other custom claims.
Ah well, just a bit stream of thoughts there at the end. Probably even the wrong place here.

@floge07 - responding to your points...

No, that would work.
By specifying system:serviceaccount: we would essentially trust all jwt issued by that Kubernetes service, right?
But what if I wanted to contrain the subject identifier a bit further, would the prefixing logic also allow system:serviceaccount:myapp-? Or must it end with a colon?

Ok great, good to hear. And no, you wouldn't need to end on a semicolon. The scenario you list, system:serviceaccount:myapp-, would absolutely work.

Now that I think about how the "Subject identifier" gets kinda useless when matching everything, why is that field even mandatory on the Azure side?
If I add the URI of an OIDC Issuer that I say I trust, shouldn't that already be enough?
I mean sure it's nice to optionally constrain it further to specific subject values with a prefix or equal match, but are there security concerns I'm not seeing right now? (I can only think of when using a shared kubernetes with multiple apps and rbac)

This is a totally valid point, by adding this flexibility we're effectively making the subject claim optional in certain scenarios. Apologies for the vagueness, but there are limits to what I can say at this moment (and we're still working on designing what this looks like in practice).

To have support to check for any arbitrary claim would probably be useful. After all, Kubernetes already adds its own claim there. Even includes the pod name.
There are certainly oidc issuer services out there that will just put a random id into sub and the maybe important stuff into other custom claims.

Certainly - arbitrary claims is already part of the planned solution :)

Ah well, just a bit stream of thoughts there at the end. Probably even the wrong place here.

Thanks for your thoughts! Very helpful to hear. If you want to chat further, feel free to shoot me an email - I listed my alias above.

@floge07 / @litvinolek - thanks for listing your scenarios, it's super helpful for us to see the different use cases. I do have a question for y'all - our current design is centered around prefix matching instead of wildcards. So, you'd be able to achieve flexible namespaces with prefix matching, but you'd also need to authorize any service account name as well. Essentially, you'd match against system:serviceaccount:, and then namespace/service account name could be anything.
Would this be a blocking issue for you all?

It's a security concern but not a hard blocker.
With other cloud providers we mint one federated identity per application/workload and grant it the absolute minimum level of access required to function properly (e.g application A has write access to a specific storage account, application B has read access to one keyvault or a subset of keys within a shared keyvault, etc). The access model produced by prefix matching makes it trivial for a team operating in one namespace to assume permissions that belong to a team operating in a different namespace.
A more concerning example would be a scenario where there is a cluster running a CI workers (e.g. gitlab) that routinely run the tasks associated with maintaining the federated identities themselves (e.g. gitops workflows with terraform). In this scenario, with prefix matching alone, any application team working in any namespace could assume the identity associated with the CI system (subscription owner).
If my teams were to use this, compensating controls would have to be developed above/outside of Azure to create the kind of security we currently take for granted with other cloud providers.

It's a security concern but not a hard blocker.
With other cloud providers we mint one federated identity per application/workload and grant it the absolute minimum level of access required to function properly (e.g application A has write access to a specific storage account, application B has read access to one keyvault or a subset of keys within a shared keyvault, etc). The access model produced by prefix matching makes it trivial for a team operating in one namespace to assume permissions that belong to a team operating in a different namespace.
A more concerning example would be a scenario where there is a cluster running a CI workers (e.g. gitlab) that routinely run the tasks associated with maintaining the federated identities themselves (e.g. gitops workflows with terraform). In this scenario, with prefix matching alone, any application team working in any namespace could assume the identity associated with the CI system (subscription owner).
If my teams were to use this, compensating controls would have to be developed above/outside of Azure to create the kind of security we currently take for granted with other cloud providers.

So you have a situation where you don't want to automatically trust the users that have access to the Kubernetes service.
What exactly are their permissions? Even if you completely lock down the service accounts and the subject match, if they can create pods everywhere, they could just create a pod in that other namespace and bind the service account of that app, could they not?
So I assume they only have permission for their own namespace.
If the namespaces all begin with their app name, you could just configure the prefixes like system:serviceaccount:app1- and system:serviceaccount:app2-.
The only hole in that would be if the users can create new namespaces.
Because if you check for the full namespace and service account name, no one could assume that identity because Kubernetes would block it because of duplicated naming.
But as soon as you don't do that, either with wildcards or with prefixes, someone could just create a namespace matching the scheme, which would only be solvable by denying namespace creation.

en namespace/service account name could be anything.

In precisely my case - we can definitely predict the service account name, but the problem is a namespace
But even if we will have the ability to use something like "system:serviceaccount:namespace-*:serviceaccountname" - it will be much better

en namespace/service account name could be anything.

In precisely my case - we can definitely predict the service account name, but the problem is a namespace
But even if we will have the ability to use something like "system:serviceaccount:namespace-*:serviceaccountname" - it will be much better

The proposed prefix matching is on the whole subject, so the above would not be possible.

We need regex or glob support not prefix matching.
Please just copy how AWS does it, it supports all use cases.
If you do prefix matching it's likely going to continue to be unusable by most.
I know I won't be able to use it with prefix only. I need wildcard. I need to be able to match a namespace pattern and service account pattern at the same time.
Thanks,
Erik

en namespace/service account name could be anything.

In precisely my case - we can definitely predict the service account name, but the problem is a namespace
But even if we will have the ability to use something like "system:serviceaccount:namespace-*:serviceaccountname" - it will be much better

The proposed prefix matching is on the whole subject, so the above would not be possible.

This seems to contradict what @nickludwig said above: "So, in the context of AKS, you'd be able to configure an expression such that any service account name or namespace/service account name combination would be authorized."
If you can't do this, then you're forced to allow all service accounts (system:serviceaccount) or can only allow all Service Accounts in a namespace. Neither is helpful for the scenario where multiple namespaces are created, each with a (predictably-named) Service Account that needs to be federated to a shared/global managed identity.

en namespace/service account name could be anything.

In precisely my case - we can definitely predict the service account name, but the problem is a namespace
But even if we will have the ability to use something like "system:serviceaccount:namespace-*:serviceaccountname" - it will be much better

The proposed prefix matching is on the whole subject, so the above would not be possible.

This seems to contradict what @nickludwig said above: "So, in the context of AKS, you'd be able to configure an expression such that any service account name or namespace/service account name combination would be authorized."
If you can't do this, then you're forced to allow all service accounts (system:serviceaccount) or can only allow all Service Accounts in a namespace. Neither is helpful for the scenario where multiple namespaces are created, each with a (predictably-named) Service Account that needs to be federated to a shared/global managed identity.

Correct. Those scenarios are not planned to be covered is what was stated.
https://github.com/Azure/azure-workload-identity/issues/373#issuecomment-1611852155

Thank you @nickludwig  for the transparency around this issue and what is being done internally.
I did want to get some clarification around the prepossessed solution around prefix matching, and I apologize if this has been answered already  but the thread has gotten large and bit difficult to navigate at this point.
If you are able to comment publicly on this I'd appreciate an explanation on how the proposed solution intends to handle an simplified cluster layout that might be seen in the wild, like consider the scenario of the following namesapce naming conventions:

backend
pr-namespace00
pr-namespace01
dev-namespace00
dev-namespace01
some-other-namespace

would we be able to configure the mutating webhook service to map backend, pr-, and dev- to separate AAD applications federated identity bindings, and thus different Azure access policies; as well as excluding the some-other-namespace from any the configured binding?
I understand there is a limit on what you can talk about in this thread but I did want to capture the needs of clusters that have heterogeneous access requirements between the various namespaces, and have some reassurance that unless we opt to use the prefix of system:serviceaccount: we aren't creating, in effect, an allow-all rule.

Wildcard branch would be amazing, looking forward to the fix. Just to add an error message to aid others searching.
Error: : AADSTS70021: No matching federated identity record found for presented assertion. Assertion Issuer: 'https://token.actions.githubusercontent.com'. Assertion Subject: 'repo:myorg/myrepo:ref:refs/heads/mybranch'. Assertion Audience: 'api://AzureADTokenExchange'.

Any idea when this will be available? After September 2023 aad-pod-identity is end-of-life, so hope for this to be available before that date. If not, than we have no other solution to fall back to..

@ekristen, @artificial-aidan, @lynshi, @joshua-hancox - Thank you for the feedback. We're doing another round of design reviews. Will hopefully have some additional updates here shortly.

@nickludwig yeah, in my case, the subject claim from GitHub looks like repo:myorg/myrepo:ref:refs/heads/somebranch and I'd like to match against repo:myorg/myrepo:ref:refs/heads/*, so that a push to any branch can use a federated identity. Hopefully that fits the upcoming model.
Today, my GitHub pushes can be associated with a Google Cloud workload identity or AWS OIDC, but Azure has this caveat I'm hoping can disappear.

@nickludwig Just want to voice support for implementing this. At Cilium we would also like to be able to have the subject claim match any branch, since we have cases where the CI needs to run against arbitrary references. Up to now this wasn't a blocker but due to recent CI changes we will have to move back to using client secrets until this is supported as the only available workaround would be adding bogus environments to all of our workflows' jobs and use that to match with an environment subject claim.
For what it's worth, before finding this issue I've tried to manually edit the subject identifier to the following values, as I expected I could somehow make it work (because what is the point of being able to edit the subject identifier otherwise 😅):

repo:cilium/cilium:ref:refs/heads/* (I assumed this would match any branch)
repo:cilium/cilium:ref:* (I assumed this would match any reference)
repo:cilium/cilium:ref (idem)
repo:cilium/cilium (I assumed this would match anything coming from the cilium/cilium repository)

Hey @nbusseneau - thank you as well! This scenario is accounted for in our design.

Any idea when this is going to happen? We would like to be able to use OIDC also on: release when generating new tags, AFAIU currently it's not possible, right?

@nickludwig any update on this? Like so many others, we're eagerly awaiting a solution on this!

Hey folks, apologies for the delay here. I wanted to make sure I had a concrete update before coming back to the broader forum.
We have closed on design and are currently in the process of implementation. Our tentative ETA to preview this is Mid November 2023. Since the initial preview will be a private preview, a Microsoft NDA will be required to participate - so, if you have interest in participating, please reach out to me<EMAIL_ADDRESS>and I will get you added to the list we're building.

@nickludwig yeah, in my case, the subject claim from GitHub looks like repo:myorg/myrepo:ref:refs/heads/somebranch and I'd like to match against repo:myorg/myrepo:ref:refs/heads/*, so that a push to any branch can use a federated identity. Hopefully that fits the upcoming model.
Today, my GitHub pushes can be associated with a Google Cloud workload identity or AWS OIDC, but Azure has this caveat I'm hoping can disappear.

@nickludwig Just want to voice support for implementing this. At Cilium we would also like to be able to have the subject claim match any branch, since we have cases where the CI needs to run against arbitrary references. Up to now this wasn't a blocker but due to recent CI changes we will have to move back to using client secrets until this is supported as the only available workaround would be adding bogus environments to all of our workflows' jobs and use that to match with an environment subject claim.
For what it's worth, before finding this issue I've tried to manually edit the subject identifier to the following values, as I expected I could somehow make it work (because what is the point of being able to edit the subject identifier otherwise 😅):

repo:cilium/cilium:ref:refs/heads/* (I assumed this would match any branch)
repo:cilium/cilium:ref:* (I assumed this would match any reference)
repo:cilium/cilium:ref (idem)
repo:cilium/cilium (I assumed this would match anything coming from the cilium/cilium repository)

@nbusseneau If I understood correctly, the scenario you described should be supported, you just need to update the OIDC token claims on GitHub side as well as updating the subject identifier on Azure: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims
This can be done either at repository or organization level. The default behaviour is to include the claims repo and context, so to support matching any branch/environment on a repository you can just remove the context claim e.g.
PUT https://api.github.com/repos/cilium/cilium/actions/oidc/customization/sub

{
    "use_default": false,
    "include_claim_keys": [
        "repo"
    ]
}

Then the subject repo:cilium/cilium should match.
That said, this capability by no means solves every use case and wildcard support is badly needed, glad to hear it's being implemented!

Thanks @scootafew, this would probably work but is indeed annoying -- Azure is not the only OIDC provider we're interacting with at Cilium, and we do use context in others... 😅 I think we will just wait for wildcards to be available, but it might help someone else -- so thanks again for posting!

Are there any updates on this? It's such a weird limitation and the fact that wildcards aren't supported is not apparent until you actually try the integration and it fails miserably.

Hey all, a quick update:
We've unfortunately had to delay this work for a quarter, so the ETA is now somewhere in the mid-end FY24Q1 range. I understand this has been a long wait for many of you all, so I want to re-emphasize that we're still committed to getting this done.
As for the Private Preview - I'm still building the participant list despite our delay. Thank you to all who have reached out so far, I'm working through responses and should have gotten back to the majority of you by now. There are still a few folks for me to respond to, so if you haven't heard back in a week or so then please feel free to bump the thread.
I appreciate the continued patience and I'm looking forward to getting a version of this out to you all as soon as possible. I'll circle back when I have another update to share.

Hey all, a quick update:
We've unfortunately had to delay this work for a quarter, so the ETA is now somewhere in the mid-end FY24Q1 range. I understand this has been a long wait for many of you all, so I want to re-emphasize that we're still committed to getting this done.
As for the Private Preview - I'm still building the participant list despite our delay. Thank you to all who have reached out so far, I'm working through responses and should have gotten back to the majority of you by now. There are still a few folks for me to respond to, so if you haven't heard back in a week or so then please feel free to bump the thread.
I appreciate the continued patience and I'm looking forward to getting a version of this out to you all as soon as possible. I'll circle back when I have another update to share.

Something is not really clear to me, is the private preview scheduled for the mid-end FY24Q1 range or the GA?

Hey all, a quick update:
We've unfortunately had to delay this work for a quarter, so the ETA is now somewhere in the mid-end FY24Q1 range. I understand this has been a long wait for many of you all, so I want to re-emphasize that we're still committed to getting this done.
As for the Private Preview - I'm still building the participant list despite our delay. Thank you to all who have reached out so far, I'm working through responses and should have gotten back to the majority of you by now. There are still a few folks for me to respond to, so if you haven't heard back in a week or so then please feel free to bump the thread.
I appreciate the continued patience and I'm looking forward to getting a version of this out to you all as soon as possible. I'll circle back when I have another update to share.

Something is not really clear to me, is the private preview scheduled for the mid-end FY24Q1 range or the GA?

@kevinharing: Private Preview.

@nickludwig I'm also interested in the private preview.
And did you mean CY24Q1 (calendar 2024, as in January-March 2024)? Microsoft's Fiscal year ends on June 30, so unless I'm mistaken, you're already in FY24Q2.

@nickludwig any chance to join the private preview?

@nickludwig  any chance to join the preview?  when the feature can be public?
It is a blocking issue for the migration from azure pod identity to azure workload identity migration.

@nickludwig Is there any update regarding timeline? In my company we are waiting this solution to switch many of our systems (pipelines etc.) to Azure. Unfortunately without wildcard support in the federated credential, I cannot promote it into the team.

For us, this is necessary in order not to exceed the quota of role assignments.

@nickludwig Any updates on this?

@nickludwig  any updates on this?

@nickludwig yeah, in my case, the subject claim from GitHub looks like repo:myorg/myrepo:ref:refs/heads/somebranch and I'd like to match against repo:myorg/myrepo:ref:refs/heads/*, so that a push to any branch can use a federated identity. Hopefully that fits the upcoming model.
Today, my GitHub pushes can be associated with a Google Cloud workload identity or AWS OIDC, but Azure has this caveat I'm hoping can disappear.

@nickludwig Just want to voice support for implementing this. At Cilium we would also like to be able to have the subject claim match any branch, since we have cases where the CI needs to run against arbitrary references. Up to now this wasn't a blocker but due to recent CI changes we will have to move back to using client secrets until this is supported as the only available workaround would be adding bogus environments to all of our workflows' jobs and use that to match with an environment subject claim.
For what it's worth, before finding this issue I've tried to manually edit the subject identifier to the following values, as I expected I could somehow make it work (because what is the point of being able to edit the subject identifier otherwise 😅):

repo:cilium/cilium:ref:refs/heads/* (I assumed this would match any branch)
repo:cilium/cilium:ref:* (I assumed this would match any reference)
repo:cilium/cilium:ref (idem)
repo:cilium/cilium (I assumed this would match anything coming from the cilium/cilium repository)

@nbusseneau If I understood correctly, the scenario you described should be supported, you just need to update the OIDC token claims on GitHub side as well as updating the subject identifier on Azure: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims
This can be done either at repository or organization level. The default behaviour is to include the claims repo and context, so to support matching any branch/environment on a repository you can just remove the context claim e.g.
PUT https://api.github.com/repos/cilium/cilium/actions/oidc/customization/sub

{
    "use_default": false,
    "include_claim_keys": [
        "repo"
    ]
}

Then the subject repo:cilium/cilium should match.
That said, this capability by no means solves every use case and wildcard support is badly needed, glad to hear it's being implemented!

Really appreciate this nugget. Makes it workable for me. Thank you for sharing

Hi all, Bitbucket Pipelines use {WorkspaceUUID}:{DeploymentUUID}:{stepUUID} where step is dynamic. We use Bitbucket Pipelines and would like to test OIDC integration but this is a stopper.

Another use case this would help unlock is Buildkite id-tokens
The sub generated by BK is going to be different on every run/commit. Thus the current rigid exact matching required by azure makes integration with Buildkite impossible.
Subject

Identifies the subject of the JWT, typically representing the user or entity being authenticated.

Format: `organization:ORGANIZATION_SLUG:pipeline:PIPELINE_SLUG:ref:REF:commit:BUILD_COMMIT:step:STEP_KEY`

If the build has a tag, REF is refs/tags/TAG.

Otherwise, REF is refs/heads/BRANCH.

Example: `organization:acme-inc:pipeline:super-duper-app:ref:refs/heads/main:commit:9f3182061f1e2cca4702c368cbc039b7dc9d4485:step:build`

This is also neccesary in order to make the Gitlab CI integration work

Another use case this would help unlock is Buildkite id-tokens
The sub generated by BK is going to be different on every run/commit. Thus the rigid exact matching required by azure makes integration with Buildkite impossible.
Subject

Identifies the subject of the JWT, typically representing the user or entity being authenticated.

Format: `organization:ORGANIZATION_SLUG:pipeline:PIPELINE_SLUG:ref:REF:commit:BUILD_COMMIT:step:STEP_KEY`

If the build has a tag, REF is refs/tags/TAG.

Otherwise, REF is refs/heads/BRANCH.

Example: `organization:acme-inc:pipeline:super-duper-app:ref:refs/heads/main:commit:9f3182061f1e2cca4702c368cbc039b7dc9d4485:step:build`

Another similar use case this would unlock would be GitLab CI's integration for KeyVault.
This is is an impediment for migrating from Hashicorp Vault as every project/branch requires its own sub match.

Any updates on the timeline for this? We need to switch from using AAD pod identity to workload identity but are finding the limitations blocking us.

I got the info end of this month - hopefully

Same boat. As part of a migration to Azure we need this to allow GitLab CI to work in a sensible way. I had higher hope then shoving usernames and passwords into CI variables :(

Having this feature would greatly enhance our experience with CI tools as well.

+1 this is very limiting.

this limit is really crippling our automation, we already need to split principals per aks cluster. If we need to split this for every namespace and with the 20 creds limit this is almost impossible to automate

Can you guys just go into the code and change the limit from 20 to 200? Its just one little zero right 😄 ?
But seriously, without having to solve the entire general case or add some risky new feature, just upping the limit to some other slightly larger but still arbitrarily small finite number would make a huge difference in all our lives.

I try and refrain from being negative in GitHub Issues, but it's become clear Azure doesn't understand their customer base at all. I could link to dozens of issues about API instability, random breaking changes, weird limits like this, oh and my most recent favorite, randomly turning on settings you've explicitly turned off because they "know better" than you.  I recommend using any other provider if you can.
With that said, I solved this by writing a tool that I can't open source (I wish I could) that manages federated identities across tenants, it's painful and sucks, but I'll explain so if someone else want's to try and implement a portion of it they can.

Have a primary service principal with access to create additional ones.
I create one per unique entity (ie github repo) on each tenant that it needs access to.
I then have to create the federated identities for every combination, I generally try to keep it to repo vs branch as it exponentially expands when dealing with github, it's unfortunate but a compromise.
For k8s, I iterate on service principals and create federated identities per 20, I generally am fortunate enough to have less than 20 service accounts per cluster that need to access a tenant.
I put all this into a yaml file, and iterate over it, it's a quasi automated process, with a little extra effort you could query your apis to obtain all the information.

Chiming in to say that @ekristen's solution is more or less what we did also. It is a painful bookkeeping process that took considerable engineering effort to establish. It represents a needlessly complex single point of failure in our architecture that should not exist.
For future users reading this: if at all possible, pivot to AWS or GCP if your organization will allow it. This issue is the tip of an iceberg of half baked implementations that exist everywhere within Azure.

WTF

We had one use case we were able to get around where we used a shared secret and wrote our own k8s webhook to copy as needed. This limitation has caused use to have to have worse security practices to avoid lots of operational pain.
I echo the above.

Fix please

Stumbled up on this yesterday while evaluating federation for GitHub Actions. Without support for wildcards and a higher limit than 20, this feature is basically useless for us to use with GitHub Actions.

Stumbled up on this yesterday while evaluating federation for GitHub Actions. Without support for wildcards and a higher limit than 20, this feature is basically useless for us to use with GitHub Actions.

For Githun there is a workaround described earlier: https://github.com/Azure/azure-workload-identity/issues/373#issuecomment-1709899343

Stumbled up on this yesterday while evaluating federation for GitHub Actions. Without support for wildcards and a higher limit than 20, this feature is basically useless for us to use with GitHub Actions.

For Github there is a workaround described earlier: https://github.com/Azure/azure-workload-identity/issues/373#issuecomment-1709899343

This is not really a solution for us, since we have some principals that can be used by the entire GitHub organization (e.g to pull container images) and other principals only assigned to specific repositories. For the first requirement to work, we would have to modify the subject to only include the GitHub organization, in which case principals with repository scope would not work.

For GitHub, if you are using branches or tags for releases, I think you can circumvent this by using a static environment for your release and including that in the federated credential as it takes priority over the branch ref.

Any updates on this?? We really need to have the regex functionality for smoother execution of the multiple use-cases that we have.

I've noticed that the pattern matching for the branch is for only the start of the branch name, which means it can effectively can be used as a wildcard.
I'm using GitLab, which doesn't have the ability to manipulate the sub in the JWT token
For example, on main  branch, the sub would be:
project_path:example-project/example-repo:ref_type:branch:ref:main
This will directly match a federated credential set of project_path:example-project/example-repo:ref_type:branch:ref:main and be able to authenticate via OIDC.
If I have the branch: DATA-123, the sub would be:
project_path:example-project/example-repo:ref_type:branch:ref:DATA-123
If I configured in Azure the federated credential of project_path:example-project/example-repo:ref_type:branch:ref:DATA-, it would still be able to authenticate, and the OIDC flow will be successful. Note, I didn't add an astrix or any sort of wildcard, it feels like the pattern matcher on Azure only looks for the start of thee string, and not the complete match for the branch reference.
To me this seems like a bug, and something which is poorly coded in Azure and is a risk that may be changed in future, but it does solve our use-case of a GitFlow type pattern, as long as our branches follow the pattern of 'DATA-'.
In our enterprise company we'll be raising this 'feature' I discovered to understand if it is something they'll be fixing

This combined with the 20 cred limit is hampering our development too - would appreciate any update on whether this is going to be addressed in the near future.

👍 on this. This limitation breaks any use of GitLab federated identity because you can't change what the target variable is to verify in Azure (GitLab supplies a plethora of them) and any PR includes the source branch name as the sub.

Ya PR based flows are a huge use case for this

@perlboy could you please describe your set up and what's not working? The prefix string we have implemented is still working (as of 9AM GMT 26/04/2024)

@perlboy could you please describe your set up and what's not working? The prefix string we have implemented is still working (as of 9AM GMT 26/04/2024)

I tested this two days ago with Gitlab and it did not work.
Could it be that there is undocumented new featured being deployed and that works only on some regions

I'd like to add myself to the pool of users wanting this feature. Currently, we're stuck with client secret authentication as CircleCI adds the commit author ID to the sub claim.

@nickludwig Any news on this or the prefix matching, or even better, wild-card support?

Just wanted to say call out @scootafew 's solution specific to github -> azure as it addresses my need exactly:
allow federated auth from any branch in a github action workflow

Perhaps other CI products allow modifying what subject identifiers they attempt to auth with, where each branch can use a constant identifier and thus there is no need for wildcards on azure's side.

could we please avoid diluting this request. If the workaround was helpfull give it a thumbs up and don't blow up the thread with words of gratitude and by making assumptions. For our company this is still a major showstopper.

I think what is frustrating to me, is they have carved out an exception to Github, acknowledging there is a problem with the lack of flexibility.  Sadly we are using BitBucket (not my choice) but it creates similar OIDC subjects and this Github fix is just too specific.  Make a solution that works broadly if you are going to spend time on it.

The workaround isn't helpful except for those using the (Microsoft owned) GitHub. Azure seems to be the only implementation of federated OIDC that doesn't support a wildcarding concept.

With the @ImageMagick project we were running into the same issue when using azure/login in a GitHub actions and wanting do this for every tag. So a wildcard for a tag would have helped us. We resolved this by using an environment instead:
  create_release:
    runs-on: windows-latest
    environment: release

    permissions:
      id-token: write
      contents: read

And setting up this environment with a wildcard filter for tags:

And use that GitHub environment inside the configuration of our federated credential:

two years later, we still don't have a word from AAD team? @udayxhegde this has been a true pain once we started to embrace federated creds

Surprised this has not been supported already, especially with the amount of attention this issue has.

There's no wildcard support for Subject Identifier?, I am surprised.

🤯 #metoo

Just found the 20 limit.. this is a disaster.
can't believe 2 years since this issue it is still an issue

🤯 #metoo
No kidding, in my case I need too give access for different and dynamic workloads inside one tenant (i.e. k8s namespace), each workload has a different serviceAccount (I think it is a good practice), I would like to have the possibility to create a federated identity with subject like system:serviceaccount:<namespace>:* or system:serviceaccount:<namespace>:<some serviceAccount prefix>*
It is possible on AWS with the StringLike operator.

I'm not sure why there is a hard limit of 20 federated credentials, but I think having multiple ServiceAccounts tied to a single Azure User-Assigned Managed Identity might lead to unnecessary Azure permission sprawl. Since the managed identity itself is granted RBAC permissions, all linked ServiceAccounts would essentially inherit those same permissions, even if they don’t necessarily require them. So I prefer creating additional managed identities to guarantee that ServiceAccounts adhere to the principle of least privilege.

Twiddling my thumbs and waiting for an official reply on this much needed feature...

When can we get this simple feature? What's wrong with Entra ID since this cannot be fixed?

Wondering if this repo isn't the best place for this issue due to it not being officially supported.

I found this issue here, MS seem to at least officially reply there once something gets enough upvotes.
https://feedback.azure.com/d365community/idea/2068fe95-45ec-ee11-a73d-0022484c4e0d
Everyone go add your upvotes 😄

Any update on this?

My only option for now is to run the jobs needing Azure only from the main branch.
Unless there are other ways to workaround the no-wildcard limitation?

When you don't use GitHub's environment feature you can just create a default environment, use that default environment in any GH Actions Job needing Azure Access and then you can set up your EntraID App to allow federated access from that repo in that default environment (alternative to branch based access).
Works for testing, wouldn't use it in large orgs or enterprises since they use that feature for environment scoped secrets. @HenriBlacksmith
Any updates from the private beta users or from azure itself on this? This limitation is making this unnecessary complex.

I am using GitLab not GitHub sadly

The max 20 federated credentials limit is an ABSOLUTE JOKE! I don't understand why this limitation is still in place : it makes the OIDC feature in Entra ID completely unusable.

The max 20 federated credentials limit is an ABSOLUTE JOKE! I don't understand why this limitation is still in place : it makes the OIDC feature in Entra ID completely unusable.

And * (wildcards) are also not allowed 😢 😞

The wildcard support is needed.

Don't worry, it's only been 31 months since this was reported, I'm sure it's almost ready.

The max 20 federated credentials limit is an ABSOLUTE JOKE! I don't understand why this limitation is still in place : it makes the OIDC feature in Entra ID completely unusable.

I do not think the limit is a problem if you have the wildcard option.
The problem is mainly for CI pipelines/jobs which have a sub claim depending on the branch and that situation can only be unblocked by wildcards.
For a Kubernetes situation I do not see the usage of wildcards or more than 20 credentials (if you have more than 20 deployments federated with one Entra ID app or Managed Identity it is maybe the sign that this app must be split into more apps).
For the CI problem, HashiCorp vaut JWT authentication we use in GitLab CI allows us to customize the claims to be checked from GitLab CI tokens and the branch or tag name is usually not taken into account.
Hence another option could be to allow users to customize the claim key used (and to allow usage of multiple keys to build the trust)

This feature is a must. We have centralized our group's GitLab projects under a single group, and all those need access to credentials to access our Artifactory instance so that they can fetch dependencies (requires authentication).
We wanted to use a share key vault for those credentials, to avoid storing those in GitLab (unsafe). But the limitations (no wildcard and 20 federated credentials) mean that it's just impossible for us.

This feature is a must. We have centralized our group's GitLab projects under a single group, and all those need access to credentials to access our Artifactory instance so that they can fetch dependencies (requires authentication). We wanted to use a share key vault for those credentials, to avoid storing those in GitLab (unsafe). But the limitations (no wildcard and 20 federated credentials) mean that it's just impossible for us.

Maybe you can create multiple apps instead of having multiple credentials then?

This feature is a must. We have centralized our group's GitLab projects under a single group, and all those need access to credentials to access our Artifactory instance so that they can fetch dependencies (requires authentication). We wanted to use a share key vault for those credentials, to avoid storing those in GitLab (unsafe). But the limitations (no wildcard and 20 federated credentials) mean that it's just impossible for us.

Maybe you can create multiple apps instead of having multiple credentials then?

Indeed, but the lack of wildcard support still means that we'll have tons of configuration (we have hundreds of projects, each with multiple branches)

This is also a problem in our org, where I'm trying to authenticate with a workflow that triggers on release being published, meaning it checks against a tag version: ref:refs/tags/V1.0.0 and does not have the option to do wildcard there is crazy IMO since it's impossible to add each version manually?

Any movement on this feature request?

For those  using gitlab ...
Couple weeks ago Gitlab introduced customizable jwt sub claims. Admins/Owners can change the sub  claim components using Gitlab API.  I.e. you can set only project_path: and in result the gitlab id_token will NOT have the branch info in the sub anymore.
You can set it using following curl:
curl -X PUT "https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}" -H "PRIVATE-TOKEN: <token>" -H "Content-Type: application/json" --data '{"ci_id_token_sub_claim_components":["project_path"],"name":"${CI_PROJECT_NAME}"}'

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/160562

Dear Microsoft Team,
You should consider adding wildcard support. So many people are interested and this seems to be a blocker for many of us.
Not sure why it is not picked in years!!

Wildcard please....

We’ve also encountered this issue where we cannot use wildcards, specifically in branch names.
In our case, we use GitHub Actions to deploy infrastructure via Terraform across multiple environments in GCP, AWS, and Azure. Our goal is to bind identities to the environment name and either any branch or the main branch, as follows:

Environment + any branch: Read-only permissions (used for executing Terraform plan from PRs).
Environment + main branch: Write permissions for Terraform apply.

We successfully achieved this in GCP (by defining multiple attributes on different claims and binding permissions to them) and in AWS (by using wildcards in branch name matching in the IAM role trust policy).
Unfortunately, this is not possible in Azure.

When will the allowance for more than 20 identities be provided? Not sure why is this even a restraint at this point.

Without this wild card support, oidc integration with github is rudimentary at best and basically unsable.
After 2 and a half years since being reported to the team and "heads down trying to implement it" we can't just do a regex match on the subject? So rather let the customers just fall back to storing secrets and let the docs tell them not to.
@aramase @udayxhegde  If you are still here, is this issue ever going to get some dev time?

Please add this feature... Works in AWS for a long time...

Can we get an update on this issue? It seems like people are consistently running into this issue and it's been two years since this issue was initially created.  There's also been several people asking for an update on whether or not this will be supported or not.  At the least let us know if you won't be supporting this much needed feature.

@nickludwig is there private preview going on? Are you still main point of contact for this feature in Microsoft?
Would be great if someone provides at least some update about this feature status

No thanks to Azure but flagging that this comment is an interim solution enabled on the GitLab side. Requires minor change on AWS (if you're multicloud) to align but gets a terraform plan with Azure across the line in PRs.

I know @merill is Principal Product Manager for Entra, tagging in case he can shed some light

Hey all, a bit of a long post incoming.
We are in the process of building out wildcard support (as part of a feature we're calling Flexible FIC) and have some functionality that's ready to test. Given docs aren't out yet (likely will be released next week), I'm including all relevant information here so you can begin testing as you see fit.
For more context, we're extending the FIC object with a new property called claimsMatchingExpression. This property enables the use of a wildcard-based expression for matching against a specified claim. There will be a few limitations when this first rolls out, and a few pieces coming at a later point as implementation work finishes up.
The claimsMatchingExpression property is comprised of two pieces; value, which contains the expression, and languageVersion which allows us to version the expression language (should always be set to 1 for now). The expression itself is comprised of three pieces; a claim lookup (represented as "claims['sub']"), an operator (matches is the operator for wildcards), and the comparand (which is what the incoming token will be matched against).
A basic example of a Flexible FIC is as follows:
{
    "name": "myFlexibleFic",
    "issuer": "https://token.actions.githubusercontent.com",
    "audiences": [
        "api://AzureADTokenExchange",
    ],
    "claimsMatchingExpression": {
        "value": "claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*'",
        "languageVersion": 1
    }
}

The matches operator supports both single char (denoted by ?) and multi-char (denoted by *) wildcards. You can configure this via the Microsoft Graph /beta endpoint, or by using the Application Registrations Azure Portal UX.
NOTE: claimsMatchingExpression and subject fields are mutually exclusive. Whenever a claimsMatchingExpression is configured, the subject field must be null, and vice versa.
What is testable right now?
You can begin using this functionality for GitHub/GitLab/Terraform Cloud FIC's configured on application registrations. The following describes the supported issuer URL's/supported claim(s) for each issuer.
GitHub
Supported issuer URL's: https://token.actions.githubusercontent.com
Supported claims and operators per claim:

Claim sub supports operators eq and matches
Claim job_workflow_ref supports operators eq and matches

GitLab
Supported issuer URL's: https://gitlab.com, https://gitlab.example.com, https://gitlab.example.ca
Supported claims and operators per claim:

Claim sub supports operators eq and matches

Terraform Cloud
Supported issuer URL's: https://app.terraform.io, https://app.eu.terraform.io
Supported claims and operators per claim:

Claim sub supports operators eq and matches

NOTE 1: You will not be able to discover the API on your own, as the deployment to un-hide the API has not completed. That said, the allow-list gating access to this functionality has been removed, so you can configure these Flexible FIC's right now using the syntax mentioned in this post.
NOTE 2: To configure Flexible FIC's via App Registrations Azure Portal UX, you will need to include a feature flag in your portal URL for the time being. We are still waiting on the deployment to full release the UX to complete. The feature flag needed is enableFlexibleFIC=true, and an example of a portal URL containing this feature flag is https://portal.azure.com/?enableFlexibleFIC=true#view/Microsoft_AAD_RegisteredApps/ApplicationMenuBlade/~/Credentials.
What is coming at a later point?
Flexible FIC for Managed Identities + AKS
We are currently in the process of implementing this functionality for FIC's configured on managed identities. When we release this, we will also enable AKS as a supported issuer for this functionality.
Our current estimate for completion of this work is the middle to end of CY25Q1. This is a bit fluid, so I will circle back if anything changes regarding that date.
Azure CLI support
In order to provide native support for this new functionality, Azure CLI needs a public API. Since the deployment to make the API public has not completed, Azure CLI cannot implement this functionality. That being said, you can use Azure CLI's az rest method for making REST requests with this new functionality. An example of this is as follows:

az rest --method post --url https://graph.microsoft.com/beta/applications/{objectId}/federatedIdentityCredentials --body "{'name': 'FlexFic1', 'issuer': 'https://token.actions.githubusercontent.com', 'audiences': ['api://AzureADTokenExchange'], 'claimsMatchingExpression': {'value': 'claims[\'sub\'] matches \'repo:contoso/contoso-org:ref:refs/heads/*\'', 'languageVersion': 1}}"

Terraform provider support
Same as with Azure CLI, Terraform needs a public API to begin work on providing native support. Once the deployment to un-hide the API has been completed, we will work on getting an ETA on this support.
Feedback/Questions
For any feedback or gaps in functionality that are not mentioned in this post, please fill out this form.
For any questions, please post them below. I will try and be as active as I can in this thread.

Thanks @nickludwig for the update. There are a series of supported URL issuers above, but are there plans to enable this feature for arbitrary ("Public"?) issuers? I'm interested in implementing OIDC auth to orchestrate Azure automation from Bitbucket pipelines, where the OIDC issuer is https://api.bitbucket.org/2.0/workspaces/<slug>/pipelines-config/identity/oidc'.

@nickludwig Marvelous!
Will the ability to inspect arbitrary claims come with the initial release, or as a follow-on project "at a later point"? GitLab's token has a rich set of claims, but their sub is still not especially configurable, and it would be very nice to have access to the data in those claims. Should I fill out the feedback form (or file a support request) to help prioritize this?

az  ad app federated-credential list is unhappy after the az rest command to add the FIC (or doing it through the portal); it seems to be unhappy about the subject field being `null, and then it trips over its own shoelaces because it tries to decode some invalid JSON to get at the error:
<EMAIL_ADDRESS>"https://graph.microsoft.com/v1.0/$metadata#applications('UUID')/federatedIdentityCredentials",
"value":[{"id":"UUID","name":"FlexFic1","issuer":"https://gitlab.com"{"error":{"code":"InternalServerError","message":
"The property 'subject[Nullable=False]' of type 'Edm.String' has a null value, which is not allowed.","innerError":
{"date":"2024-12-06T23:19:12","request-id":"UUID","client-request-id":"UUID"}}}

Note "https://gitlab.com"{"error", so the stack trace you get tells you json.decoder.JSONDecodeError: Expecting ',' delimiter: line 1 column 247 (char 246).
The portal seems to be fine.

@sbgamma - This is something we're discussing but don't have a definitive answer for quite yet.
@dhduvall - So the initial release covers just the claims/issuers mentioned in my post. I'm open to extending this to other claims given sufficient justification, so feel free to fill out the form I included in the post. Like with arbitrary issuers, arbitrary claims are something I have as a goal, but don't have a definitive answer for yet.
As for the Azure CLI stuff - yep, az ad app federated-credential list is unfortunately not going to work until az ad app federated-credential is updated to support Flexible FIC. You should still be able to list FIC's using az rest and switching method to get, however.

@nickludwig Thank you for the update and truly appreciate that the wildcard support feature is finally here!
So I want to use flexible FIC wildcard in our repo under code.siemens.com (gitlab clone). I defined the body.json as following:
{
    "name": "code-siemens-fic",
    "issuer": "https://code.siemens.com",
    "audiences": [
        "https://code.siemens.com"
    ],
    "subject": null,
    "description": "code.siemens service account federated identity",
    "claimsMatchingExpression": {
        "value": "claims['sub'] matches 'repo:$repoProject/$repoName:ref:refs/heads/*'",
        "languageVersion": 1
    }
}

And when I try to create the FIC az rest --method POST --uri "https://graph.microsoft.com/beta/applications/$objectId/federatedIdentityCredentials" --body @body.json I get following error:
Bad Request({"error":{"code":"InvalidFederatedIdentityCredentialValue","message":"The FederatedIdentityCredential.ClaimsMatchingExpression.Value is invalid. Rule exception: Expression is not supported for applications in this cloud 'Public' using issuer 'https://code.siemens.com'. paramName: FederatedIdentityCredential.ClaimsMatchingExpression.Value, paramValue: claims['sub'] matches 'repo:$repoProject/$repoName:ref:refs/heads/*', objectType: Microsoft.Online.DirectoryServices.Application","innerError":{"date":"2024-12-09T10:52:36","request-id":"$requestId","client-request-id":"$client-request-id"}}})
What am I doing wrong here?

@SiHaoShen - the reason this is not working at the moment is because the issuer you've configured is not one of the generalized issuers we support for Flexible FIC at the current moment. The supported issuer URL's are mentioned in my post above. It is a goal to extend this support to arbitrary issuers, but it is not something I have a definitive answer for yet.

@nickludwig is Azure DevOps considered an arbitrary issuer (https://vstoken.dev.azure.com/<org_id> ), i.e. that it might not be supported for Flexible FIC?

I also put my initial post in here for OIDC integration from BitBucket like SBGAMMA.  If you do not do arbitrary URLs it would be nice to at least add BitBucket to the list of supported issuers https://api.bitbucket.org/2.0/workspaces/<slug>/pipelines-config/identity/oidc

I'm trying to add this to an application using terraform, and struggling a bit. Obviously neither azurerm or azuread will support this, and normally for unsupported Azure resources I'd use azapi, but I don't see how to use azapi for an Entra object, and I don't know of another terraform provider which is fully flexible like that. Is https://github.com/hashicorp/terraform-provider-azuread/issues/937 what I need?

I'm trying to add this to an application using terraform, and struggling a bit. Obviously neither azurerm or azuread will support this, and normally for unsupported Azure resources I'd use azapi, but I don't see how to use azapi for an Entra object, and I don't know of another terraform provider which is fully flexible like that. Is hashicorp/terraform-provider-azuread#937 what I need?

@dhduvall I've used the restful_operation resource from this restful provider  to set this via the beta graph api in terraform. It's not as clean as azapi or azurerm/azuread support, but it does the job in the interim :)
provider "restful" {
  base_url = "https://graph.microsoft.com/beta"
  security = {
    http = {
      token = {
        token = var.graph_api_token
      }
    }
  }
}

I run the following to set the graph api token:
TF_VAR_graph_api_token=$(az account get-access-token --resource-type ms-graph --query accessToken -o tsv)
Other rest/http terraform providers would likely also work.

@daisy-timms-xlab That's an awesome recommendation. Thank you! Looks like there's even a way to make it work with OIDC.

@nbaju1 - not an arbitrary issuer, but just one that's currently unsupported. It'll be one of the ones we discuss when looking to expand this functionality, hoping to have those conversations at the beginning of the new year.
@jgiasson-nuharbor - yeah if you want to include some more info (justification, scenarios, etc) in the form I provided in my initial post, that'll help me when I discuss with folks on my end. if you want to include your email in the form, then I can reach out to you about this so we can discuss some more.
Also, thanks to all for including some examples of workarounds for using this with various tools!

@SiHaoShen - the reason this is not working at the moment is because the issuer you've configured is not one of the generalized issuers we support for Flexible FIC at the current moment. The supported issuer URL's are mentioned in my post above. It is a goal to extend this support to arbitrary issuers, but it is not something I have a definitive answer for yet.

@nickludwig I hope other domains would supported quickly. I am in the same situation.

@SiHaoShen - the reason this is not working at the moment is because the issuer you've configured is not one of the generalized issuers we support for Flexible FIC at the current moment. The supported issuer URL's are mentioned in my post above. It is a goal to extend this support to arbitrary issuers, but it is not something I have a definitive answer for yet.

@nickludwig Thanks for the clarification. We are more than eager to see it coming to all other self-hosted GitLab instances soon.


Create a sample for long-running operations

I don't think we have a sample showing how the new LRO APIs work, let's create one.

This will be addressed in issue https://github.com/Azure/azure-sdk-for-go/issues/796.


Reduce usgaes of try! in tests

The usage of try! was still a relict of when XCTest didn’t allow throwing test method.

@swift-ci Please test

@swift-ci please test


[BUG] The bridge-app can connect to the homepod but not the google nest hub

Reproduction steps
The bridge can easily pair with my HomePod, but there's no way it can connect to my Google Nest Hub 2.
The error is too general "There is an error when connecting to the device".
Bug prevalence
all the time
GitHub hash of the SDK that was being used
latest
Platform
darwin
Platform Version(s)
No response
Anything else?
No response

Have you set up a matter integration project in the console?

I used the QR code that was generated from matter.

You need to set up a matter integration project in the google cloud console before, in order that the google home app gets the required information.

I stumbled over a tutorial from silabs https://docs.silabs.com/matter/2.1.0/matter-bridge/readme-user#using-google-nest-hub


how can i create an index page to my website?

Im having a hard time setting up the index page for my domain. Will you guide me about the redirects of the system? thank you.

Hi,
To set Telegram to send request to your server you need to use Telegram API setwebhook.
If you follow the instruction and use the install script all is setup for you.
You can set you webhook url manually using telegram API link like this:
https://api.telegram.org/bot{my_bot_token}/setWebhook?url={your_url}
relacing {my_bot_token} by the token of botfather and {your_url} by the url of you web application.


Build Failure if value contains an = (because line is split on all equals, not just first)

Example:
DBSOCKET = "mysql+pymysql://{user}@LOCALHOST/myapp?unix_socket=/run/mysqld/mysqld.sock"
Expected behaviour: Successful generation of env.g.dart
Actual Output:
[SEVERE] envied_generator:envied on lib/env/env.dart:
  Bad state: Pattern matching error
  package:envied_generator/src/parser.dart 43:5      Parser.parseOne
  package:envied_generator/src/parser.dart 23:38     Parser.parse
  package:envied_generator/src/load_envs.dart 24:17  loadEnvs
  package:envied_generator/src/generator.dart 60:9   EnviedGenerator.generateForAnnotatedElement

Reason for failure:
String is split on all occurances of '=' and assumes the value will never have one.
parser.dart:
    /// Split the line into key and value.
    final [String lhs, String rhs] = stripped.split('=');

Suggested fix:
since the .env spec does not require any spaces around =, the only way to identify the separator is to only split on the first occurrence of the =.
Therefore, replace the use of the inbuilt string.split('=') with one that only splits on the first occurrence.

Apologies, realised you are fixing this and just haven't pushed the new package out yet.
(#100)


"Registration Page" Tab

Create a tab like the "Profile Page" but than for the "Registration Page".

Don't make a tab. show on the Profile Page two checkboxes ("Profile Page" and "Register Page").

Implemented in d786b1daadc788865ff3b65ea9d3efef03440fe7


docs(codeowners): add codeowners

Add more code owners

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Indicator for projected countdowns

Currently:
After #2912 is implemented
If a countdown is projected on projector A and you are on the detail view of projector B then there is no visualisation that the countdown is already projected onto the other projector
Wanted behaviour:
If the countdown is projected then there should be an indicator that it is already projected elsewhere.
The indicator should be the projector icon (directly behind the title) if you hover over the icon the a toolbox tells you where the countdown is projected

It is currently already possible via the Open projection dialog to view where a countdown is projected.
As the space is very limited there I think it might be better to integrate the info into the already existing button.


how disable file anchors badge

when i see the file anchors badge, i always want to click it, how disable the file anchors badge?

VSCode has native functionality built in to disable this badge, simply right click the anchor icon and hit "Hide Badge". Hope that helps!

VSCode has native functionality built in to disable this badge, simply right click the anchor icon and hit "Hide Badge". Hope that helps!

It's useful, thanks!


Adds slash hold to add label instead of API labels arg

Issue #, if available:
Description of changes:
Same change that was done in https://github.com/aws/eks-distro-build-tooling/pull/757
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/hold

This isn't working in eks-d. Holding until I fix it

/unhold
/approve