auth0-extensions / auth0-deploy-extensions Goto Github PK

tenant.json exported by deploy-cli tool not being used by github deploy

That is, this stuff:

I used the CLI deploy tool to output my current tenant's configuration to see if there's an obvious way to add the Auth0 API (including custom ones in the future) into my code config, but I don't see anything obvious. Here's what my output looks like:

I can't find anything in this directory tree is there anything for the APIs.

After upgrading the node runtime in Auth0 to Node 12, the azure deployment script is broken. I have tried saving the settings multiple times, and uninstalling/reinstalling.

I end up with this error:

invalid_request: Client attempting to use unregistered redirect URI: https://[tenant].us8.webtask.io/[id]

I exported our config from Auth0 using the CLI, then tried to redeploy it using the Github Deployment extension. When exporting it included guardian/factors/webauthn-roaming.json, but this was rejected by the schema as it's not present in the enum.

I see that WebAuthn is a BETA feature, but it's not ideal in terms of user experience to be unable to import something which was exported only moments beforehand. Perhaps BETA features should not be exported by default if it's not possible to import them?

Error message was:

Schema validation failed loading [
    {
        "keyword": "enum",
        "dataPath": ".guardianFactors[5].name",
        "schemaPath": "#/properties/guardianFactors/items/properties/name/enum",
        "params": {
            "allowedValues": [
                "sms",
                "push-notification",
                "otp",
                "email",
                "duo"
            ]
        },
        "message": "should be equal to one of the allowed values"
    }
]

As of about a week ago, our deployments have failed with the error Libsodium error: Error: wrong secret key for the given ciphertext. My first thought was that someone must have accidentally changed our tenant's cipher secret. When I went to check it in the extension configuration menu I noticed that the 'Cipher Secret' input field is completely gone. We are using v2.10 of the extension.

Looking through the changelog and and commit history of this repo, I see that cipher secrets are being replaced with something called 'mappings'. Since we have not updated the extension to v3.0, I believe the latest release might have accidentally broken tenants configured with v2 installations.

Guidance on fixing this would be very appreciated. We would like to keep all configurations in version control (including encrypted secrets) instead of updating them in the management dashboard.

The problem I found was that trying to use the ##MAPPING## syntax for the smtp password did not work as expected using the Bitbucket deploy extension.

Here is the example provider.json I was trying to use:

{
  "name": "smtp",
  "enabled": true,
  "default_from_address": "[email protected]",
  "credentials": {
    "smtp_host": "smtp.sendgrid.net",
    "smtp_port": 587,
    "smtp_user": "apikey",
    "smtp_pass": "##SMTP_PASSWORD##"
  }
}

The configured mappings are

{
  "SMTP_PASSWORD": "super secret password"
}

After a "successful deployment the email sending fails due to incorrect password.

I cloned the repo and added some tests.
It looks like the "applyMapping" function in utils.js (server/lib/utils.js) is not correctly handling the credentials item/key.

const applyMappings = (item, mappings) => {
  const result = {};
  Object.keys(item).forEach((key) => {
    if (Array.isArray(item[key])) {
      const value = item[key];
      result[key] = JSON.parse(keywordReplace(JSON.stringify(value), mappings));
    } else {
      //START CHANGE
      if (typeof item[key] === 'string') {
        result[key] = keywordReplace(item[key], mappings);
      } else {
        //This code gets executed and correctly processes for emailProvider credentials
        result[key] = JSON.parse(keywordReplace(JSON.stringify(item[key]), mappings));
      }
      //END CHANGE
    }
  });
  console.log('applyMappings Result: ' + JSON.stringify(result));
  return result;
};

After making the above (not so nice!) change it processes the template correctly.

As the title says:

• create a new rule via git repo, push it- > it's created in Auth0
• delete the rule in git repo, push it -> rule remains in Auth0

Tested with the Visual Studio extension using Azure DevOps.

I know you can use the .json-metafile and enable/disable rules, but I actually want the rule to be really deleted.

The Github link in extensions still leads to old, archived repo (https://github.com/auth0-extensions/auth0-github-deploy) and not this one (https://github.com/auth0-extensions/auth0-deploy-extensions).

Hi,

We've been going back and forth with support on this issue where we're seeing incomplete deployments on the Github deploy extension for over a week now, and was wondering if we could do a screen share as we can generally replicate the issue.

https://support.auth0.com/tickets/00452451

The file CHANGELOG.md does not seem to have been updated since 2.0.0. Could you please either keep it updated or remove it? It is useful for preparing an update of an extension.

we configured the github deployments extension (both the personal access token and the webhook) and it works when i click on the deploy button. after that on the deployments tab i see a success status with a green icon, the branch name (master) in the change column and my auth0 user (in auth0|id format). but after i push something to the repository (we usually merge a pull request), on the deployments page i see a failed status with a red icon, the hash of the commit and my github username.

the log says:

{
  "statusCode": 401,
  "error": "Unauthorized",
  "message": "Invalid token",
  "attributes": {
    "error": "Invalid token"
  }
}

i checked the recent deliveries under the webhook and there is a successful request to the payload url, the status code is 202 and the response is

{
  "message": "Request accepted, deployment started."
}

I have setup the deployment extension to automatically deploy from our source control on Azure Dev Ops.
Initially it worked but, when we migrated to a branch per tenant pattern, it stopped working.
The web hook fires and deployment starts, but it fails with the error:

Value cannot be null.

Parameter name: versionDescriptor

It's also worth noting that, on the table showing deployment history, the branch field is empty. I have tried removing and reinstalling the extension, but the result is the same.

Hi, when I update to 2.7 from 2.4 it looks like user logging might be broken.

This is my request i'm sending from gitlab to auth0

{
  "object_kind": "push",
  "event_name": "push",
  "before": "5841f43269bbb284c2ed60939c15dc93212d3894",
  "after": "fc361d32ba9c9df8fb2e475b9096982df26d2eac",
  "ref": "refs/heads/testing",
  "checkout_sha": "fc361d32ba9c9df8fb2e475b9096982df26d2eac",
  "message": null,
  "user_id": 40,
  "user_name": "Cody McMichael",
  "user_username": "cody.mcmichael",
  "user_email": "",
  "user_avatar": "https://secure.gravatar.com/avatar/a6bdaf5fdbc03f2872aa53310f344ec7?s=80&d=identicon",
  "project_id": 210,

I noticed my email was empty here, but in the commit...

"commits": [
    {
      "id": "4225d1243f8d0efe8719783d9d1206e431f7db79",
      "message": "builds staging\n",
      "timestamp": "2018-08-07T00:37:40Z",
      "url": "https://in.thewardro.be/io/interactive/auth0-config/commit/4225d1243f8d0efe8719783d9d1206e431f7db79",
      "author": {
        "name": "Cody McMichael",
        "email": "[email protected]"
      },
      "added": [

It exists, I realize it could be an issue on my end as well, but was wondering if maybe you switch pulling the email address from the commit to the project block and this is why it no longer pulls?

Currently we only use repositories with two-part names ( user/repo), see:

• auth0-deploy-extensions/server/lib/utils.js

  Lines 388 to 402 in d39a35a

  	/*
  	* Parse the repository.
  	*/
  	const parseRepo = (repository = '') => {
  	const parts = repository.split('/');
  	if (parts.length === 2) {
  	const [ user, repo ] = parts;
  	return { user, repo };
  	} else if (parts.length === 5) {
  	const [ , , , user, repo ] = parts;
  	return { user, repo };
  	}
  	throw new ArgumentError(`Invalid repository: ${repository}`);
  	};

  )

• auth0-deploy-extensions/server/lib/providers/gitlab.js

  Lines 362 to 382 in d39a35a

  	/*
  	* Get a project id by path.
  	*/
  	const getProjectId = () => {
  	const { user, repo } = utils.parseRepo(config('REPOSITORY'));
  	const repository = `${user}/${repo}`;
  	return getApi().Projects.all({ membership: true }).then(projects => {
  	if (!projects) {
  	return Promise.reject(new Error('Unable to determine project ID'));
  	}
  	const currentProject = projects.filter(f => f.path_with_namespace === repository);
  	if (currentProject[0] && currentProject[0].id) {
  	return currentProject[0].id;
  	}
  	return Promise.reject(new Error('Unable to determine project ID'));
  	});
  	};

GitLab, however, provides a "subgroups" feature (see https://docs.gitlab.com/ee/user/group/subgroups/#overview) which, when used, cause repository names to have more segments. E.g. a repository could be named mycompany/myteam/mysubteam/myrepo.

So, at least for GitLab, we cannot assume a two-part name for repositories.

Hi Auth0 Team,

I've been unable to deploy using the bitbucket deployment extension. The only logs I receive is "Request failed with status code 401."

I've tried redeploying to an auth0 tenant with a previously successful deployment and still failed. No changes or configurations were changed for this auth0 tenant.

Any help would be appreciated.

I might be misunderstanding something but if I want to store the tenant settings in a sub directory inside my repository I should use the BASE_DIR setting right?

My folder structure looks like this

and then in the GitHub deployments settings I set the BASE_DIR to services/auth0. But when I try deploying it fails with this error

{"message":"Not Found","documentation_url":"https://developer.github.com/v3/git/trees/#get-a-tree"}

The only other settings I've added to the config is the repo, branch and the token.

Thankful for any help!

I'd like to keep all my configuration and secrets in version control to minimize human error when updating auth0 settings.

Obviously we shouldn't store secrets in plain text. So that leaves encryption.

Something like sops or similar would be perfect. But presumably the keys should be coming from auth0. So auth0 might need to have some dashboard that says 'use these keys for this tenant'. But I'm sure there are many more ways to do this securely!

Copied from auth0-extensions/auth0-github-deploy#59

It would be nice to also deploy RBAC roles/permissions via this extension.

Can be implemented same as everything else.

I.E A roles folder - with with multiple json files:

some-role.json

{ "name": "Some Role", "description": "Some Role Description"}

or a single json array

roles.json

[
  { "name": "Some Role", "description": "Some Role Description"},
  { "name": "Another Role", "description": "Another Role Description"}
]

And something similar for permissions.

Thanks!

As per the details in auth0/auth0-deploy-cli#250 (for auth0-deploy-cli) there is no functionality to manage Anomaly Detection via Configuration-as-Code extensions.

In the Dashboard Admin there is a standalone section "Anomaly Detection" to control those settings.

In the JSON files of either the GitHub deploy or the CLI deploy extensions there is a single brute_force_protection setting that is directly in the DB connection files (not a tenant-level setting as per the Dashboard Admin > Anomaly Detection > Brute-force Protection)

Question 1) How do we control the 3 x Anomaly Detection settings via JSON config?

• Bot Detection
• Brute-force Protection
• Breached-password Detection

Question 2) How do the individual DB connection JSON brute_force_protection booleans relate to the tenant-level Dashboard Admin > Anomaly Detection > Brute-force Protection settings? There are multiple DB connections, but only a single Dashboard Admin tenant-level setting. Do these JSON settings have an effect?

Steps to reproduce.

1. Create a gitlab repository nested under a sub-group. For instance "https://gitlab.com/username/subgroupname/reponame"

2. Install the gitlab deployments extension in the auth0 GUI, with this repo

3. Go to the "deployments" tab, and click deploy

Expected behaviour

A deployment occurs

Actual behaviour

Network request returns with this error

{error: "ArgumentError", message: "Invalid repository: https://gitlab.com/username/subgroupname/reponame"}

It comes from this function which incorrectly parses the repository URL.

Splitting the subgroup repo URL gives 6 parts.

I can open an MR to fix it, and properly identify the user and repo, unless for some reason auth0 doesn't want to support anything but 1 level of nesting in gitlab repositories.

It's also worth noting that I set up a different tenant and used the exact same configuration 1 month ago, and it worked perfectly fine with no issues. So this is strange. Perhaps this bug was introduced recently.

The current implementation allows getting notifications about deployments on Slack.

More and more development teams are using Microsoft Teams(1), so it would be great if there is a possibility to get similar notifications there. The configuration could be very similar to Slack, like MS_TEAMS_INCOMING_WEBHOOK_URL.

Source:

1. https://www.businessinsider.in/tech/enterprise/news/microsoft-teams-just-hit-20-million-daily-active-users-beating-its-rival-slack-once-again/articleshow/72129973.cms

Currently I see no way to manage and deploy hooks using deploy extension. Potentially because of hooks still being in "beta"?

Hoping for comments in this thread if support for hooks is planned.

In terms of security, deploy keys are a much better option for third party integrations against GitHub repositories because they limit the scope of access in the case of a breach: https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys

They also do not allow writes by default, which is a major benefit over the current personal access token-style of GitHub auth used by this project.

I pushed changes to tenant.yaml. The hook runs but returns http 202 with the body:

{"message":"Request ignored, none of the Rules or Database Connection scripts were changed."}

The original tenant.yaml was generated by exporting with a0deploy yaml format.

Is or will this be supported?

Hi,
We started receiving notifications today that our Auth0 github integration is using deprecated Github APIs.

On February 5th, 2020 at 15:36 (UTC) your personal access token (XXXXX) using NodeJS HTTP Client was used as part of a query parameter to access an endpoint through the GitHub API:
.....snip

Please use the Authorization HTTP header instead, as using the `access_token` query parameter is deprecated.

Depending on your API usage, we'll be sending you this email reminder once every 3 days for each token and User-Agent used in API calls made on your behalf.
Just one URL that was accessed with a token and User-Agent combination will be listed in the email reminder, not all.

Visit https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters for more information.

Thanks,
The GitHub Team

Is there a roadmap and/or timeline for when this will be addressed with the Auth0 github integration? or will we need to switch over to using the deploy-cli-tool instead of this integration?

Any information would be greatly appreciated.

Using the Github extension, share content between multiple tenants.

Having a separate BASE_DIR and config.json for each tenant is one option, however, there is no way (that I know) to have shared contents over multiple directories in this way without duplicating all the files. One solution was to set environment variables within the auth0 extension's dashboard separately for each tenant, but in many cases it would be nicer to have this configuration in source control as well.

This was also requested in the forums but if I'm not mistaken has not been followed here until now https://community.auth0.com/t/parameterized-deployments-using-github-deploy-tool/29527/4.

Suggestion/feature request: assume I want to create multiple rules via github, and don't care about the order. Therefore usually I wouldn't create .json metafiles for the rules but just the .js files.

However, this does not work at the moment, because once I try to submit more than one rule without a .json file attached, I would get

{"statusCode":409,"error":"Conflict","message":"A rule with the same order already exists","errorCode":"rule_conflict"}

Would be nice if, in case no .json files are attached, the rules would just get added to the bottom of the list and the order just auto-increased.

Came across above issue when testing with the VisualStudio extension on Azure DevOps.

We have noticed a number of deprecation notices in our logs when deploying with the Github Deployment extension. A migration guide has been published by Auth0 for this - https://auth0.com/docs/product-lifecycle/deprecations-and-migrations/migrate-to-paginated-queries

Looks like these deprecation notices will become errors starting January 26th 2021.

The Auth 0 Deploy Extension only supports Bitbucket Cloud currently. Please add support for Bitbucket Server as well. We have specific project constraints that prevent us from using Bitbucket Cloud. We would like to have our workflows with Auth0 as integrated as possible, and this would provide that capability.

We are using the Gitlab extension and also added Slack Incoming Webhook for the handy Slack notifications. But noticed the message mentions "Bitbucket" instead of "Gitlab".

Seems like when your different deployment extension repos were consolidated, might have missed this minor detail.

Hi,

I'm migrating to using the GitHub Deployment Extension and one piece that's missing is the ability to configure branding.

I would assume an implementation may look like this:

/branding/settings.json

{
  "colors": {
    "primary": "#ffffff"
  },
  "logo_url": "http://blahblahblah"
}

as this is part of the Management API I assume it wouldn't be too difficult to add to the extension?

An alternative, more all-encompassing, way to solve this and any other missing pieces for SCM deployments may be to have a file in the git root to declare arbitrary Management API calls to happen whenever a deployment event runs? If there's already a way to do this, that would allow me to set branding values via git too.

Cheers,
Daniel

Hi,
Seems like the integration with Azure Devops is not really working.
Bottom line - configuration will not affect the basic error of accessing the prop "value" on undefined..
This fails in the Azure Devops API node lib..

Before I try and debug deeper on this - is this even supposed to work?

Given each Auth0 tenant has a System API called 'Auth0 Management API', I was wondering if there is a generic way to get this API's audience.

I'm trying to create a repository which has the develop branch deployed to one Auth0 tenant and master to another, but if I specify the develop tenant's Auth0 Management API identifier in the grants/myorg.json file then the deployment fails in the other environment because the API is not found.

For example:

//myorg.json
{
  "client_id": "My Machine to Machine client",
    "audience": "https://{develop-myorg|myorg}.eu.auth0.com/api/v2/",
    "scope": [
      "read:users"
    ]
}

I'd like to use exactly the same Auth0 configuration in both environments so I can catch any configuration errors before they hit production.

We're using the Auth0 BitBucket Extension to deploy custom pages and rules; however, with version 3.5 of the extension whenever we do a deploy, we get a "success" result, but the rules and pages aren't created/updated and there are no "created", "updated", or "deleted" records in the logs for our rules and pages. We are able to successfully deploy with version 3.4 of the extension, so it appears that something has been broken (or there is additional Auth0 configuration required?) with version 3.5.

The expectation is to see something like this in the logs (example from v3.4 deploy):

{
 "rules": {
  "deleted": 0,
  "created": 0,
  "updated": 3
 },
 "pages": {
  "deleted": 0,
  "created": 0,
  "updated": 2
 }
}

But we get this (with deploy from v3.5 using the same BitBucket repository):

{}

This is sort of a chicken-and-egg problem, but it's a bit odd that we have to manually configure and update extensions when almost everything else can be placed into version control. So perhaps the scope could be all extensions except the CLI/deploy extensions themselves?

Eg: I plan to add extensions for real time logs, Sumologic log exports, and delegated admin to my tenants.

This is very similar to auth0-extensions/auth0-source-control-extension-tools#58

I'm trying to configure my database connection (eg. disable signups) with the Github deploy extension.

Based on the readme in this repo, this extension supports something called settings.json in the database-connections folder.

However, there's no further documentation on what this file is and its expected schema.

So I tried the format mentioned in the above issue and the deploys are not honoring the settings.

What am I missing?