Login with github as backend fails if base url contains additional path segment

[agairing]

Describe the bug If you use github as backend the following basic setup is required:

• run your own github auth server backend (see https://github.com/vencax/netlify-cms-github-oauth-provider) - https://mygithub-auth-backend.org as an example -create oauth app in github and configure callback url pointing to your github auth server backend (https://mygithub-auth-backend.org/callback)
• set base_url in config.yml according to your github auth server backend (https://mygithub-auth-backend.org) --> This works well if the base url does not contain any path segment. This does not work if you use an additional path segment in your github auth server.

Example:

• callback url -> https://mygithub-auth-backend.org/oauth2/callback
• base_url in config.yml: https://mygithub-auth-backend.org/oauth2

The authentication and token creation with github is successfull but the communication between the auth popup and the original page fails.

To Reproduce

• setup github auth backend with additional path segment
• adjust base_url in config
• try to login

Expected behavior Login should work

Applicable Versions:

• Netlify CMS version: app - 2.12.9, core: 2.24.4, cms: 2.10.45
• Git provider: Github
• OS: windows 10
• Browser version Chrome 80

Additional context It seems that the following check in netlify-auth.js is not working: e.origin !== this.base_url I think origin is always just the host without any path segment.

[erezrokah]

Thanks @agairing, looks like origin contains the schema and port too: https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#The_dispatched_event We would gladly accept a PR for it (probably we just need to parse base_url and reconstruct without the path).

[agairing]

Ok, and I can try to create a PR. What about sth. like this.base_url.indexOf(e.origin) !== 0 ?

[erezrokah]

How about e.origin !== new URL(this.base_url).origin ? It makes it clear what we're checking and is stricter.

[agairing]

Fine for me. I just did the local setup and executed the tests before changing anything. 34 tests are failing on windows. Example: Expected: ObjectContaining {"path": "static/media/abc_def_eaco_.png"} Received: {"field": undefined, "fileObj": {}, "path": "static\\media\\abc_def_eaco_.png", "url": "displayURL"}

How should this be handled? At first glance, it seems that the test is not cross platform compatible.

[erezrokah]

@agairing, thanks for letting us know. I opened an new issue for that https://github.com/netlify/netlify-cms/issues/3655 and I'm surprised our CI doesn't fail it since it we run the tests on Widows too: https://github.com/netlify/netlify-cms/runs/609296943?check_suite_focus=true#step:6:1496. I think you could just test the fix locally and submit it and I'll take care of the tests.

[peace-for-all]

I'm sorry, if wrong place to ask, but:

https://www.netlifycms.org/docs/backends-overview/#backend-configuration From my understanding of this doc, the case described in original post should be configured as

base_url: https://mygithub-auth-backend.org/oauth2
auth_endpoint: oauth2

Is this right or am I misreading the doc? Thanks. :-)

[aaron2198]

After a few days of fighting with it @walxin I think we both misread the doc as it states "OAuth client hostname (just the base domain, no path)" for base_url, like https://mygithub-auth-backend.org. Then auth_endpoint would be the full path to your specific auth destination, like oauth2. For us this was, oauth/auth, We were trying to tuck all auth endpoints behind a prefix (oauth) to play nicely with a cluttered domain and got really hung up with this. I don't suspect a PR is required to solve this issue, it was possible to manage without changing how the code works. It is even written clearly, I suppose sometimes these things are just hard to interpret.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.