Github may have broken the way Make’s previous authorization flows worked when they introduced the new “fine-grained tokens” currently in beta. The result of this is what were originally just referred to as "“tokens” are now “classic tokens”.
If this is the case, Make needs to update the authorization flow to point to the proper location.
We all know that Rebranding is sucks It takes a crazy amount of time out of your schedule already.
Since so many automations have been frozen due to the leak of GitHub integration, could you please make this prior to anything else if it is possible within your flow?
@here Heya everyone and welcome to those of you who have just joined the community
I just wanted to jump in here to say thank you for bringing this up. I asked around and it turns out that our devs are aware of the issue and working on fixing it. Hopefully, all will be up and running as soon as possible.
I know that this is frustrating and I’m really sorry for the headache this is causing you. I’ll keep an eye on this and make sure to post an update here once I learn any news related to this issue.
Thanks for your understanding and for bearing with us
@UncleTallest Unless you’ve registered your own oAuth2 application within Github (correctly) you should not fill in any client_id or secret.
Make will take care of this, you only have to authorize it (without advanced settings).
Thanks for letting me know that this issue still prevails, @UncleTallest
I’m really sorry for having raised your hopes too early. Turns out that there are still some bits that need to be dealt with. Sorry again and I swear the next time I’m announcing this as fixed, it’ll be for real.
Thank you for bearing with us, I really appreciate your patience.
One possible solution could be to register a new oAuth2 application within GitHub and correctly authorize it without using advanced settings. Alternatively, the issue may be caused by a problem with the client ID or secret being used, in which case verifying and correcting these details could resolve the issue.
Hey folks, just wanted to give you a quick update on this. Our devs have identified and fixed the issue and are now testing everything to make sure that all works the way it’s supposed to before deploying the fixes to production. As soon as that happens, I’ll make sure to let you all know here.
Sorry that this is taking time and thanks so much for your patience on this one
Thanks a lot for the update @Michaela! That sounds like great news. Please can you clarify whether the similar error I posted above will also be fixed, or just the 404 originally reported?
I can’t reproduce it either now. Don’t think I even needed to do any of your suggestions, must have been a weird glitch.
Now I’m getting the same 404 as everyone else. However I noticed that the OAuth window created for the authorization flow had the following URL in the address bar:
https://github.com/login/oauth/authorize?scope=repo&client_id=&redirect_uri=https%3A%2F%2Fwww.integromat.com%2Foauth%2Fcb%2Fgithub&response_type=code&state=<censored to be safe>
Notice how client_id is empty here. And indeed I see exactly the same thing in the URL from the screenshot in @UncleTallest’s above post where he’s trying without specifying a ClientID.