Creating an access entry fails if it already exists

Description
I am trying to create a new access entry. I am migrating from 19.20 -> 20.5.0 and so getting rid of config map entry and migrating to access entry: Creation of access entry fails if it already exists. I have to go manually delete the role so it attempts to create it again.
See Actual Behaviour for a full error message
Also for user defined roles such as the 'cluster_management_role' as shown in the terraform code - it sometimes fails to attach the policy. This results in failed deployment for us since  we are using this role to for EKSTokenAuth.

[ yes] ✋ I have searched the open/closed issues and my issue is not listed.

⚠ Note
Versions

Module version [Required]: 20.5.0

Terraform version:
1.5.7

Provider version(s):
5.38.0

Reproduction Code [Required]
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.5.0"

  cluster_name                         = var.eks_cluster_name
  cluster_version                      = var.eks_version
  cluster_endpoint_public_access       = true
  cluster_endpoint_private_access      = true
  cluster_endpoint_public_access_cidrs = var.public_access_cidrs
  enable_irsa                          = true
  iam_role_arn                         = aws_iam_role.eks_cluster_role.arn
  authentication_mode                  = "API_AND_CONFIG_MAP"
  vpc_id                               = local.vpc_id
  control_plane_subnet_ids             = local.eks_cluster_private_subnets
  subnet_ids                           = local.eks_worker_private_subnets

  cluster_security_group_tags = {
    "kubernetes.io/cluster/${var.eks_cluster_name}" = null
  }

  cluster_addons = {
    vpc-cni = {
      resolve_conflicts_on_update = "OVERWRITE"
      resolve_conflicts_on_create = "OVERWRITE"
      before_compute              = true
      service_account_role_arn    = module.vpc_cni_irsa.iam_role_arn
      addon_version               = local.eks_managed_add_on_versions.vpc_cni
      configuration_values = jsonencode({
        env = {
          # AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG = "true"
          # ENI_CONFIG_LABEL_DEF               = "topology.kubernetes.io/zone"

          # Reference docs https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html
          ENABLE_PREFIX_DELEGATION = "true"
          WARM_PREFIX_TARGET       = "1"
        }
      })
    }
    coredns = {
      resolve_conflicts_on_update = "OVERWRITE"
      resolve_conflicts_on_create = "OVERWRITE"
      preserve                    = true #this is the default value
      addon_version               = local.eks_managed_add_on_versions.coredns

      timeouts = {
        create = "25m"
        delete = "10m"
      }
    }
    kube-proxy = {
      addon_version               = local.eks_managed_add_on_versions.kube_proxy
      resolve_conflicts_on_update = "OVERWRITE"
      resolve_conflicts_on_create = "OVERWRITE"
    }
    aws-ebs-csi-driver = {
      addon_version               = local.eks_managed_add_on_versions.aws_ebs_csi_driver
      resolve_conflicts_on_update = "OVERWRITE"
      resolve_conflicts_on_create = "OVERWRITE"
      service_account_role_arn    = aws_iam_role.ebs_csi_role.arn

    }
  }

  enable_cluster_creator_admin_permissions = true
  access_entries = {
    cluster_manager = {
      kubernetes_groups = [] #did not allow to add to system:masters, associating admin access policy
      principal_arn     = aws_iam_role.cluster_management_role.arn
      policy_associations = {
        cluster_manager = {
          policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
          access_scope = {
            namespaces = []
            type = "cluster"
          }

        }

      }
    }

    mwaa = {
      kubernetes_groups = []
      principal_arn     = aws_iam_role.mwaa_execution_role.arn
      username          = "mwaa-service"
    }

  }

  node_security_group_additional_rules = {
    nodes_istiod_port = {
      description                   = "Cluster API to Node group for istiod webhook"
      protocol                      = "tcp"
      from_port                     = 15017
      to_port                       = 15017
      type                          = "ingress"
      source_cluster_security_group = true
    }
    node_to_node_communication = {
      description = "Allow full access for cross-node communication"
      protocol    = "tcp"
      from_port   = 0
      to_port     = 65535
      type        = "ingress"
      self        = true
    }
  }

  node_security_group_tags = {
    # NOTE - if creating multiple security groups with this module, only tag the
    # security group that Karpenter should utilize with the following tag
    # (i.e. - at most, only one security group should have this tag in your account)
    "karpenter.sh/discovery" = var.eks_cluster_name
  }

  eks_managed_node_group_defaults = {
    # We are using the IRSA created below for permissions
    # However, we have to provision a new cluster with the policy attached FIRST
    # before we can disable. Without this initial policy,
    # the VPC CNI fails to assign IPs and nodes cannot join the new cluster
    iam_role_attach_cni_policy = true
  }

  eks_managed_node_groups = {

    default = {
      name = "${var.eks_cluster_name}-default"

      subnet_ids = local.eks_worker_private_subnets

      min_size     = 2
      max_size     = 3
      desired_size = 2

      force_update_version = true
      instance_types       = ["m5a.xlarge"]

      # Not required nor used - avoid tagging two security groups with same tag as well
      create_security_group = false

      update_config = {
        max_unavailable_percentage = 50 # or set `max_unavailable`
      }

      description = "${var.eks_cluster_name} - EKS managed node group launch template"

      ebs_optimized           = true
      disable_api_termination = false
      enable_monitoring       = true

      block_device_mappings = {
        xvda = {
          device_name = "/dev/xvda"
          ebs = {
            volume_size           = 75
            volume_type           = "gp3"
            iops                  = 3000
            throughput            = 150
            encrypted             = true
            delete_on_termination = true
          }
        }
      }

      metadata_options = {
        http_endpoint               = "enabled"
        http_tokens                 = "required"
        http_put_response_hop_limit = 2
        instance_metadata_tags      = "disabled"
      }

      create_iam_role = false
      iam_role_arn    = aws_iam_role.eks_node_group_role.arn
      # iam_role_name            = "${var.eks_cluster_name}-default-managed-node-group"
      # iam_role_use_name_prefix = false
      # iam_role_description     = "EKS managed node group role"
      # iam_role_additional_policies = {
      #   AmazonEC2ContainerRegistryReadOnly = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
      #   additional                         = aws_iam_policy.node_additional.arn
      # }

      tags = {
        EksClusterName = var.eks_cluster_name
      }
    }
  }

  tags = {
    # Explicit `nonsensitive()` call needed here as these tags are used in a foreach loop during deployment and foreach don't allow sensitive value
    nonsensitive(data.aws_ssm_parameter.appregistry_application_tag_key.value) = nonsensitive(data.aws_ssm_parameter.appregistry_application_tag_value.value)
    VPC_Name                                                                   = var.vpc_name
    Terraform                                                                  = "true"
  }
}

Steps to reproduce the behavior:
terraform init
terraform apply
Expected behavior
The cluster entry should be properly created even if it already exists.
Policy should be attached correctly
Actual behavior
The behaviour is very intermittent and unpredictable. It sometimes creates tge
We see error messages such as:
╷
│ Error: creating EKS Access Entry (second:arn:aws:iam::473699735501:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess_2dfe39b46fb1ea3a): operation error EKS: CreateAccessEntry, https response error StatusCode: 409, RequestID: 06e2b43a-e5a6-46f6-a05f-ed8b0887aa75, ResourceInUseException: The specified access entry resource is already in use on this cluster.
│
│   with module.eks.aws_eks_access_entry.this["cluster_creator"],
│   on .terraform/modules/eks/main.tf line 185, in resource "aws_eks_access_entry" "this":
│  185: resource "aws_eks_access_entry" "this" {
│
╵
╷
│ Error: creating EKS Access Entry (second:arn:aws:iam::473699735501:role/second-us-east-1-eks-node-group-role): operation error EKS: CreateAccessEntry, https response error StatusCode: 409, RequestID: 7f43c24f-361e-46cc-84e9-fe642dc622e0, ResourceInUseException: The specified access entry resource is already in use on this cluster.
│
│   with module.karpenter.aws_eks_access_entry.node[0],
│   on .terraform/modules/karpenter/modules/karpenter/main.tf line 589, in resource "aws_eks_access_entry" "node":
│  589: resource "aws_eks_access_entry" "node" {
│
╵
make: *** [Makefile:142: deploy-eks-cluster] Error 1

Actual behaviour when cluster_management_role custom role access entry fails to attach the policy
Plan: 18 to add, 2 to change, 13 to destroy.
╷
│ Error: query: failed to query with labels: secrets is forbidden: User "arn:aws:sts::473699735501:assumed-role/eks-second-us-east-1-cluster-management-role/EKSGetTokenAuth" cannot list resource "secrets" in API group "" in the namespace "karpenter"
│
│   with helm_release.karpenter,
│   on eks-add-ons.tf line 101, in resource "helm_release" "karpenter":
│  101: resource "helm_release" "karpenter" {
│
╵

Terminal Output Screenshot(s)

Additional context

@cweiblen Are you able to reproduce this issue as well?

if you are migrating a cluster into cluster access entry, you can't use  enable_cluster_creator_admin_permissions = true because EKS automatically maps that entity into an access entry. you can either remove this, or you can enable it but you'll need to import the entry that EKS created into the resource used by the module (to control this via Terraform)

For the other issue where the policy is never attached:
` cluster_manager = {
kubernetes_groups = [] #did not allow to add to system:masters, associating admin access policy
principal_arn     = aws_iam_role.cluster_management_role.arn
policy_associations = {
cluster_manager = {
policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
access_scope = {
namespaces = []
type = "cluster"
}
    }

  }
}

`
I see this in the plan:
`# module.eks.aws_eks_access_policy_association.this["cluster_manager_cluster_manager"] will be created

resource "aws_eks_access_policy_association" "this" {

associated_at = (known after apply)

cluster_name  = "osdu5"

id            = (known after apply)

modified_at   = (known after apply)

policy_arn    = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"

principal_arn = "arn:aws:iam::808560345837:role/eks-osdu5-us-east-1-cluster-management-role"

access_scope {

type = "cluster"
}
}
`

Is this related with

I don't follow, what is the issue?

In the reproduction code, see my access entry for     principal_arn     = aws_iam_role.cluster_management_role.arn
After terraform is applied, the access entry is created but it does not have the AmazonEKSClusterAdminPolicy attached to it.

See the second entry here:

What does the API say aws eks list-associated-access-policies --cluster-name <value> --principal-arn <value>
Is your Terraform plan "clean" (i.e. - if you run terraform plan, its free of any diff/pending changes)

I was not able to get it working using access_entries input, I would get the errors described.  As a workaround I used the aws_eks_access_entry from the AWS provider

I would be curious to see what you are doing differently. If an access entry already exists, it already exists - there isn't anything unique about the implementation that would allow you to get around that

@bryantbiggs There are 2 issues that we see. when using access_entries
1/ If an access entry exists - it complains with the error 'Resource is already in use' and fails. It's a fatal error and not just a warning
2/ If it does create the entry, it does not attach the policy.

1/ If an access entry exists - it complains with the error 'Resource is already in use' and fails. It's a fatal error and not just a warning

We do not control this - this is the EKS API. Its stating that you can't have more than one entry for the same principal. This would be similar to trying to create two clusters both named the same, in the same region - the API does not allow that, nothing to do with this module

2/ If it does create the entry, it does not attach the policy.

Do you have a reproduction? I'd love to see whats different about a standalone resource versus whats defined here. Here is what we have in our example that works as intended https://github.com/terraform-aws-modules/terraform-aws-eks/blob/907f70cffdd03e14d1da97d916451cfb0688a760/examples/eks_managed_node_group/main.tf#L304-L342

@bryantbiggs In my code I have an access entry of type 'cluster' as shown below:
In your example, ex-two is of type cluster but no 'policy_associations' section only a policy_arn.
Is that may be the problem with my code?
access_entries = {
cluster_manager = {
kubernetes_groups = [] #did not allow to add to system:masters, associating admin access policy
principal_arn     = aws_iam_role.cluster_management_role.arn
policy_associations = {
cluster_manager = {
policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
access_scope = {
namespaces = []
type = "cluster"
}
    }

  }
}

mwaa = {
  kubernetes_groups = []
  principal_arn     = aws_iam_role.mwaa_execution_role.arn
  username          = "mwaa-service"
}

The first time we run it works fine, the second time you run it may be for an upgrade in another part of the code - it attempts to create it again

From the details you have provided, its very hard to understand what you are doing and why you are encountering issues. I would suggest re-reading the upgrade guide. In short, there are two areas where access entries will already exist that YOU do not need to re-add them in code. Both of these scenarios are when you have a cluster that was created with the aws-auth ConfigMap and you are migrating to access entry:

The identity that was used to create the cluster will automatically be mapped into an access entry when access entry is enabled on a cluster. Under the aws-auth ConfigMap only method, you would not see this identity in the ConfigMap. If you are using the same role that was used to create the cluster using aws-auth and you are migrating to access entry, you should not set enable_cluster_creator_admin_permissions = true because Terraform will try to create an access entry that EKS has already created and it will fail. If you wish to control this in code you will either need to manually delete the entry via the EKS API and then create with Terraform, or do a Terraform import to control this through code. We cannot do anything about this in the module since the module did not create it in the first place
EKS will automatically create access entries for roles used by EKS managed nodegroup(s) and EKS Fargate profiles - users should NOT do anything with these cluster access entries when migrating to cluster access entry - leave these to EKS to manage. Again, if you try to re-add these entries through code/Terraform, it will fail and state that an entry already exists

and for sake of completeness, here is an example as requested of a single entry with cluster scope as the module is currently written - it works without issue:
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.8"

  cluster_name                   = local.name
  cluster_version                = local.cluster_version
  cluster_endpoint_public_access = true

  enable_cluster_creator_admin_permissions = true

  vpc_id                   = module.vpc.vpc_id
  subnet_ids               = module.vpc.private_subnets
  control_plane_subnet_ids = module.vpc.intra_subnets

  eks_managed_node_group_defaults = {
    ami_type       = "AL2_x86_64"
    instance_types = ["m6i.large", "m5.large", "m5n.large", "m5zn.large"]
  }

  eks_managed_node_groups = {
    # Default node group - as provided by AWS EKS
    default_node_group = {
      # By default, the module creates a launch template to ensure tags are propagated to instances, etc.,
      # so we need to disable it to use the default template provided by the AWS EKS managed node group service
      use_custom_launch_template = false
    }
  }

  access_entries = {
    # One access entry with a policy associated
    ex-single = {
      principal_arn     = aws_iam_role.this["single"].arn
      policy_associations = {
        ex = {
          policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
          access_scope = {
            type = "cluster"
          }
        }
      }
    }
  }

  tags = local.tags
}

Describe the access entry:
aws eks describe-access-entry \
  --cluster-name ex-eks-managed-node-group \
  --principal-arn "arn:aws:iam::000000000000:role/ex-single" \
  --region eu-west-1

{
    "accessEntry": {
        "clusterName": "ex-eks-managed-node-group",
        "principalArn": "arn:aws:iam::000000000000:role/ex-single",
        "kubernetesGroups": [],
        "accessEntryArn": "arn:aws:eks:eu-west-1:000000000000:access-entry/ex-eks-managed-node-group/role/000000000000/ex-single/40c71997-3891-aa1c-0997-e0352c7ca25a",
        "createdAt": "2024-03-12T11:01:05.685000-04:00",
        "modifiedAt": "2024-03-12T11:01:05.685000-04:00",
        "tags": {
            "GithubRepo": "terraform-aws-eks",
            "GithubOrg": "terraform-aws-modules",
            "Example": "ex-eks-managed-node-group"
        },
        "username": "arn:aws:sts::000000000000:assumed-role/ex-single/{{SessionName}}",
        "type": "STANDARD"
    }
}

List the policies associated with this principal:
aws eks list-associated-access-policies \
  --cluster-name ex-eks-managed-node-group \
  --principal-arn "arn:aws:iam::000000000000:role/ex-single" \
  --region eu-west-1

{
    "associatedAccessPolicies": [
        {
            "policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
            "accessScope": {
                "type": "cluster",
                "namespaces": []
            },
            "associatedAt": "2024-03-12T11:01:07.063000-04:00",
            "modifiedAt": "2024-03-12T11:01:07.063000-04:00"
        }
    ],
    "clusterName": "ex-eks-managed-node-group",
    "principalArn": "arn:aws:iam::000000000000:role/ex-single"
}

Somehow the policy does not get attached in my case and in @cweiblen 's case as well.
Not sure whether it is the policy that we are using. I have shared my code, plan and a screenshot above

I have shared my code, plan and a screenshot above

You have shared some code, yes, but its all variables and values that are unknown to anyone but yourself. For now I am putting a pin in this thread because I am not seeing any issues on the module as it stands. If there is additional information that will highlight this issue, we can definitely take a another look

We faced the same issue that @deshruch mentioned. e.g.
1/ If an access entry exists - it complains with the error 'Resource is already in use' and fails. It's a fatal error and not just a warning
2/ If it does create the entry, it does not attach the policy.

and we have this enable_cluster_creator_admin_permissions set as False
Exact error was:
creating EKS Access Entry (): operation error EKS: CreateAccessEntry, https response error StatusCode: 409, RequestID: xxx, ResourceInUseException: The specified access entry resource is already in use on this cluster
We had to manually intervene and delete that entry or attach policy.

We had to do the same thing that @cweiblen did to get around this. We had to create access entries using 'resource'. Note that this was the case for a custom IAM role that we were migrating form Config Map to EKS access entry.
However, if this is for the node group role, EKS module automatically moves it. We were also using the 'karpenter' module in which you need to explicitly set   create_access_entry    = false (default is true), s o that the karpenter module does not try to recreate it again and throw the 'the specified access entry resource is already in use on this cluster' error.
For user defined/custom IAM role, we had to add access entry and policy association using 'resource'


New package: IBM.Semeru.8.JRE version 8.0.412.8

Created by 🥟 Dumplings.
Microsoft Reviewers: Open in CodeFlow

Verify:


tests/c_lib: strerror_r is POSIX

Add "#define _POSIX_C_SOURCE 200809" so that picolibc will declare the complete POSIX API, including strerror_r, not just the Zephyr C library API.

Looks like we'll have to wait for the SDK used by CI to get updated to one with picolibc's _ZEPHYR_SOURCE support?

Fixed a commit message which needed word wrapping for the Compliance Checks.

Looks pretty close.
This is definitely on the roadmap. I'm hoping we can tie Konfig into POSIX feature test macros / version specifiers.

Looks pretty close.
This is definitely on the roadmap. I'm hoping we can tie Konfig into POSIX feature test macros / version specifiers.

Thanks. This depends on an SDK that supports _ZEPHYR_SOURCE; when that starts getting used in CI, it should "just work". I'm trying to get all of my changes queued up and ready to land after 3.4.0 is done.

@keith-packard did you want to rebase / can this now go in?

all done; let's see if CI agrees with my local twister run.


Organize codebase

Is it probably time to organize the code into a module

Yeah, we have done the cleaning in our repo.


Telegraf: fix flush_interval option

The Telegraf flush_interval option is not working correctly. The option was not being added to the telegraf.conf file. Add the missing flush_interval option to the template to fix this problem.

Merged, thanks!


Arrange name of derived data path

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context
This project has multiple name of derived data path (derived_data_path, derivedDataPath).
The number of derived_data_path is bigger than one of derivedDataPath by grepping.
So I arrange name of derived data path to derived_data_path.
Description
I fixed name of derived data path in xcodebuild.

I signed it!

Thanks @Nonchalant for your contribution. Wouldn't this break existing Fastfiles when merged and released?

@janpio Oh, that's right. My diff will break existing Fastfiles. Sorry, I will close this PR.


Change babywealthyclub strategy

Fixes # .
Changes proposed in this pull request:

@ChaituVR   When can it be merged into master？

Hey @claibornej Can't change the existing strategy, can create a new one?

gh pr checkout 1126

Hey @claibornej Can't change the existing strategy, can create a new one?

like this?
https://github.com/snapshot-labs/snapshot-strategies/pull/1126


Tag “C#” page show 404

When I click on the C# tag, page 404 appears. How did I figure it out that the " # " symbol is specific. How is this resolved?

https://discourse.gohugo.io/t/tag-c-page-show-404/12991
https://github.com/xianmin/hugo-theme-jane/pull/84
I added this patch

Yes, you fixed this bug. And it works if you click on the labels under the articles.
But if you click in the upper corner, where the categories and tags are. Then there is still a bug.

Thanks, fixed now.
[[params.nav.custom]]
title = "C#"
url = "/tags/c#/"

works well.

Excuse me. Apparently, I didn't describe the error very clearly.
If click on a category or tags, and then select a category or tag with C# from the list of categories or tags. So the 404 error is being made.
But if you click on the tag or categories under the page, it is displayed normally.

Updated, try again please.

Great thanks for help!


NavOption which opens a page without pushing it to the stack [v2]

Related issues: #6623 #6556
I currently have a splash page which opens either a main page, login page or setup page. I do not want users to be able to go back to the splash page. Currently, nav.push doesn't seem to have an option to prevent users from going back to the page which called it. I tried setting climbNav: false, but that doesn't seem to be related. As a result, perhaps a NavOption which opens a page without pushing it to the stack might be useful?

It sounds like in your case you could use setRoot:
// ... Logic that determines which page to go to ...
this._navController.setRoot(ThePage);

@biesbjerg Thanks for your reply - that solved what I wanted to do. I should've tested setRoot, so my bad for not doing so.


freertos: proposal for changes to task scheduling (IDFGH-5635)

This is a quick proposal to fix the issues described below.  Please review as I can't claim this is well thought out or fully tested.

ToDo: This scheduler doesn't correctly implement the round-robin scheduling as done in the single-core
*  FreeRTOS stack when multiple tasks have the same priority and are all ready; it just keeps grabbing the
*  first one. ToDo: fix this.
*  (Is this still true? if any, there's the issue with one core skipping over the processes for the other
*  core, potentially not giving the skipped-over processes any time.)

These are the results of a test that creates 5 tasks on each core that share the idle priority and never block, relying only on time-slicing and preemption to share CPU.
Without patch:
Running tasks CPU usage:
 main                   2193789         <1%
IDLE            111006000               39%
test task 1-0   30180030                10%
test task 1-1   28000021                9%
test task 0-0   56530016                20%
test task 0-1   27990017                9%
test task 0-2   27990016                9%
test task 0-3   27990017                9%
test task 0-4   27990017                9%
test task 1-2   139960022               49%
test task 1-3   27990021                9%
test task 1-4   27990021                9%
IDLE            27559788                9%
ipc0            4871            <1%
esp_timer       19              <1%
ipc1            9897            <1%

With patch:
Running tasks CPU usage:
 main                   6513760         <1%
test task 0-1   135528372               16%
test task 1-1   134210021               16%
test task 1-4   137530021               16%
test task 1-2   134090021               16%
test task 0-2   134181705               16%
test task 1-0   137600029               16%
test task 0-3   135561710               16%
test task 1-3   134180021               16%
test task 1-4   134151800               16%
IDLE            137689790               16%
IDLE            135641756               16%
test task 0-0   133730769               16%
esp_timer       17              <1%
ipc1            9884            <1%
ipc0            4858            <1%

Thanks for your contribution.

@zikalino do you want to review this?

Note: Freertos smp does a similar thing
https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/fa6982c99ad2a77693f31b7f40a92469dc35753a/tasks.c#L929-L930

@negativekelvin Thank you for your contribution. The new "Best Effort Round Robin" scheduling in https://github.com/espressif/esp-idf/commit/8babb3bca6f206ea463d125e2e8ab174d94818a0 should now implement these changes.

@Dazza0
This PR was created quite long time ago.
I'm surprised you didn't merge it without any comments.
IMHO, this discourages people to contribute.


Update the Shop Now button of the Fruit Website

Decribe the Feature you want to end
[GSSoC'23] The button which is there on the website is simple and I want to change its appearance and make it more cool.
Expected behavior
After the changes have been made, the user will be able to hover over the button and will definitely love it.

I would like to work in this project. Can you Please assign me in this project

hey @JPV2207   , If you want to make any changes in existing features or, project. Then, it would be great if you share relevant screenshots.

I have added the screenshots sir.

I would like to work on this project under GSSOC'23.Please Assign me this task

I would love to work on this project under GSSOC'23.Please Assign  this task to me.


Chromatic aberration when the opponent presses a note (LUA/Script)

Describe your problem here.
I need some script that makes when the opponent presses a note it creates a chromatic aberration effect for a few milliseconds
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No response

Lua not LUA

Lua not LUA

Does it really affect anything?
I'm still going to change it


Will you update the mod to ersion 1.14.4?

@TridentMC I know it's already for 1.14.3 but 1.14.4 is the one I use and I would like you to update it to that version

Could you please put the mod for 1.14.4,i need

Could you please put the mod for 1.14.4,i need

When you have done this please send me a message

When you have done this please send me a message

Put it on as soon as possible because i really need a lot

Put it on as soon as possible because i really need a lot


TypeError: 'NoneType' object is not subscriptable

python create_data.py create_kitti_info_file --data_path=$KITTI_DATASET_ROOT
Generate info. this may take several minutes.
Traceback (most recent call last):
File "create_data.py", line 303, in
fire.Fire()
File "/home/cicv/anaconda3/envs/pointpillars/lib/python3.7/site-packages/fire/core.py", line 127, in Fire
component_trace = _Fire(component, args, context, name)
File "/home/cicv/anaconda3/envs/pointpillars/lib/python3.7/site-packages/fire/core.py", line 366, in _Fire
component, remaining_args)
File "/home/cicv/anaconda3/envs/pointpillars/lib/python3.7/site-packages/fire/core.py", line 542, in _CallCallable
result = fn(*varargs, **kwargs)
File "create_data.py", line 83, in create_kitti_info_file
_calculate_num_points_in_gt(data_path, kitti_infos_train, relative_path)
File "create_data.py", line 41, in _calculate_num_points_in_gt
info["img_shape"])
File "/home/cicv/PointPillars/second.pytorch/second/core/box_np_ops.py", line 648, in remove_outside_points
indices = points_in_convex_polygon_3d_jit(points[:, :3], frustum_surfaces)
TypeError: 'NoneType' object is not subscriptable

refer to #61
I meet the same problem... Try
conda install numba=0.39


postgresqlPackages.pg_auto_failover: 1.4.0 -> 1.4.1

Motivation for this change
https://github.com/citusdata/pg_auto_failover/releases/tag/v1.4.1
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[X] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.


[ZEPPELIN-1116]send out more exception msg

What is this PR for?
better jdbc error msg make people know the true error clearly.
What type of PR is it?
Improvement
What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-1116
How should this be tested?
Outline the steps to test the PR here.
Screenshots (if appropriate)

Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

in sql case, the real error exception stack is hide in e.getCause.getCause. use printStackTrace to receive all the stack trace make people know true reason.

LGTM

I have a question. Is it OK not to close baos explicitly in multi user environments?

thanks your advice, It seems that the memory-based ByteArrayOutputStream do not need a close() method to release resources.
Here is an answer at http://stackoverflow.com/questions/2330569/closing-a-bytearrayoutputstream-has-no-effect

@passionke Sorry for the late reply. Thanks for the comment. LGTM.

@passionke Can you tell me your jira id?

I found you as your email.


.row--align-items-center doesn't exist

Needs to be added to _row.scss

Will be fixed when develop is merged into master.


CLI setup script failing due to cannot find zip file

Reported by Jagannath S Bilgi in Slack.
Trying to setup langstream CLI on GKE cluster using following command.
"sudo curl -Ls "https://raw.githubusercontent.com/LangStream/langstream/main/bin/get-cli.sh" | bash"
However getting below error.
"unzip:  cannot find zipfile directory in one of /home/jagannath_bilgi/.langstream/downloads/langstream-cli-0.2.0.zip or
/home/jagannath_bilgi/.langstream/downloads/langstream-cli-0.2.0.zip.zip, and cannot find /home/jagannath_bilgi/.langstream/downloads/langstream-cli-0.2.0.zip.ZIP, period.
'ARCHIVE_OK=$(unzip -qt "$downloaded_zip_path" | grep 'No errors detected in compressed data')': command failed with exit code 1."
Note: Have verified that "langstream-cli-0.2.0.zip" file is present.
Attached snippet for reference. Kindly advise how to resolve the same

@nicoloboschi Any ideas on why this is failing?

It was a temporary error during the download (from a previous command).
The solution was to delete the zip and re-run the installation
I don't think we need to handle this case in the installer


The mouse pointer does not change after the flyout control exceeds the screen boundary

Describe the bug
When set a flyout control shouldconstraintorootbounds attribute to false, add hyperlinkbutton, dock the mouse pointer will not change in the control, or the default pointer
Steps to reproduce the bug
1.Create flyout control.
2.Set flyout shouldconstraintorootbounds=false
3.add hyperlinkbutton in flyout
4.put the mosue cursor in hyperlinkbutton
Expected behavior
The mouse cursor can be changed.
Screenshots

NuGet package version
Windows App SDK 1.4 Preview 1: 1.4.230628000-preview1
Packaging type
Packaged (MSIX)
Windows version
Windows 11 version 22H2 (22621, 2022 Update)
IDE
Visual Studio 2022-preview
Additional context
No response

Still reproducible in Windows App SDK 1.5.3: 1.5.240428000. Also with TextBox and I-Beam cursor:

Similar issue reported in #9023, is still present in the most recent version of the Windows App SDK.
Will a fix be available soon?


When will this part of the fix be released as a gem?

https://github.com/javan/whenever/blob/81fc0c675c3d8f69a4220f3453c16e3a0d92b8d4/lib/whenever/capistrano/v3/tasks/whenever.rake#L54
Even with the latest whenever 0.10.0, the code is still old.

Released in 0.11.0

Thanks! 👍


Investigate CheckIt.latex_system_from_matrix

Fixed my faux pas in https://github.com/StevenClontz/checkit/commit/341b943b069a1ad885101de4f9e62a6e389e027e - passing an empty list as a default argument is bad news, as the same empty list is reused each time (including anything appended to the list as a side effect).


Forgot to complete

You forgot to close the icon in the snippet bellow Icon Prefixes (http://materializecss.com/forms.html).
I put in yellow on the pic above.
I don't know if this is the right place to put this kind of issue.

If you'd like, you can submit a pull request with a fix: https://github.com/Dogfalo/materialize/blob/master/jade/page-contents/forms_content.html#L253


Allow opt-out to namespace deletion when Project is deleted

Checklist

[x] I've searched the issue queue to verify this is not a duplicate feature request.
[ ] I've pasted the output of kargo version, if applicable.
[ ] I've pasted logs, if applicable.

Proposed Feature
I would like to have an option to say Kargo that I do not want it to delete namespace when kargo Project is deleted.
Motivation
I noticed that there is option to use existing namespaces: https://github.com/akuity/kargo/issues/2528 however when I used it and then I deleted Kargo Project half of my cluster went missing :/
Because Kargo is creating namespaces based on Project names there is higher chance there will be some conflicts. Because if Kargo Project is used to represent Bounded Context in organization there is high chance we already have namespace with name of that Bounded Context.
Suggested Implementation

could be an option in helm chart which would be rendered to some Kargo configmap
adding label / annotation indicating the namespace should not be deleted

I think there are some difficult security implications to this.
I do think this is a good idea, but we need to be very careful about how it is implemented.
On the security front, what you would not want is for someone to delete a Project, have the namespace stick around, and then have someone add a new Project with the same name, have it adopt that namespace, and this would effectively permit a new Project to hijack and old one, including credentials/Secrets. We would probably have to do this similar to what k8s does with PVs/PVCs and "reclaim policies."
Unrelated to that, we would also have to figure out an efficient way of preventing reconciliation of Kargo resources living in a namespace that no longer has a Project associated with it.

I dont have experience with this too much, but my expectation is that Kargo will delete only things created by itself? Then it should be kind matter of just labeling / annotating resources? I think ArgoCD does the same.
I have probably very simplified view about this again 😄 and in reality it will not be that simple 🤷

my expectation is that Kargo will delete only things created by itself?

I'm not sure I see how this is relevant to the things I said we'd have to watch out for if we were to implement this.

I'm not sure I see how this is relevant to the things I said we'd have to watch out for if we were to implement this.

Well if you delete Project then everything created by Kargo would be gone right? That means there is nothing to be hijacked because all connected service accounts, all secrets and other stuff would be deleted with Project 🤷

But this assumes that once a Project creates a Namespace, people would not go and add additional things to this this which are not managed by Kargo. Which I don't think can be assumed to be true.

I would make it an option then. Option to indicate that NS should be deleted no matter what it contains

Well if you delete Project then everything created by Kargo would be gone right?

Ah. I didn't understand this to be what you were asking for.
I assumed that in asking for (the option for) a namespace to not be deleted, you'd also want to preserve what's in the namespace.
What exactly would be the point of not deleting the namespace if your expectation is for Kargo to manually clean up everything within it?

What exactly would be the point of not deleting the namespace if your expectation is for Kargo to manually clean up everything within it?

not everything, just things created by Kargo itself.
The point is that you can share namespace with your other applications.
Lets say you have onboarding namespace which contains all onboarding related microservices and you want to have Kargo Project called onboarding. Currently you cant do that because you risk that Kargo will delete all your microservices...
The only option is to move cargo to separate cluster, if we want to do that we need to move argocd as well because that is Kargo requirement....

not everything, just things created by Kargo itself.

Kargo creates Freight. It might create Promotions if you have auto-promotion enabled for some Stages. Everything else in a Project is created by you. That includes Warerhouses, Stages, and most importantly, Secrets. If Kargo cleans up things it created, Secrets remain and my concern about hijacking the namespace remains as well. If you have actual application resources, including Secrets in that namespace, my concern about hijacking actually increases.

The point is that you can share namespace with your other applications.
Lets say you have onboarding namespace which contains all onboarding related microservices and you want to have Kargo Project called onboarding.

We absolutely, positively did not intend for people to have their Kargo resources and the applications managed by those resources in the same namespace. Please don't do that. That wouldn't even be an option in a lot of cases, because Kargo isn't always on the same cluster as your application(s).

The only option is to move cargo to separate cluster

This is actually common and it is this way by design. Kargo resources live in a common Kargo control plane that is visible to Kargo controllers running in many different clusters.

if we want to do that we need to move argocd as well because that is Kargo requirement.

This is also not true. A single Kargo controller can live in any cluster and can interface with one Kargo control plane and one Argo CD control plane. Either or both of those things can be remote from the perspective of the controller.
Admittedly, this hasn't been well-documented yet.
I'm going to close this issue because now that I understand more clearly what you are asking for, it's not something that we're going to consider.
If you need more help understanding topological issues, please raise the question in the Discord community or browse other issues to see there has been a lot of prior Q and A about how how the pieces all connect.


STORM-864 Exclude storm-kafka tests from Travis CI build

Please refer https://issues.apache.org/jira/browse/STORM-864 to see why I'm trying to exclude storm-kafka from Travis CI.
After applying this patch, we can get rid of random test failures on storm-kafka with Travis CI.
Please note that there's small probabilities to random test failures on storm-core yet.

+1

Thank you @HeartSaVioR. I have merged the change in. This should help us get better feedback on the pull request from CI build.

@kishorvpatil Thanks for reviewing and merge. :)


[BUG] Kibana throws errors 500/401 one hour after login when using SAML

Describe the bug
1 hour after login, Kibana will show one of these 2 errors instead of the requested page:

On the root domain of Kibana: {"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred."}
On all other pages: {"statusCode":401,"error":"Unauthorized","message":"Response Error"}

The only way to work around this issue is to delete cookies.
To Reproduce
Steps to reproduce the behavior:

Login to Kibana via a SAML Identity Provider (e.g. Okta)
Wait for 1 hour
Try to refresh/browse to a new Kibana page
See that Kibana shows {"statusCode":401,"error":"Unauthorized","message":"Response Error"} instead of showing the requested page
See that Kibana shows {"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred."} when manually going to the root Kibana domain

Note: to create the Okta app, I followed the instructions here: AWS - Add Single Sign-On (SSO) to Open Distro for Elasticsearch Kibana using SAML and Okta.
Expected behavior
The internal JWT created by OpenDistro (I'm not sure exactly what component creates it) should be automatically renewed and Kibana shouldn't throw an error (either 401 or 500) when visiting a page 1 hour or more after initial login.
Logs
ES Node Logs
[2021-09-15T09:08:24,861][TRACE][c.a.o.s.a.BackendRegistry] [es3.logs.example.com] Rest authentication request from <IP_ADDRESS>:32528 [original: /<IP_ADDRESS>:32528]
[2021-09-15T09:08:24,861][DEBUG][c.a.o.s.a.BackendRegistry] [es3.logs.example.com] Check authdomain for rest noop/0 or 2 in total
[2021-09-15T09:08:24,861][TRACE][c.a.o.s.a.BackendRegistry] [es3.logs.example.com] Try to extract auth creds from clientcert http authenticator
[2021-09-15T09:08:24,861][TRACE][c.a.o.s.h.HTTPClientCertAuthenticator] [es3.logs.example.com] No CLIENT CERT, send 401
[2021-09-15T09:08:24,861][TRACE][c.a.o.s.a.BackendRegistry] [es3.logs.example.com] No 'Authorization' header, send 403
[2021-09-15T09:08:24,861][DEBUG][c.a.o.s.a.BackendRegistry] [es3.logs.example.com] Check authdomain for rest noop/1 or 2 in total
[2021-09-15T09:08:24,861][TRACE][c.a.o.s.a.BackendRegistry] [es3.logs.example.com] Try to extract auth creds from saml http authenticator
[2021-09-15T09:08:24,862][INFO ][c.a.d.a.h.j.AbstractHTTPJwtAuthenticator] [es3.logs.example.com] Extracting JWT token from [REDACTED JWT TOKEN HERE] failed
com.amazon.dlic.auth.http.jwt.keybyoidc.BadCredentialsException: The token has expired
	at com.amazon.dlic.auth.http.jwt.keybyoidc.JwtVerifier.getVerifiedJwtToken(JwtVerifier.java:85) ~[opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator.extractCredentials0(AbstractHTTPJwtAuthenticator.java:108) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator.access$000(AbstractHTTPJwtAuthenticator.java:47) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator$1.run(AbstractHTTPJwtAuthenticator.java:90) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator$1.run(AbstractHTTPJwtAuthenticator.java:87) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at java.security.AccessController.doPrivileged(AccessController.java:312) [?:?]
	at com.amazon.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator.extractCredentials(AbstractHTTPJwtAuthenticator.java:87) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.dlic.auth.http.saml.HTTPSamlAuthenticator.extractCredentials(HTTPSamlAuthenticator.java:148) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.opendistroforelasticsearch.security.auth.BackendRegistry.authenticate(BackendRegistry.java:421) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.opendistroforelasticsearch.security.filter.OpenDistroSecurityRestFilter.checkAndAuthenticateRequest(OpenDistroSecurityRestFilter.java:177) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.opendistroforelasticsearch.security.filter.OpenDistroSecurityRestFilter.access$000(OpenDistroSecurityRestFilter.java:66) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.opendistroforelasticsearch.security.filter.OpenDistroSecurityRestFilter$1.handleRequest(OpenDistroSecurityRestFilter.java:113) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:258) [elasticsearch-7.10.2.jar:7.10.2]
	at org.elasticsearch.rest.RestController.tryAllHandlers(RestController.java:340) [elasticsearch-7.10.2.jar:7.10.2]
	at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:191) [elasticsearch-7.10.2.jar:7.10.2]
	at com.amazon.opendistroforelasticsearch.security.ssl.http.netty.ValidatingDispatcher.dispatchRequest(ValidatingDispatcher.java:63) [opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at org.elasticsearch.http.AbstractHttpServerTransport.dispatchRequest(AbstractHttpServerTransport.java:319) [elasticsearch-7.10.2.jar:7.10.2]
	at org.elasticsearch.http.AbstractHttpServerTransport.handleIncomingRequest(AbstractHttpServerTransport.java:384) [elasticsearch-7.10.2.jar:7.10.2]
	at org.elasticsearch.http.AbstractHttpServerTransport.incomingRequest(AbstractHttpServerTransport.java:309) [elasticsearch-7.10.2.jar:7.10.2]
	at org.elasticsearch.http.netty4.Netty4HttpRequestHandler.channelRead0(Netty4HttpRequestHandler.java:42) [transport-netty4-client-7.10.2.jar:7.10.2]
	at org.elasticsearch.http.netty4.Netty4HttpRequestHandler.channelRead0(Netty4HttpRequestHandler.java:28) [transport-netty4-client-7.10.2.jar:7.10.2]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at org.elasticsearch.http.netty4.Netty4HttpPipeliningHandler.channelRead(Netty4HttpPipeliningHandler.java:58) [transport-netty4-client-7.10.2.jar:7.10.2]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) [netty-handler-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1518) [netty-handler-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1267) [netty-handler-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1314) [netty-handler-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) [netty-codec-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:615) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:578) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) [netty-transport-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.49.Final.jar:4.1.49.Final]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.49.Final.jar:4.1.49.Final]
	at java.lang.Thread.run(Thread.java:832) [?:?]
Caused by: org.apache.cxf.rs.security.jose.jwt.JwtException: The token has expired
	at org.apache.cxf.rs.security.jose.jwt.JwtUtils.validateJwtExpiry(JwtUtils.java:58) ~[cxf-rt-rs-security-jose-3.4.0.jar:3.4.0]
	at com.amazon.dlic.auth.http.jwt.keybyoidc.JwtVerifier.validateClaims(JwtVerifier.java:119) ~[opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at com.amazon.dlic.auth.http.jwt.keybyoidc.JwtVerifier.getVerifiedJwtToken(JwtVerifier.java:81) ~[opendistro_security-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	... 74 more
[2021-09-15T09:08:24,865][DEBUG][c.o.s.a.AuthnRequest     ] [es3.logs.example.com] AuthNRequest --> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN_{SOME_UUID}" Version="2.0" IssueInstant="2021-09-15T09:08:24Z" ForceAuthn="true" Destination="https://subdomain.okta.com/app/xxx/yyy/sso/saml" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://kb.logs.example.com/_opendistro/_security/saml/acs"><saml:Issuer>logs-kibana-saml</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>
[2021-09-15T09:08:24,865][TRACE][o.e.i.b.in_flight_requests] [es3.logs.example.com] [in_flight_requests] Adjusted breaker by [0] bytes, now [0]
[2021-09-15T09:08:24,866][TRACE][o.e.h.HttpTracer         ] [es3.logs.example.com] [422][8027f54c-0e8c-4318-b8c8-a5fab657dd63][UNAUTHORIZED][text/plain; charset=UTF-8][0] sent response to [Netty4HttpChannel{localAddress=/<IP_ADDRESS>:9200, remoteAddress=/<IP_ADDRESS>:32528}] success [true]
[2021-09-15T09:08:24,866][TRACE][c.a.o.s.a.BackendRegistry] [es3.logs.example.com] No 'Authorization' header, send 401 and 'WWW-Authenticate Basic'

Kibana Server Logs
Sep 14 15:33:17 kb1.logs.example.com kibana[493]: {"type":"log","@timestamp":"2021-09-14T15:33:17Z","tags":["error","elasticsearch","data"],"pid":493,"message":"[ResponseError]: Response Error"}
Sep 14 15:33:17 kb1.logs.example.com kibana[493]: {"type":"log","@timestamp":"2021-09-14T15:33:17Z","tags":["error","http"],"pid":493,"message":"{ ResponseError: Response Error\n    at IncomingMessage.response.on (/us
r/share/kibana/node_modules/@elastic/elasticsearch/lib/Transport.js:272:25)\n    at IncomingMessage.emit (events.js:203:15)\n    at endReadableNT (_stream_readable.js:1145:12)\n    at process._tickCallback (internal/proc
ess/next_tick.js:63:19)\n  name: 'ResponseError',\n  meta:\n   { body: '',\n     statusCode: 401,\n     headers:\n      { 'x-opaque-id': '{SOME_UUID}',\n        'www-authenticate':\n         'X-S
ecurity-IdP realm=\"Open Distro Security\" location=\"https://subdomain.okta.com/app/xxx/yyy/sso/saml?SAMLRequest=some-base64-data\" requestId=\"ONELOGIN_{SOME_UUID}\"',\n        'content-type': 'text/plain; charset=UTF-8',\n        'content-length': '0' },\n
    meta:\n      { context: null,\n        request: [Object],\n        name: 'elasticsearch-js',\n        connection: [Object],\n        attempts: 0,\n        aborted: false } },\n  isBoom: true,\n  isServer: false,\n  d
ata: null,\n  output:\n   { statusCode: 401,\n     payload:\n      { statusCode: 401,\n        error: 'Unauthorized',\n        message: 'Response Error' },\n     headers: {} },\n  reformat: [Function],\n  [Symbol(SavedOb
jectsClientErrorCode)]: 'SavedObjectsClient/notAuthorized' }"}
Sep 14 15:33:17 kb1.logs.example.com kibana[493]: {"type":"error","@timestamp":"2021-09-14T15:33:17Z","tags":[],"pid":493,"level":"error","error":{"message":"Internal Server Error","name":"Error","stack":"Error: Inter
nal Server Error\n    at HapiResponseAdapter.toInternalError (/usr/share/kibana/src/core/server/http/router/response_adapter.js:69:19)\n    at Router.handle (/usr/share/kibana/src/core/server/http/router/router.js:177:34
)\n    at process._tickCallback (internal/process/next_tick.js:68:7)"},"url":{"protocol":null,"slashes":null,"auth":null,"host":null,"port":null,"hostname":null,"hash":null,"search":null,"query":{},"pathname":"/","path":
"/","href":"/"},"message":"Internal Server Error"}
Sep 14 15:33:17 kb1.logs.example.com kibana[493]: {"type":"response","@timestamp":"2021-09-14T15:33:17Z","tags":[],"pid":493,"method":"get","statusCode":500,"req":{"url":"/","method":"get","headers":{"x-forwarded-for"
:"<IP_ADDRESS>","x-forwarded-proto":"https","x-forwarded-port":"443","host":"kb.logs.example.com","x-amzn-trace-id":"Root=some-id","sec-ch-ua":"\"Google Chrome\";v=\"93\", \" Not;A Brand\";v
=\"99\", \"Chromium\";v=\"93\"","sec-ch-ua-mobile":"?0","sec-ch-ua-platform":"\"macOS\"","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko
) Chrome/93.0.4577.63 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9","sec-fetch-site":"none","sec-fetch-m
ode":"navigate","sec-fetch-user":"?1","sec-fetch-dest":"document","accept-encoding":"gzip, deflate, br","accept-language":"en-GB,en-US;q=0.9,en;q=0.8,fr;q=0.7"},"remoteAddress":"<IP_ADDRESS>","userAgent":"Mozilla/5.0 (Macin
tosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"},"res":{"statusCode":500,"responseTime":56,"contentLength":9},"message":"GET / 500 56ms - 9.0B"}

Host/Environment (please complete the following information):

OS: Ubuntu 20.04
ElasticSearch: OSS 7.10.2
Kibana (opendistroforelasticsearch-kibana): 1.13.2
OpenDistro versions:

opendistro-alerting               <IP_ADDRESS>-1
opendistro-anomaly-detection      <IP_ADDRESS>-1
opendistro-asynchronous-search    <IP_ADDRESS>-1
opendistro-index-management       <IP_ADDRESS>-1
opendistro-job-scheduler          <IP_ADDRESS>-1
opendistro-knn                    <IP_ADDRESS>-1
opendistro-knnlib                 <IP_ADDRESS>
opendistro-performance-analyzer   <IP_ADDRESS>-1
opendistro-reports-scheduler      <IP_ADDRESS>-1
opendistro-security               <IP_ADDRESS>-1
opendistro-sql                    <IP_ADDRESS>-1
opendistroforelasticsearch        1.13.2-1

Any news on this issue?
I just tested OpenSearch 1.0.0 and 1.1.0 and the issue is still present.
The only way to work around it is to delete cookies, which is a nightmare from an UX point of view/usability of the tool.
The JWT expiry setting could maybe be a workaround for this issue, but unfortunately this feature also has a bug: https://github.com/opensearch-project/security/issues/1448

cc @dblock just so you're aware of it as I believe it is a rather high impact bug.

Thanks for the report, @GuiTeK. Although not a security vulnerability, I agree that this is painful from the user experience standpoint. The team has not had time to look into it yet, but I've removed the untriaged label to make sure we have it on the list of issues ready to take on.

Related issues (although the root cause is not the parameters described in these two issues):

https://github.com/opensearch-project/security-dashboards-plugin/issues/71
https://github.com/opensearch-project/security-dashboards-plugin/issues/159

Hello, @GuiTeK all good!? Did you find a solution to this issue? I am currently validating the downgrade of the ES plugin "opendistro_security" from: <IP_ADDRESS> to: <IP_ADDRESS>. Keeping the Kibana plugin as it is.
It works, at least did not break anything. I will proceed with the same for my clusters and see how it behaves.
Thanks for the info regarding OpenSearch versions.

Hello, @GuiTeK all good!? Did you find a solution to this issue? I am currently validating the downgrade of the ES plugin "opendistro_security" from: <IP_ADDRESS> to: <IP_ADDRESS>. Keeping the Kibana plugin as it is. It works, at least did not break anything. I will proceed with the same for my clusters and see how it behaves. Thanks for the info regarding OpenSearch versions.

Replying to self:
ended up with:
Kibana 1.12 (7.10.0) + opendistroSecurityKibana <IP_ADDRESS>
My case with multiple Tenants suffers a lot fo the lack of real support to them + the session/cookie issue.
With this combination, I can finally see the 1hour timeout (from Azure). Before was a matter of 15 min or less.
But I feel that it will not be enough. So maybe next will try to change my infra (load balancer/request flow) or test with latest Opensearch version.
I guess that everyone is off for the year, is that right? Cheers!! :)

We observed this behaviour when the session keepalive is set to true. Setting it to false fixed it.
In dashboards.yml
opensearch_security.session.keepalive: false

However, we found another issue regarding to SAML timeouts. The IDP provides a expiry time, but OpenSearch only honors a specific option in the SAMLResponse. Auth0 for example sends it via a different option. Not sure who is in the wrong here. But in our case the work-around was to set the jwt.expiry setting manually
https://github.com/opensearch-project/security-dashboards-plugin/issues/159#issuecomment-1022438420

Confirmed with both saml and oidc

Hello hello! Forgot to post back. I ended up with normal settings (exactly like the official docs) no fancy stuff, normal versions all around. But, I use load balancers, previous person had several ÉS node type under the LB and kibana was pointed to this LB for auth. After pointing to a single client node it never happened again.

This is still an issue for anyone using openid_auth_domain

Yip. Tried different ttl values and combination of settings. Problem still persists

This issue is still present in version 2.1.0

Confirmed and very annoying.

I have the same problem

Any news on this one? This is one of the reasons I can't migrate an Elastic cluster to Opensearch because the team doesn't want tot deal with this session error.

Hello,
I have the same problem with Azure AD

[Triage 1/30/2023] This issue seems to be related to the cookie storage and potentially the access & refresh tokens expiring. We are passing a token but it does not have a good method of dealing with expiration between front-end and backend systems. @davidlago could you link this to the to-be-created ticket for session management so that this can be a considered use case. Thank you.

Hello,
I have the same problem with Azure AD

Also running into this issue with Azure AD.  I have not found a way to resolve this without manually clearing cookies for the issue browser.

Same problem @jperhamcatchteam
Are there any changes that can be made in the meantime to resolve this? Running Azure AD SSO as well and having to clear cookies to get back in.

Any updates about this? Seems ridiculous that such issue isn't fixed in two years...

We can still observe this issue in OpenSearch v2.7.0.

We have this issue with v2.8.0 using gitlab as our IDP and its 2 minute token sessions. As one can imagine it renders using dashboards with OIDC fairly unusable.

Hi there,
I'm able to reproduce this. While I do not get the 500 error (but as mentioned in previous comments, this seems to have been improved in more recent versions), I am redirected back to the IdP even though my token is still valid.
I believe this line is the offender: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/session/security_cookie.ts#L67
That validate function is used when configuring Hapi's cookie.
if (sessionStorage.expiryTime === undefined || sessionStorage.expiryTime < Date.now()) {
      return { isValid: false, path: '/' };
}

session.expiryTime is set when the cookie is first created, and it is extended on each authenticated request if opensearch_security.session.keepalive is set to true. But keepaliveonly extends the cookie when there is an actual request - so if the "session" timeouts between requests, it won't help.
So where does that value come from?
In the case of OIDC, here: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/openid/routes.ts#L197
OIDC also checks the claim for an expiration time, which is then also correctly set and validated. But I believe expiryTime takes precedence in the cookie's validate function.
For SAML, this is handled a bit differently. If there is an expiration set in the IdP payload, that value is used as expiryTime. At least as long as that claim is called 'exp'). But then again, if the 'keepalive' setting is true, that value will be overridden by 'opensearch_security.session.ttl': https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/authentication_type.ts#L158
If I'm correct, this issue should happen after after the time of the last request + whatever seconds (or rather milliseconds) are defined in opensearch_security.session.ttl...

A fix would be welcome, thanks for the research. Bug is still present in 2.11.

I am having same issue with OIDC and Dashboards 2.11 :(
After 10 minutes the token is expired, and the users receiving 401 codes.

Pardon the delay on this, I will try to come up with a solution and post an update here.

Hello @jochen-kressin
Can you share with us some updates about the issue?
Many thanks for all your work, we are very grateful :)

@SergioIbIGZ Not much to share yet, investigating if we can just remove the session.ttl setting.
If you're using SAML, for now you may be able to fix the problem by just setting
opensearch_security.session.keepalive to false, as mentioned here: https://github.com/opensearch-project/security-dashboards-plugin/issues/828#issuecomment-1022442439
If there is an exp property coming from your IdP, this will then be used. Setting keepalive to false prevents that from being overridden with whatever you have in session.ttl.

Hello,
Thanks for your response.
No, we are using "jwt"; we use "openid" auth. But the error/problem is the same as described in this issue (IMO, maybe I am wrong). For example:
[2023-12-14T11:27:07,592][INFO ][c.a.d.a.h.j.AbstractHTTPJwtAuthenticator] [tip-master-1] Extracting JWT token from eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJYRTk1NDQ0IiwiY291bnRyeSI6IkVTUCIsInJvbGVzIjpbIkJCVkFfSE8tVklFV0VSX0NUSSJdLCJraWQiOiJyc2ExIiwiaXNzIjoiaHR0cHM6XC9cL2lkcC5saXZlLmdsb2JhbC5wbGF0Zm9ybS5iYnZhLmNvbVwvb2lkY1wvIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiWEU5NTQ0NCIsImdpdmVuX25hbWUiOiJTRVJHSU8iLCJhdWQiOiIxMGMzYzhhNi0zZjc4LTQ5M2UtYTc4Ny02MTJkODcwMjFhZGQiLCJuYW1lIjoiW0V4dGVybmFsXSBTRVJHSU8gSUJBw5FFWiBET01JTkdPIiwiZXhwIjoxNzAyNTUyMTU1LCJpYXQiOjE3MDI1NTE1NTUsImp0aSI6IjQxZGM0ZGViLThmMjMtNDUwYi04OTIzLTc1ZjM3ZjM5NWI4NiIsImVtYWlsIjoiU0VSR0lPLklCQU5FWi5DT05UUkFDVE9SQEJCVkEuQ09NIn0.mwMA0tnhvOPK14kY39MjPawYiklH3TlnHMwBM63K8AABfAIFtz-Ra_8uwy3AfHODKdTzDhOigYU5oFNJlVoudnzRAZek7uDk2YUsYRb3of4zIKJt3tBPkaHOrYOGHUGIQsgeX3kNQewKMPIvmiLgGw-r0Ep5kKbm228TRXhlbWOt_Y_TDj1KqF5SCv2rkr60wiJVt19nPSbzK2WlLhkE_227ywC1gwo9N1lvSH6qoO82o4If75O4L0ddO6crvaE97amgeCxi9jaI6_QM0U9lSX9kGoAvK1kb0ik90NJGnaVBqetw-WWVykZMsxUFDL8dlDP8eMNCRCOwayrDM2_EUQ failed
com.amazon.dlic.auth.http.jwt.keybyoidc.BadCredentialsException: The token has expired

In my case the token expires in only 10 minutes and it is quite painful.
Thanks :)

@SergioIbIGZ Reading your log message, and also going through the other logs mentioned in this issue, I may have been to quick with my problem analysis above.
Could you maybe post your opensearch_dashboards.yml settings related top openid here?
Also, your opensearch_security.session settings would be interesting to see.
Do you know if your tokens has any expiration time defined?

Hello again,
Out openid tokens TTL is 12 hours.
This is my opensearch_dashboards.yml settings:
        opensearch_dashboards.yml: |
            # OPENID CONFIG
            opensearch_security.auth.type: "openid"
            opensearch_security.openid.connect_url: "https://idp.live.*****"
            opensearch_security.openid.client_id: "******************************"
            opensearch_security.openid.client_secret: "*********************************"
            opensearch_security.openid.base_redirect_url: "https://search.****"
            opensearch_security.openid.scope: "openid profile email"
            opensearch.ssl.verificationMode: none
            opensearch_security.openid.refresh_tokens: true
            opensearch_security.session.keepalive: false
            opensearch_security.session.ttl: 43200000
            opensearch_security.cookie.ttl: 43200000
            logging.verbose: "true"

As additional info, I asked to my OPENID - IDP admins team about this log that I show you before:
[2023-12-15T11:26:03,606][WARN ][stderr                   ] [tip-master-4] WARNING: Invalid cookie header: "Set-Cookie: _abck=4E25B1E3D81AE7AB946634EADA237E7B~-1~YAAQ7ZrYF5yY/mOMAQAAVPM5bQtr3G/qB0l+o+nrSO76lad2w5YcwovSgCUxts5zstjN45ES23olMQgB7bQmkxit3EdzB1NiFo3lP5v8zLmo8uDXwwol0r9Uw0/bah9t57oVWqUrEpQVJZb2wMEgylCwOQ7zHaZCYyYxk8gLBS5iBzWIcKvhePXIrLw/6NVsODI0cOImJ3rjCfY9FW2CWf7GbD4POuQdgEtR4IRGs9+hPaHe2U6WgPZqEcyPjvyc9Drzh8sXymqnJzwar67oTz9v9arJLVdbJt5p3A0O6boOe+Tz3QNo2JUwAk+7nX/b6jM6I8566S5Dsps4IlDW8Tv9i3w/DdZAYcCVBEjnNb+GBpH/RftcVJE=~-1~-1~-1; Domain=.acme.com; Path=/; Expires=Sat, 14 Dec 2024 11:26:03 GMT; Max-Age=31536000; SameSite=None; Secure". Invalid 'expires' attribute: Sat, 14 Dec 2024 11:26:03 GMT

Their opinion is that it can be a issue similar to this:
https://www.lenar.io/invalid-cookie-header-invalid-expires-attribute/
https://github.com/aws/aws-sdk-java-v2/issues/2421
https://stackoverflow.com/questions/39699123/it-seems-that-set-cookie-having-an-expiration-format-mon-25-sep-2017-134002-g
But personally I have searched related issues in Opensearch github.com and I found nothing. So it sounds weird to me.

@SergioIbIGZ Hmm I've never seen that error before. Does it show up on each request?
And the name "_abck" - have your renamed the dashboards cookie to be called that, or is it maybe some other cookie that is attached to the request?
I'm starting to think this may have to do with your backend auth configuration. Your Dashboards config seems correct to me. I was going to say you may need to set keepalive to true, but even if it is false, the plugin should not invalidate the token after 10 minutes - it should use the 12 hours you've defined in session.ttl.
Another thing I noticed but am not 100% sure about: in some cases you may need to add offline_access to the scope config option in order for the IdP to refresh a token. E.g. my local instance of Keycloak requires it, and I also have to add offline_access in Keycloak's Scope Mapping.
But I don't think that explains your original problem.

Hello @jochen-kressin . Thank you for your answers.
I tried adding "offline_access" to the scope but our IDP does not work, is invalid for it :(
Apart of this, yesterday I made a interesting POC. I installed the last version of OpenSearch (2.11) with the latest version of OpenSearch Dashboards 2. Using Helm and applying the exact SAME config as we use in OpenSearch 1.x, including OpenID.
For my surprise, in OpenSearch 2.x logs appears the cookie expire invalid error, but in OpenSearch Dasboards 2.x does NOT appears the BadCredentialsException that exist in the 1.x version. For your reminder:
[2023-12-14T11:27:07,592][INFO ][c.a.d.a.h.j.AbstractHTTPJwtAuthenticator] [tip-master-1] Extracting JWT token from eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJYRTk1NDQ0IiwiY291bnRyeSI6IkVTUCIsInJvbGVzIjpbIkJCVkFfSE8tVklFV0VSX0NUSSJdLCJraWQiOiJyc2ExIiwiaXNzIjoiaHR0cHM6XC9cL2lkcC5saXZlLmdsb2JhbC5wbGF0Zm9ybS5iYnZhLmNvbVwvb2lkY1wvIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiWEU5NTQ0NCIsImdpdmVuX25hbWUiOiJTRVJHSU8iLCJhdWQiOiIxMGMzYzhhNi0zZjc4LTQ5M2UtYTc4Ny02MTJkODcwMjFhZGQiLCJuYW1lIjoiW0V4dGVybmFsXSBTRVJHSU8gSUJBw5FFWiBET01JTkdPIiwiZXhwIjoxNzAyNTUyMTU1LCJpYXQiOjE3MDI1NTE1NTUsImp0aSI6IjQxZGM0ZGViLThmMjMtNDUwYi04OTIzLTc1ZjM3ZjM5NWI4NiIsImVtYWlsIjoiU0VSR0lPLklCQU5FWi5DT05UUkFDVE9SQEJCVkEuQ09NIn0.mwMA0tnhvOPK14kY39MjPawYiklH3TlnHMwBM63K8AABfAIFtz-Ra_8uwy3AfHODKdTzDhOigYU5oFNJlVoudnzRAZek7uDk2YUsYRb3of4zIKJt3tBPkaHOrYOGHUGIQsgeX3kNQewKMPIvmiLgGw-r0Ep5kKbm228TRXhlbWOt_Y_TDj1KqF5SCv2rkr60wiJVt19nPSbzK2WlLhkE_227ywC1gwo9N1lvSH6qoO82o4If75O4L0ddO6crvaE97amgeCxi9jaI6_QM0U9lSX9kGoAvK1kb0ik90NJGnaVBqetw-WWVykZMsxUFDL8dlDP8eMNCRCOwayrDM2_EUQ failed
com.amazon.dlic.auth.http.jwt.keybyoidc.BadCredentialsException: The token has expired

So when a user log-in in OpenSearch Dashboards 2.x, the 401/Unauthorized error 10 minutes after the login, does NOT occurs. The session is kept alive or maybe the token is able to be refreshed.
The conclusion for me is that "com.amazon.dlic.auth.http.jwt.keybyoidc" is different, o maybe another version, in 2.x and it works properly with our IDP and its cookies.
Can you tell me about it? Is there possible to study a possible fix for 1.x?
Thanks for your time and dedication :)

Any updates on this one? Would really love for this to be solved in 2.12. This one is very annoying :)

Hi @sandervandegeijn, I don't know of any active efforts to fix this. I will remove the Triaged label so the matainers can review this issue during the Triaging meeting later today and add an update below.

[Triage] Seems like this is still an issue and something is going wrong with the behavior when using external IdPs and dashboards. Based on the discussion any data is lost from the active session if a redirect to refresh the token is executed during making a changes. I.e. making filters and then a token refresh causes you to lose all of the filters. We should try to prioritize this based on the long life of this issue.

@GuiTeK @sandervandegeijn I am beginning to pick this up, and new tho this space. Can you share your settings for opensearch_security.session.ttl and opensearch_security.session.keepalive as well as any settings from the saml provider that you have, such as the expiry/ assertion lifespan? I am seeing some behavior on my local and not sure if it is what you are talking about - is the bug that after some certain amount of time OSD can re-routed back to the saml provider to re-authenticate even though the assertion should still be valid? I do see this on my local, but I do not see the 401's/error pages that you folks were mentioning?

We are at the defaults. I'm not running SAML anymore, but with openid it's basically the same thing. Leave the dashboards app for 30 minutes or so, click on the next page and it will kick off the authentication flow (which is better than it was in the past, then it would just throw the 401 and be done with it). This is fast and another problem is dat it loses all the state that you had like filters. :)

I am doing the same as @sandervandegeijn - using OpenID via Azure AD and the same thing happens to us.

Understood. I do think there is a bug/confusion here regarding the whole management of sessions. Would you folks be able to provide some feedback on this issue? https://github.com/opensearch-project/security-dashboards-plugin/issues/1711? Additionally a few questions/comments for you (I am still trying to wrap my head around it so there will be more to come!)

Is there anything preventing you from updating keepalive to false and opensearch_security.session.ttl to match the expiry of the assertion/exp field? This might not solve for cases in which the exp is actually short lived (that may be a separate issue of doing the best to preserve URls, filters, etc.), but this should solve for the redirection. I believe the defaults here: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/index.ts#L78 are the root case of this
Can you folks help me understand in which case would people want the session within OSD to actually be shorter than the validity of the result received from the IDP? We may want to set some sensible defaults in the case that it is not set in a way we expect by the IDP, but any other reasons to have this mismatch?

Actually, I checked, I set the timeouts to one day. Removed the settings, so now I'm on the defaults. Will test again.
I do not understand why you would override the timeout from the IDP. If you need it shorter, you should fix it at the IDP's side I would suppose?
This also seems related: https://github.com/opensearch-project/security-dashboards-plugin/issues/159#issuecomment-1022438420

Actually, I checked, I set the timeouts to one day. Removed the settings, so now I'm on the defaults. Will test again.
I do not understand why you would override the timeout from the IDP. If you need it shorter, you should fix it at the IDP's side I would suppose?
This also seems related: #159 (comment)

Problem persists.

From a user perspective: mighty irritating!  All selections and filtering gone. So back to the ELK setup for daily work.

Hello again, Probably this information is not useful here but I would like to share it with you.
As I said in #828 (comment) in our case, the IDP and its cookie is configuring to try to set 12 hours as Dashboards session ttl. But at the end that session is closed with a 401 error after only 10 minutes (I don't know why in our case is only that time).
Our parcial workaround is configuring this settings:
opensearch_security.openid.refresh_tokens: false
opensearch_security.session.keepalive: true
opensearch_security.session.ttl: 180000
opensearch_security.cookie.ttl: 180000

As you can see, the session ttl is only 3 minutes. But what we achieve with that is a browser "auto-reload" to dashboards login each that time. It is annoying but doing this, the 401 error does NOT occurs. But the users have to save its work continuosly to don't lose it, or course.
Thanks!

@SergioIbIGZ If I am reading your situation correctly, it seems like you have issues on 1.x line, but the issue is not on 2.x line? Unfortunately we do not develop for 1.x anymore anymore, and would recommend you upgrade to 2.x. https://opensearch.org/releases.html. That being said, I am going to shortly post a summary on this issue and close it out with the merging of a recent PR. Feel free to open another issue if something that is affecting 2.x comes up, or if I am not understanding your problem correctly. Thanks!

This issue is getting a little long in the tooth and it's getting hard for me to diagnose/help individual folks with their problems. That being said, it seems to me like there's several issues mentioned, some related, and some not, and some based on opendistro, which may or may not be out of date. From what I see the issues are:

SAML assertion assumptions not allowing auth0 to be properly read. I created a follow up issue in the security repo since SAML assertion reading is done there: https://github.com/opensearch-project/security/issues/4046. @mvanderlee can you comment on whether customizing SAML assertion fits your use case? I am new to the space so not sure if I am reading that this might help?
Any OIDC cookie expiry issues to anything less than the opendistro_security.cookie.ttl, which defaults to 1 hour should be handled in https://github.com/opensearch-project/security-dashboards-plugin/pull/1773
Any cookie expiry issues where keepalive is true (which is the default) should be handled in https://github.com/opensearch-project/security-dashboards-plugin/pull/1773

I will be closing this issue with the merging of https://github.com/opensearch-project/security-dashboards-plugin/pull/1773. Anybody please feel free to open a follow-up issue with detailed reproduction steps (IDP, opensearch_dashboards.yml settings, opensearch security backend config, etc.) so I can better address individual concerns. Thanks!
Additionally, we have a RFC https://github.com/opensearch-project/security-dashboards-plugin/issues/1711 to discuss confusion around some of the settings. If anyone has any thoughts, please leave them there, thanks!
@GuiTeK @rmelilloii @sandervandegeijn @mhoydis13 @SakuraAxy @FryggFR @jperhamcatchteam  @Beeez @K3ndu @tr0k
@mkhpalm @SergioIbIGZ @andrew-landsverk-win @atbohmer

Thanks for the effort Derek, we haven't made it easy for you ;)

Hello again, Probably this information is not useful here but I would like to share it with you.
As I said in #828 (comment) in our case, the IDP and its cookie is configuring to try to set 12 hours as Dashboards session ttl. But at the end that session is closed with a 401 error after only 10 minutes (I don't know why in our case is only that time).
Our parcial workaround is configuring this settings:
opensearch_security.openid.refresh_tokens: false
opensearch_security.session.keepalive: true
opensearch_security.session.ttl: 180000
opensearch_security.cookie.ttl: 180000

As you can see, the session ttl is only 3 minutes. But what we achieve with that is a browser "auto-reload" to dashboards login each that time. It is annoying but doing this, the 401 error does NOT occurs. But the users have to save its work continuosly to don't lose it, or course.
Thanks!

@SergioIbIGZ If I am reading your situation correctly, it seems like you have issues on 1.x line, but the issue is not on 2.x line? Unfortunately we do not develop for 1.x anymore anymore, and would recommend you upgrade to 2.x. https://opensearch.org/releases.html. That being said, I am going to shortly post a summary on this issue and close it out with the merging of a recent PR. Feel free to open another issue if something that is affecting 2.x comes up, or if I am not understanding your problem correctly. Thanks!

That's right @derek-ho.  I already tested it in 2.x and my issue is not present. So I will suggest to update to that version.
Thanks a lot :)


allow dns hosts; fix notifications concurrency issues

Fix intermittent Notifications test by isolating its GenServer state and Phoenix.PubSub topic.
Allow hosts to be entered for the DNS field.

Fixes #978

Pull Request Test Coverage Report for Build 4c1bc4d98a8317dd9ebcd061a8eec0340ddd4ae2-PR-1027

2 of 3 (66.67%)  changed or added relevant lines in 1 file are covered.
8 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.5%) to 65.932%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

apps/fz_http/lib/fz_http/notifications.ex
2
3
66.67%

Files with Coverage Reduction
New Missed Lines
%

apps/fz_http/lib/fz_http_web/live/notifications_live/badge.ex
1
71.43%

apps/fz_http/lib/fz_http_web/live/notifications_live/index_live.ex
2
71.43%

apps/fz_http/lib/fz_http/validators/common.ex
5
84.38%

Totals

Change from base Build dd11c728b06adf0ad500d369b754d98d92e031af:
-0.5%

Covered Lines:
1136

Relevant Lines:
1723

💛  - Coveralls


tusimple model predict on another dataset seems weired

tusimple model predict on another dataset seems weired

what missed here?

@liuruijin17 I think it maybe some coordinates issue? For semantic prediction, it at least knows where is the lane on the ground, rather than up to the sky,

@liuruijin17 Can u post a your self-collected image prediction effect using cached model?

Hi,
In fairness to the discussion about lane locating performance, I wish we had only discussed the TuSimple dataset. Because any model will probably not perform well on data that has never been seen before, which is the downside of a data-driven approach to deep learning.
The segmentation task focuses on recognizing each pixel, and a segmentation model trained on TuSimple might know the lane pixel on other datasets because there is no overall concept of lanes here, just lane pixels. However, our approach directly treats the lane as an overall object, so the current situation across different datasets is perfectly normal.
Now I share two self-collected images, you can directly test the results by the provided TuSimple trained model, and you will see one is better than the other.
We also have data on intersections, etc., but there is no point in testing it here since our approach cares about the high-level lane objects, not low-level lane pixels.

@liuruijin17  thank u! I will test tomorrow. My point is not Tusimple trained model also works on other dataset, it's it at least fit the lane shape in some sort of style instead. I have tested UltraFastLane detection model trained on CULane, it also have floating to the sky issue, but in the end I found it's a coordinates converting issue since my image WH not same as CULane's.

Hi, sorry for being late, tough days because my cat got sick.
I think I understand your point. I tried to crop your image to 511x1421 then test with the CULane pre-trained LSTR since our input is 295x820, the result is still bad. So I wonder whether the cropping processing I did is like yours (just semantically rather than in terms of specific values).
Another thing I realized that our model prefers traditional object detection, so the overall apparent clues of the lane markings are critical. For scenarios where lane markers are missing, LSTR may not predict well (test results on CULane shows that point).
The last thing is I think UltraFastLane learns from the segmentation information and focuses more on low-level features so that it is more robust on different scenes than LSTR which learns a lane as a whole object. So the trade-off is that LSTR needs more data to see and conquer, which I think there is still a cap anyway:joy_cat:. The ultimate solution may still have to rely on the fine-grained split of scenarios and tasks.

@liuruijin17 thanks for your investigation! Indeed, more data is likely the way how transformer based model performance even better.
I also tested with different resize way or cropping, no luck.
However LSTR still a promising model since it learn better on curved scenarios. BTW will u planned to come up with a second version of LSTR in the future which might add a semantic branch or something fancy way to tweaking it?

@jinfagang you are welcome! It's nice to make a little something useful.
Yes, recently I have been reading papers about 3D lane detection, like 3DLaneNet and Gen-LaneNet, to seek some ideas about how to expand the detection results of different camera poses, maybe use the hot domain adaptation topic. However, I find the dataset is the main bottleneck since the public 2D or 3D lane datasets are too general to focus on fine-grained scenarios like intersections, merges and splits, and lack annotations to specify them. Perhaps we will start with the dataset to define some novel problems, which may also solve the original issues at the same time.

@liuruijin17  Waiting for your progress!


【Core Data】How to Enable Device Data Storage Service and  read Data

version：V3.1 Napa
1.How to Enable Device Data Storage Service: or How to enable the device's data storage service
2.How Third-Party Software Reads Data from the Device's Database:

What is the Device Data Storage Service you mentioned here?
To retrieve the existing data from core-data, you can execute the REST API to get Events or Readings
https://docs.edgexfoundry.org/3.1/microservices/core/data/ApiReference/

https://docs.edgexfoundry.org/3.1/microservices/core/data/ApiReference/

是指的core data去保存传感器数据，配置使能该功能，并通过接口读取传感器数据；

You can build another service to surve your purpose.  It doesn't have to tie to core-data.
All you need to do is to subscribe the event messaging topics to receive data from Device Services, and handle the data whatever you want.

close this issue due to no activity


[BUG] 401 error when calling rest api methods when setting StorageState in BrowserContext

Context:

Playwright Version: 1.28.1
Operating System: Windows 10
.NET version: NET 6
Browser: All
Extra: Authorization via UI keycloak

Code Snippet
Help us help you! Put down a short code snippet that illustrates your bug and
that we can run and debug locally. For example:
      public async Task CreateRequestApiAsync()
        {
            var browserStorageState= await _browserContext.StorageStateAsync();

            var api = await _playwright.APIRequest.NewContextAsync(new APIRequestNewContextOptions
            {
                StorageState = browserStorageState
            });
            var response = await api.PostAsync("https://page.com/api/request",

                new() { DataObject = new Fixture().Create<RequestDto>() });
        }

Describe the bug
Good day! Our company uses keycloak as a single entry point.
I'm trying to use browser context for authorization on the backend side.
The code I provided above always returns 401 errors, although the documentation says:
Storage state is interchangeable between BrowserContext and APIRequestContext
Any ideas how to get this to work? I have a workaround to get token from localstorage
(vuex:tokenInfo:access_token)

Could you provide us a repro which we can run locally? Yes this should work out of the box see here:
using Microsoft.Playwright;

using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync(new() { Headless = false });
await using var browserContext = await browser.NewContextAsync();
var page = await browserContext.NewPageAsync();
await browserContext.AddCookiesAsync(new []
{
    new Cookie
    {
        Name = "cookie1",
        Value = "value1",
        Url = "https://postman-echo.com/headers",
        HttpOnly = false,
        Secure = true,
        SameSite = SameSiteAttribute.None,
    }
});

var storageState = await browserContext.StorageStateAsync();

Console.WriteLine("storage state: " + storageState);

var request = await playwright.APIRequest.NewContextAsync(new ()
{
    StorageState = storageState,
});
var response = await request.GetAsync("https://postman-echo.com/headers");
Console.WriteLine(await response.TextAsync());

@mxschmitt  There is definitely time for this. I can give a snapshot of storageState for now
storageState.txt
As I understand it, the problem is that the bearer token is in KEYCLOAK_IDENTITY

Looks stale and we don't have a repro so we cannot act on it. Closing as part of the triage process. Please re-file with a clear repro.


TypeError: Cannot read property 'listeningForMouseEvents' of undefined

TypeError: Cannot read property 'listeningForMouseEvents' of undefined
    at ContainerElement.update (element.js:185)
    at Web2VR.update (web2vr.js:284)
    at web2vr.js:142
update | @ | web2vr.js:287
-- | -- | --
  | (anonymous) | @ | web2vr.js:142
  | setInterval (async) |   |
  | allLoadedUpdate | @ | web2vr.js:136
  | init | @ | web2vr.js:131
  | start | @ | web2vr.js:117
  | (anonymous) | @ | ?NAFopts={"app":"vrg…pter":"easyRTC"}:57

Admittedly, I'm surely doing something wrong that's my fault, however the examples are all too complex to draw from. The very basic 'hello world' example you give, on the other hand, doesn't show an <a-scene> present, and so it is unclear how to integrate that.
This stack trace isn't helpful for me, unfortunately--I don't see listeningForMouseEvents referred to at all, which is confusing.
I'm really excited about this library and want to use it! Please help point me in the right direction. I saw that you don't have a quest to test on--I'll be getting a quest 2 soon and I'll be glad to help with that.

I just noticed that the basic demo actually produces this error message even when it works correctly, it seems, so this is likely not my problem--I just have to figure out how to get the render into my scene...?
https://deciduous-cooing-error.glitch.me/old-aframe

Just noticed that when trying to add the demo to my app, it also breaks movement-controls fromaframe-extras.  Hoping that's just my own bad attempt at implementation somehow.

If you use web2vr on aframe 1.1.0 right now everything will break. You will have to use aframe 1.0.4 for now. Working on new update that will support aframe 1.1.0.

I just want to add here that I saw github swallowed a critical thing I wrote above with misinterpreted markdown, so I'll repeat it just to make sure you see:

The very basic 'hello world' example you give, on the other hand, doesn't show an  present, and so it is unclear how to integrate that.

I would love to see an example showing how to do that a little more clearly / approachably.


Closing picker does not return focus to previous window [neovim]

Steps to Reproduce with split

Open neovim,
Split the window the horizontally :split,
Move focus to upper window, if not already there, <C-w> k,
Open vim-picker :PickerEdit,
Close vim-picker <Esc>,
Observe focus is now in bottom window instead of top window.

Steps to Reproduce with vsplit

Open neovim,
Split the window vertically :vsplit
Move focus to right window, if not already there, <C-w> l,
Open vim-picker :PickerEdit
Close vim-picker <Esc>,
Observe focus is now in left window instead of right window.

When I find some spare time, I will identify a solution and submit a PR.  I think I posed a similar issue to Shougo's unite/denite plugin and Shougo patched it within hours.  I've no idea how to manage window focus in vimscript, so I plan to start educating myself with Shougo's patch.

Thanks for the clear report @boxofrox! There's a callback to restore focus to the original window when you exit the picker with Ctrl+C, but this isn't triggered when Esc is used. I had time to look at this today, so opened https://github.com/srstevenson/vim-picker/pull/3 with a proposed fix—can you test if this works for you?

@zblz I think you mentioned this issue to me too.

@srstevenson #3 works :+1:. thanks for taking the time to patch this.

Great, merged.