Octomerger · Sep 3, 2022 · Sep 3, 2022
diff --git a/...ing-your-personal-account-on-github/managing-personal-account-settings/index.md b/...ing-your-personal-account-on-github/managing-personal-account-settings/index.md
@@ -25,6 +25,7 @@ children:
   - /managing-the-default-branch-name-for-your-repositories
   - /managing-security-and-analysis-settings-for-your-personal-account
   - /managing-access-to-your-personal-accounts-project-boards
+  - /managing-your-cookie-preferences-for-githubs-enterprise-marketing-pages
   - /integrating-jira-with-your-personal-projects
   - /what-does-the-available-for-hire-checkbox-do
 shortTitle: Configurações de conta pessoal

diff --git a/...ings/managing-your-cookie-preferences-for-githubs-enterprise-marketing-pages.md b/...ings/managing-your-cookie-preferences-for-githubs-enterprise-marketing-pages.md
@@ -0,0 +1,33 @@
+---
+title: Gerenciando suas preferências de cookies para páginas de marketing corporativo do GitHub
+intro: 'Você pode controlar como {% data variables.product.company_short %} usa informações de cookies de rastreamento não essenciais para páginas de marketing empresarial.'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghae: '*'
+  ghec: '*'
+topics:
+  - Accounts
+shortTitle: Gerenciar preferências de cookie
+---
+
+## Sobre preferências de cookies nas páginas de marketing corporativo
+
+{% data variables.product.company_short %} pode usar cookies não essenciais em algumas páginas de marketing corporativo. Você pode personalizar como esses cookies se comportam. Para obter mais informações sobre como {% data variables.product.company_short %} usa os cookies, consulte "[ Declaração de privacidade de {% data variables.product.company_short %} ](/free-pro-team@latest/site-policy/privacy-policies/github-privacy-statement)".
+
+## Alterando suas preferências de cookies
+
+Você pode personalizar como cookies não essenciais se comportam em qualquer página de marketing corporativo de {% data variables.product.company_short %}.
+
+1. Acesse a página de marketing corporativo de {% data variables.product.company_short %} onde você gostaria de mudar suas preferências de cookie. Por exemplo, acesse [Recursos de {% data variables.product.company_short %}](https://resources.github.com/).
+1. Role até o final da página e, em seguida, clique em **Gerenciar Cookies**.
+
+   ![Captura de tela do botão para gerenciar as configurações de cookie.](/assets/images/help/settings/cookie-settings-manage.png)
+
+1. Em "Gerenciar preferências de cookies" para aceitar ou rejeitar cada cookie não essencial, clique em **Aceitar** ou **Rejeitar**.
+
+   ![Captura de tela dos botões de opção para escolher "Aceitar" ou "Rejeitar" para cookies não essenciais.](/assets/images/help/settings/cookie-settings-accept-or-reject.png)
+
+1. Clique em **Save changes** (Salvar alterações).
+
+   ![Captura de tela do botão para salvar as alterações.](/assets/images/help/settings/cookie-settings-save.png)
diff --git a/...rity-hardening-your-deployments/about-security-hardening-with-openid-connect.md b/...rity-hardening-your-deployments/about-security-hardening-with-openid-connect.md
@@ -147,11 +147,11 @@ Com o OIDC, um fluxo de trabalho de {% data variables.product.prodname_actions %
 
 As reivindicações de Audiência e Assunto são normalmente usadas em combinação, ao definir as condições da função/recursos em nuvem para definir o escopo do seu acesso aos fluxos de trabalho do GitHub.
 - **Audiência**: Por padrão, esse valor usa a URL do proprietário da organização ou do repositório. Isto pode ser usado para definir uma condição para que apenas os fluxos de trabalho na organização específica possam acessar a função da nuvem.
-- **Subject**: By default, has a predefined format and is a concatenation of some of the key metadata about the workflow, such as the {% data variables.product.prodname_dotcom %} organization, repository, branch, or associated [`job`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idenvironment) environment. Consulte "[Exemplo de assunto reivindica](#example-subject-claims)" para ver como a reivindicação de assunto é montada a partir de metadados concatenados.
+- **Assunto**: Por padrão, tem um formato predefinido e é uma concatenação de alguns dos metadados da chave sobre o fluxo de trabalho como, por exemplo, a organização, repositório, branch de {% data variables.product.prodname_dotcom %} ou [`trabalho`](/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idenvironment) associado. Consulte "[Exemplo de assunto reivindica](#example-subject-claims)" para ver como a reivindicação de assunto é montada a partir de metadados concatenados.
 
-If you need more granular trust conditions, you can customize the issuer (`iss`) and subject (`sub`) claims that are included with the JWT. For more information, see "[Customizing the token claims](#customizing-the-token-claims)".
+Se você precisa de mais condições de confiança granulares, você pode personalizar o emissor (`iss`) e as reivindicações do assunto (`sub`) que estão incluídas no JWT. Para obter mais informações, consulte "[Personalizando as reivindicações do token](#customizing-the-token-claims)".
 
-There are also many additional claims supported in the OIDC token that can be used for setting these conditions. Além disso, seu provedor de nuvem poderia permitir que você atribuísse uma função aos tokens de acesso, permitindo que você especifique ainda mais permissões granulares.
+Há também muitas reivindicações adicionais compatíveis com o token do OIDC que podem ser usadas para definir essas condições. Além disso, seu provedor de nuvem poderia permitir que você atribuísse uma função aos tokens de acesso, permitindo que você especifique ainda mais permissões granulares.
 
 {% note %}
 
@@ -245,13 +245,13 @@ curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOK
 {% ifversion actions-oidc-hardening-config %}
 ## Personalizando as reivindicações de token
 
-Você pode garantir a segurança da sua configuração do OIDC personalizando as reivindicações incluídas com a JWT. These customisations allow you to define more granular trust conditions on your cloud roles when allowing your workflows to access resources hosted in the cloud:
+Você pode garantir a segurança da sua configuração do OIDC personalizando as reivindicações incluídas com a JWT. Essas personalizações permitem que você defina mais condições de confiança granulares nas suas funções de nuvem ao permitir que seus fluxos de trabalho acessem os recursos hospedados na nuvem:
 
-{% ifversion ghec %} - For an additional layer of security, you can append the `issuer` url with your enterprise slug. This lets you set conditions on the issuer (`iss`) claim, configuring it to only accept JWT tokens from a unique `issuer` URL that must include your enterprise slug.{% endif %}
-- You can standardize your OIDC configuration by setting conditions on the subject (`sub`) claim that require JWT tokens to originate from a specific repository, reusable workflow, or other source.
-- You can define granular OIDC policies by using additional OIDC token claims, such as `repository_id` and `repo_visibility`. Para obter mais informações, consulte "[Compreendendo o token do OIDC](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token)".
+{% ifversion ghec %} - Para uma camada adicional de segurança, é possível acrescentar a url do `emissor` ao slug da sua empresa. Isso permite que você defina condições na reivindicação do emissor (`iss`), configurando-o para aceitar apenas tokens JWT de uma URL única de `emissor` que deve incluir o slug corporativo.{% endif %}
+- Você pode padronizar sua configuração do OIDC definindo condições na reivindicação do assunto (`sub`) que exigem que os tokens do JWT se originem a partir de um repositório específico, fluxo de trabalho reutilizável ou outra fonte.
+- Você pode definir políticas granulares do OIDC usando reivindicações adicionais de token do OIDC, como `repository_id` e `repo_visibility`. Para obter mais informações, consulte "[Compreendendo o token do OIDC](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token)".
 
-To customize these claim formats, organization and repository admins can use the REST API endpoints described in the following sections.
+Para personalizar estes formatos de reivindicação, os administradores da organização e do repositório podem usar os pontos de extremidade da API REST descritos nas seguintes seções.
 
 {% ifversion ghec %}
 
@@ -286,21 +286,21 @@ Depois que esta configuração for aplicada, o JWT conterá o valor atualizado d
 
 Para configurar a segurança, conformidade e padronização em toda a organização, você pode personalizar as reivindicações padrão que atendem às suas condições de acesso necessárias. Se seu provedor de nuvem é compatível com condições para reivindicações de objetos, você pode criar uma condição que verifica se o valor `sub` corresponde ao caminho do fluxo de trabalho reutilizável, como `"job_workflow_ref: "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main""`. O formato exato irá variar dependendo da configuração do OIDC do seu provedor de nuvem. Para configurar a condição de correspondência em {% data variables.product.prodname_dotcom %}, você pode usar a API REST para exigir que a reivindicação do `sub` deva sempre incluir uma reivindicação personalizada, como `job_workflow_ref`. Para obter mais informações, consulte "[Definir o modelo de personalização para uma reivindicação de assunto do OIDC para uma organização](/rest/actions/oidc#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization)".
 
-Customizing the claims results in a new format for the entire `sub` claim, which replaces the default predefined `sub` format in the token described in "[Example subject claims](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims)."
+A personalização das reivindicações resulta em um novo formato para toda a reivindicação `sub`, que substitui o formato padrão `sub` no token descrito em "[Exemplo de reivindicações de assunto](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims)".
 
 Os modelos de exemplo a seguir demonstram várias maneiras de personalizar a reivindicação de assunto. Para configurar estas configurações em {% data variables.product.prodname_dotcom %}, os administradores da organização usam a API REST para especificar uma lista de reclamações que devem ser incluídas no assunto (`sub`) da reclamação. {% data reusables.actions.use-request-body-api %}
 
-To customize your subject claims, you should first create a matching condition in your cloud provider's OIDC configuration, before customizing the configuration using the REST API. Uma vez que a configuração estiver concluída, cada vez que um novo trabalho for executado, o token do OIDC gerado durante aquele trabalho seguirá o novo modelo de personalização. Se a condição de correspondência não existir na configuração do OIDC do provedor de nuvem antes de o trabalho ser executado, o token gerado poderá não ser aceito pelo provedor da nuvem, já que as condições da nuvem podem não ser sincronizadas.
+Para personalizar suas reivindicações de assunto, você deve primeiro criar uma condição de correspondência na configuração do OIDC do seu provedor de nuvem, antes de personalizar a configuração usando a API REST. Uma vez que a configuração estiver concluída, cada vez que um novo trabalho for executado, o token do OIDC gerado durante aquele trabalho seguirá o novo modelo de personalização. Se a condição de correspondência não existir na configuração do OIDC do provedor de nuvem antes de o trabalho ser executado, o token gerado poderá não ser aceito pelo provedor da nuvem, já que as condições da nuvem podem não ser sincronizadas.
 
 {% note %}
 
-**Observação**: Quando o modelo de organização é aplicado, ele não afetará nenhum repositório existente que já usa o OIDC. For existing repositories, as well as any new repositories that are created after the template has been applied, the repository owner will need to opt-in to receive this configuration. Para obter mais informações, consulte "[Definir o sinalizador da opção de participação da personalização da reivindicação de assunto do OIDC para um repositório](/rest/actions/oidc#set-the-opt-in-flag-of-an-oidc-subject-claim-customization-for-a-repository)".
+**Observação**: Quando o modelo de organização é aplicado, ele não afetará nenhum repositório existente que já usa o OIDC. Para os repositórios existentes e para os novos criados depois que o modelo for aplicado, o proprietário do repositório deverá optar por receber esta configuração. Para obter mais informações, consulte "[Definir o sinalizador da opção de participação da personalização da reivindicação de assunto do OIDC para um repositório](/rest/actions/oidc#set-the-opt-in-flag-of-an-oidc-subject-claim-customization-for-a-repository)".
 
 {% endnote %}
 
 #### Exemplo: Permitir o repositório com base na visibilidade e no proprietário
 
-This example template allows the `sub` claim to have a new format, using `repository_owner` and `repository_visibility`:
+Este modelo de exemplo permite que a reivnidicação do `sub` tenha um novo formato, usando `repository_owner` e `repository_visibility`:
 
 ```json
 {
@@ -311,11 +311,11 @@ This example template allows the `sub` claim to have a new format, using `reposi
 }
 ```
 
-Na configuração OIDC do seu provedor de nuvem, configure a condição `sub` para exigir que as reivindicações inculam valores específicos para `repository_owner` e `repository_visibility`. Por exemplo: `"repository_owner: "monalisa":repository_visibility:private"`. The approach lets you restrict cloud role access to only private repositories within an organization or enterprise.
+Na configuração OIDC do seu provedor de nuvem, configure a condição `sub` para exigir que as reivindicações inculam valores específicos para `repository_owner` e `repository_visibility`. Por exemplo: `"repository_owner: "monalisa":repository_visibility:private"`. A abordagem permite restringir o acesso a funções na nuvem apenas a repositórios privados de uma organização ou empresa.
 
 #### Exemplo: Permitir acesso a todos os repositórios com um proprietário específico
 
-This example template enables the `sub` claim to have a new format with only the value of `repository_owner`. {% data reusables.actions.use-request-body-api %}
+Este modelo de exemplo permite que a reivindicação do `sub` tenha um novo formato com apenas o valor de `repository_owner`. {% data reusables.actions.use-request-body-api %}
 
 ```json
 {
@@ -330,7 +330,7 @@ Na configuração OIDC do seu provedor de nuvem, configure a condição `sub` pa
 
 #### Exemplo: Exigindo um fluxo de trabalho reutilizável
 
-This example template allows the `sub` claim to have a new format that contains the value of the `job_workflow_ref` claim. This enables an enterprise to use [reusable workflows](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims) to enforce consistent deployments across its organizations and repositories.
+Este modelo de exemplo permite que a reivindicação do `sub` tenha um novo formato que contenha o valor da reivindicação `job_workflow_ref`. Isso permite que uma empresa use [fluxos de trabalho reutilizáveis](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims) para aplicar implantações consistentes em suas organizações e repositórios.
 
 {% data reusables.actions.use-request-body-api %}
 
@@ -346,9 +346,9 @@ Na configuração OIDC do seu provedor de nuvem, configure a condição `sub` pa
 
 #### Exemplo: Exigindo um fluxo de trabalho reutilizável e outras reivindicações
 
-The following example template combines the requirement of a specific reusable workflow with additional claims. {% data reusables.actions.use-request-body-api %}
+O modelo de exemplo a seguir combina a exigência de um fluxo de trabalho reutilizável específico com reivindicações adicionais. {% data reusables.actions.use-request-body-api %}
 
-This example also demonstrates how to use `"context"` to define your conditions. This is the part that follows the repository in the [default `sub` format](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims). For example, when the job references an environment, the context contains: `environment:<environmentName>`.
+Este exemplo também demonstra como usar `"contexto"` para definir suas condições. Essa é a parte que segue o repositório no formato [padrão `sub` padrão](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims). Por exemplo, quando o trabalho faz referência a um ambiente, o contexto contém: ambiente `:<environmentName>`.
 
 ```json
 {
@@ -362,7 +362,7 @@ This example also demonstrates how to use `"context"` to define your conditions.
 
 Na configuração OIDC do seu provedor de nuvem, configure a condição `sub` para exigir que as reivindicações inculam valores específicos para `repo`, `context` e `job_workflow_ref`.
 
-This customization template requires that the `sub` uses the following format: `repo:<orgName/repoName>:environment:<environmentName>:job_workflow_ref:<reusableWorkflowPath>`. For example: `"sub": "repo:octo-org/octo-repo:environment:prod:job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"`
+Este modelo de personalização exigue que o `sub` use o seguinte formato: `repo:<orgName/repoName>:environment:<environmentName>:job_workflow_ref:<reusableWorkflowPath>`. Por exemplo: `"sub": "repo:octo-org/octo-repo:environment:prod:job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"`
 
 #### Exemplo: Conceder acesso a um repositório específico