auth0-extensions/auth0-github-deploy

This extension gives Auth0 customers the possibility to deploy Rules and Custom Database Connections from GitHub.

auth0-github-deploy's Issues

Deploys should not implement any missing custom database scripts

Auth0 will always execute the get_user script if implemented, where "implemented" is defined as "get_user property exists on the database connection object". This can cause issues for scenarios where it's not expected to have these scripts implemented, e.g. when "import users" is disabled.

The extension should not set defaults for any database scripts that are not implemented. It should not set them in the connection object at all.

Connection update not working

When specifying a connection (connections folder) it only works when the connection does not exist yet. Once it has been created, redeploying will fail. Meaning there is no proper check in place to verify if connection exists - thus updating it.

The error returned:
APIError: {"statusCode":409,"error":"Conflict","message":"A connection with the same name already exists","errorCode":"connection_conflict"}

This is a very important thing as deploying a client will disable it under the connection and we would like to specify the enabled_clients to prevent breaking our Auth0 with just a re-deploy.

Provide a means to deploy encrypted secrets for rules and DB scripts

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.

For my tenant, manual deploy works from the button but it does not deploy automatically on merge to master.

I followed the steps from https://auth0.com/docs/extensions/github-deploy
and got my deploy working manually. But it does not do it automatically. Do anyone know what can be the issue?

Add option to wait for CI to pass before deploying

Similar to how Heroku does it.

I note an alternative workflow to this would be to use auth0-deploy-cli on the CI server rather than this extension, which I will look into.

Thanks for the awesome work btw.

Unable to clear the manual flag from all rules

Steps to reproduce:

1. Select one or more rules as manual and click the update button.
2. Deselect all the previously selected rules and click the update button.

Expected:
None of the rules would be marked as manual.

Actual:
If you refresh, the rules will still be flagged as manual because when you try to clear the manual flag from all rules at once the update button does not trigger any update on the back-end.

As additional information, this problem will likely affect all other deploy related extensions as they use the same logic for this screen, more specifically, the problem seems to be caused by:

https://github.com/auth0-extensions/auth0-github-deploy/blob/master/client/components/RulesTable.jsx#L40

Does not support change_email script

The only way to change the email of a user in a custom database connection is by implementing the change_email script, which currently can only be done through the Auth0 Management API. See here: https://community.auth0.com/t/change-a-user-email-when-using-custom-database/9567

It would be great if this could be done via this extension.

Silent failure if a rule is created with a bad rulename

Steps to replicate:
0) Enable realtime webtask logs

1. Enable github extensions
2. Create repo with rules/console_log.js and rules/console_log.json in them
3. push repo
4. Github extensions page will say successful deployment
5. realtime webtask logs show failure

Expected:
4) should be a failed deployment

Security: deploy keys

Currently the extension accesses Github using a Personal Access Token with repo level control. This means the extension can act on all public and private repositories the user has access to, with full control, and in the name of the user.

This is a security problem; the extension should have as little permission as possible to do what it needs to (read a single repository), and breaks non-repudiation, as it acts on the behalf of an individual.

This can be mitigated by creating another Github user, which only has read access to the appropriate repository, but this involves a paid Github seat and an email address to manage.

Can the extension be changed to use Github's Deploy Key concept, which is designed for this exact scenario: a repo-scoped, read-only token?

Add Email Template Support

This has been a great addition for managing scripts for connections and rules. It would be great to see something added for Email Templates as well.

Error with uglify and ES6 syntax

It seems there is an issue with express-conditional-middleware causing issues with uglify. It appears the express-conditionals-middleware uses ES6 syntax that is causing issues during npm run build.

I believe this code is the culprit:

// node_modules/express-conditional-middleware/lib/condition.js
module.exports = (condition, success, fail) => (req, res, next) => {
  const nextOnce = once(next);
  if (condition === true || (typeof condition === 'function' && condition(req, res, nextOnce))) {
    return success(req, res, nextOnce);
  }
  if (fail) {
    return fail(req, res, nextOnce);
  }

  return nextOnce();
};

if this is changed to functions instead of () => everything seems to play nice with building.

Please keep changelog up to date

The version available in auth0 is now 2.6, but there is no release, no tag, and no changelog for 2.6.

Github access token stored in plain text

The GitHub access token is available in plain text within this plugin (open up settings and inspect the access token field in the browser and the token is plainly visible).

This is of course a huge security issue since any compromise of Auth0 would mean that the attacker has full access to the entered access token (which as of now has full repo rights).

I suggest this plugin either:

1. Encrypts the GitHub access token
2. Somehow restricts the needed access rights to not have full repo accessibility

Prevent deploying secrets to version control

What If I am using a clientSecret within my rules and want to prevent it from being deployed to version control?

Error when switching the order of execution of rules

When trying to update the order of execution of rules validation fails if a previous version of a rule used the same order of a different rule in the new deployment.

An example of the change can be seen here with the deployment failing

2016-06-28T23:45:55.282Z - Updating rules...
2016-06-28T23:45:56.424Z - Existing rules: [
  {
    "id": "rul_TwHwyUjWKAGf6Cug",
    "name": "set-country",
    "stage": "login_success",
    "order": 1
  },
  {
    "id": "rul_WSRAraMQOsTbNWbl",
    "name": "log-to-console",
    "stage": "login_success",
    "order": 2
  },
  {
    "id": "rul_3lbUoWicsc07nUx0",
    "name": "require-complex-password",
    "stage": "user_registration",
    "order": 1
  }
]
2016-06-28T23:45:56.425Z - Processing rule 'log-to-console'
2016-06-28T23:45:56.425Z - Updating rule log-to-console (rul_WSRAraMQOsTbNWbl): {
  "enabled": true,
  "order": 1,
  "script": "function (user, context, callback) {\n  console.log(JSON.stringify({ user: user, context: context }, null, 2));\n  callback(null, user, context);\n}\n"
}
2016-06-28T23:45:56.426Z - Processing rule 'require-complex-password'
2016-06-28T23:45:56.426Z - Updating rule require-complex-password (rul_3lbUoWicsc07nUx0): {
  "enabled": false,
  "script": "function (ctx, cb) {\n\tif (!ctx.user.password || ctx.user.password.length < 8) {\n\t\treturn cb(new UnauthorizedError('Password does not match the password policy.'));\n\t};\n\n\tcb(null, ctx);\n}\n"
}
2016-06-28T23:45:56.428Z - Processing rule 'set-country'
2016-06-28T23:45:56.428Z - Updating rule set-country (rul_TwHwyUjWKAGf6Cug): {
  "enabled": false,
  "order": 2,
  "script": "function (user, context, callback) {\n\tif (context.request.geoip) {\n\t\tuser.country = context.request.geoip.country_name;\n\t}\n\tcallback(null, user, context);\n}\n"
}
2016-06-28T23:45:57.372Z - Error: A rule with the same order already exists

This error comes from the management API and because rules are updated one at a time with previous rules still being active.

The simple thign to do is delete all existing rules before creating the ones present in the repo since trying to solve order before updating the rules may be too complicated.

What do you think @sandrinodimattia?

Support hooks (client credentials exchange, and others)

Login failed. State mismatch

I am using auth0 enterprise and installed this extension. I configured github details and then authenticated myself on the extension. But then I don't see extension dashboard, I see this error

{"error":"ValidationError","message":"Login failed. State mismatch."}