Problems logging into CMS - endless loop - using github auth, gatsby

Hi @uberannie,

Would you mind sharing a few more details on your setup and login process?

  1. Your config.yml, specifically the backend section?
  2. Browser console logs during the login process?
  3. Is this a private or public repo? If public can you share a link to it?
  4. Is Netlify Identity configured with invite only or open invites?

Many thanks :slight_smile:

Hi Erez :wave:

backend:
  name: git-gateway
  commit_messages:
    create: "Create {{collection}} “{{slug}}”"
    update: "Update {{collection}} “{{slug}}”"
    delete: "Delete {{collection}} “{{slug}}”"
    uploadMedia: "[skip ci] Upload “{{path}}”"
    deleteMedia: "[skip ci] Delete “{{path}}”"

VM128 netlify-cms-app.js:127 netlify-cms-app 2.11.27
VM131 cms.js:1 CMS_MANUAL_INIT flag set, skipping automatic initialization.’
VM128 netlify-cms-app.js:52 netlify-cms-core 2.21.0
VM128 netlify-cms-app.js:28 TypeError: Failed to fetch
(anonymous) @ VM128 netlify-cms-app.js:28
Promise.catch (async)
(anonymous) @ VM128 netlify-cms-app.js:28
(anonymous) @ VM128 netlify-cms-app.js:60
(anonymous) @ VM128 netlify-cms-app.js:28
handleLogin @ VM128 netlify-cms-app.js:87
componentDidMount @ VM128 netlify-cms-app.js:52
Pj @ VM127 react-dom.production.min.js:158
unstable_runWithPriority @ VM126 react.production.min.js:25
pb @ VM127 react-dom.production.min.js:59
Ma @ VM127 react-dom.production.min.js:151
We @ VM127 react-dom.production.min.js:132
(anonymous) @ VM127 react-dom.production.min.js:60
unstable_runWithPriority @ VM126 react.production.min.js:25
pb @ VM127 react-dom.production.min.js:59
Rg @ VM127 react-dom.production.min.js:60
ca @ VM127 react-dom.production.min.js:60
Ja @ VM127 react-dom.production.min.js:227
enqueueSetState @ VM127 react-dom.production.min.js:217
m.setState @ VM126 react.production.min.js:21
l.onStateChange @ VM128 netlify-cms-app.js:28
notify @ VM128 netlify-cms-app.js:28
t.notifyNestedSubs @ VM128 netlify-cms-app.js:28
l.onStateChange @ VM128 netlify-cms-app.js:28
g @ VM128 netlify-cms-app.js:28
(anonymous) @ VM128 netlify-cms-app.js:40
(anonymous) @ VM128 netlify-cms-app.js:60
dispatch @ VM128 netlify-cms-app.js:28
(anonymous) @ VM128 netlify-cms-app.js:28
(anonymous) @ VM128 netlify-cms-app.js:60
dispatch @ VM128 netlify-cms-app.js:28
(anonymous) @ VM128 netlify-cms-app.js:28
async function (async)
(anonymous) @ VM128 netlify-cms-app.js:28
(anonymous) @ VM128 netlify-cms-app.js:60
(anonymous) @ VM128 netlify-cms-app.js:28
componentDidMount @ VM128 netlify-cms-app.js:87
Pj @ VM127 react-dom.production.min.js:158
unstable_runWithPriority @ VM126 react.production.min.js:25
pb @ VM127 react-dom.production.min.js:59
Ma @ VM127 react-dom.production.min.js:151
We @ VM127 react-dom.production.min.js:132
Ja @ VM127 react-dom.production.min.js:227
sd @ VM127 react-dom.production.min.js:172
(anonymous) @ VM127 react-dom.production.min.js:174
Yh @ VM127 react-dom.production.min.js:132
td @ VM127 react-dom.production.min.js:174
render @ VM127 react-dom.production.min.js:239
_ @ VM128 netlify-cms-app.js:52
(anonymous) @ VM131 cms.js:1848
n @ VM131 cms.js:1
(anonymous) @ VM131 cms.js:1
n @ VM131 cms.js:1
(anonymous) @ VM131 cms.js:1
(anonymous) @ VM131 cms.js:1
VM143 netlify-cms-app.js:127 netlify-cms-app 2.11.27
VM146 cms.js:1 CMS_MANUAL_INIT flag set, skipping automatic initialization.’
VM143 netlify-cms-app.js:52 netlify-cms-core 2.21.0

  1. private repo

  2. Configured with Open Invites

That’s great @uberannie, the Failed to fetch error log gives us a way forward.

I would try disabling/enabling git-gateway from the Netlify site to make sure it is not a permissions issue.
The next step would be to try and find the request that is failing from the browser network tab.
You might find it useful to check the preserve log option when doing so (screen shot from Chrome):

.

cool, let me try the disable / enable option. In the interim, it looks to be the .netlify/identity/settings and .netlify/identity/user requests that are failing :frowning:

Hmm, any error messages for those requests? Do they have responses or fail completly?

can confirm disabling and enabling git-gateway did not yield any different results

  • endless loop whilst disabled
  • endless loop whilst enabled

No response data :sob:

They are listed as canceled if that helps?

Note there are a couple of team members who have no problems. They are also using chrome. So I’m wondering if there is anything local storage or cached to be considered?

Hi @uberannie, clearing the cache can help reduce the scope and would be helpful.
Does the browser reports any CORS errors or any other error on why the request is canceled?

Ok I did a couple of things which resolved it, could these inform what is going on?

  • cleared local storage
  • instead of using our prod URL/admin, I used the netlify URL/admin
  • CMS loaded as expected

(interestingly, after it loaded successfully using netlify URL/admin, using prod URL/admin also works :exploding_head: But going prod URL/admin first resulted in endless loop…

Question - should both /admin URLs work or should we only use the Netlify generated URL ?

1 Like

could not see anything re CORS problems. On the failed fetch on settings and user Referrer Policy was listed as same-origin, if that is significant?

Both URLs should work.
Do you have any warnings in the custom domain management section in Netlify?
I’m assuming curl -i "https://prod domain/.netlify/identity/settings" fails and curl -i "https://netlify domain/.netlify/identity/settings" succeeds?

Hi Erez, there’s only a warning regarding an apex domain.

Not sure if related but should the CMS work on branch deploys? ie [branch url]/admin ? I’m getting the following error - but everything seems ok so far re our prod site…

The CMS should work on branch deploys, that might be another issue (again we would need to look at the traffic to figure this out).
Please note that unless you configure the CMS to connect to a specific branch it will always connect to the default branch.
Meaning branch deploys and prod will connect to the default branch.
You can dynamically update your config.yml during build time to get the CMS to connect to the specific deploy branch.

backend:
  name: git-gateway
  branch: master

Netlify supplies a HEAD env variable you can use for that purpose.

:+1:
OK so I think our prod “endless loop” issue might be OK I’ll have to check in with the rest of the team - I can’t replicate now so I’ll get them to clear cookies/local storage etc to see if that resolves their issue as it seems to have fixed it on my machine, for our prod site :crossed_fingers:

Still seeing endless loop issue on our branch deploy, clearing cookies etc doesn’t seem to resolve :frowning: I wasn’t involved in the setup so might have to do a bit of digging on how it was setup.

The curl returns a json payload which I imagine is OK

OK running in FF still having endless loop however console output looks slightly different, is this of value?

Yes, there should be a request to retrieve the config.yml file. You should verify the response has the expected content of your config file.

In the initial log there was this line:

VM131 cms.js:1 CMS_MANUAL_INIT flag set, skipping automatic initialization.’

So there won’t be a request for config.yml

even with manual initialisation it tries to load the config file and merges it with the manual config unless you pass in load_config_file: false.

See the code comments here: https://www.netlifycms.org/docs/beta-features/#manual-initialization

Infinite loops are very common problem in OAuth authorizations

hey guys, sorry been a bit quiet as we’re busy busy working through some deadlines to release the next version of our public website :dizzy:

so we’re still having it intermittently and randomly amongst team members - some no issues, some every now and then.

was chatting with one of our engineers, is there anything in the codebase that has some dependencies between calls, as a race condition? the theory that one call is waiting for another but timing is messing things up. One suggestion was to apply a “slow 3G” network mode in Chrome. This has actually “fixed” the issue so wondering if the forced slower connection helps manage the orchestration of calls?

Our team are all based in Melbourne, Australia

this is heartening… :flushed: any tips for how they can be addressed?