Troubleshooting oauth client

[marksteele]

- Do you want to request a feature or report a bug?
Might be a bug, might be a feature

- What is the current behavior?

While implementing an OAuth auth backend for Github, I'm seeing what might be an issue either with Redux state or inter-window communication.

My code:
https://github.com/marksteele/netlify-serverless-oauth2-backend

The HTML bits are copied from the other implementations (go/python/nodejs), and the HTML output appears to succeed, however the auth window does not close and the app state doesn't update to reflect the successful auth. Might be a bug in my code...

- If the current behavior is a bug, please provide the steps to reproduce.

- What is the expected behavior?
Auth window closes, react app updates with token from auth success.

- Please mention your versions where applicable.
netflify 1.5.0

https://www.control-alt-del.org/admin/

- Please link or paste your config.yml below if applicable.
https://www.control-alt-del.org/admin/config.yml

[erquhart]

I see the CMS version being printed to the console twice, which means two separate CMS instances are being created. That may have something to do with it.

[marksteele]

I've removed the duplicate instance, same result.

[marksteele]

So fundamentally the problem is that the authenticate function in netlify-auth.js is appending '/auth' to base_url. This breaks when the you want the authentication url to be different from the site root.

In my example, my base url for authentication is https://www.control-alt-del.org/oauth/{auth|callback}

Add a configuration setting 'authentication_base' to the backend config settings, and update the comparisons in handshakeCallback and authorizeCallback to use that instead of base_url.

[bakerkretzmar]

I think I'm having this same problem but I can't work out a way around it. I have everything set up exactly, as far as I can tell, like this, other than my auth_endpoint which didn't work with /oauth included in it. I'm using Jekyll, but everything else is copied and pasted from @marksteele except for my keys and secrets.

Code here: bakerkretzmar/madihaslam
Live site here: madihaslam.ca

My Netlify config.yml:

publish_mode: editorial_workflow
backend:
  name: github
  repo: bakerkretzmar/madihaslam
  base_url: https://tva0emnu7j.execute-api.ca-central-1.amazonaws.com/prod
  # auth_endpoint: /auth
  # site_domain: madihaslam.ca
# site_id: madihaslam.ca
media_folder: "uploads"
collections: etc...

The GitHub authentication works, the app gets permission to use my account, and then the authorization popup just sits there. I can see Sending message: "github" in the console, and the URL it ends up at is https://tva0emnu7j.execute-api.ca-central-1.amazonaws.com/prod/callback?code=66df4c70b0510ba7d9d3&state=HRWVCbyrKIFD93OhGz1A598pEhGADLwm, which is the token that Netlify needs, right?

My serverless deploy is working, my parameters and KMS keys are working as far as I can tell, but the CMS itself doesn't seem to know that I've authorized it.

I hope this is the right place to post this! Thanks!

[pdrbrnd]

@bakerkretzmar did you managed to get it working?

[bakerkretzmar]

@pbrandone nope, but in the meantime they added support for GitLab so I switched to that backend with implicit grant and that's working great.

[lukeburns]

It looks like this issue is due to https://github.com/netlify/netlify-cms/blob/master/packages/netlify-cms-lib-auth/src/netlify-auth.js#L44. netlify-cms-lib-auth expects e.origin to be equal to base_url, rather than base_url's origin.

So in @bakerkretzmar's case— netlify-cms-lib-auth will fail to authorize, because e.origin is https://tva0emnu7j.execute-api.ca-central-1.amazonaws.com and base_url is https://tva0emnu7j.execute-api.ca-central-1.amazonaws.com/prod.

You can fix this by replacing the above configuration with

base_url: https://tva0emnu7j.execute-api.ca-central-1.amazonaws.com
auth_endpoint: /prod/auth

Is there a good reason netlify-cms-lib-auth doesn't simply check against the origin of base_url? Might clear up some confusion if @bakerkretzmar's config worked as expected.

[erquhart]

@lukeburns comments on #1294 provide the rationale - tl;dr: we could change it, just need to make sure nothing breaks in the process.