After debugging, I suspect the cloudflare DDOS prevention page is the culprit. When the above login URL is loaded inside the Excel add-in (User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko), it will return HTTP 503 with HTML page showing messages like "DDoS protection by Cloudflare Ray ID: 4dadd2d9ef5abcde". That cloudflare page stuck there and thus the actual hubspot login page was not loaded at all.
In comparison, when the same login URL is loaded in Chrome directly, it returns 200 with the right login page HTML markups.
I wonder how does hubspot login page decide whether it will return a cloudflare DDOS prevention page or the actual login page? Do you recommend any solution for the login page to work again inside Excel add-in environment? This is blocking hubspot users to use our integration. Thank you!
I'm not sure yet why this is happening. But as of now I'd assume that you're right: possibly some new CloudFlare DDoS protection is preventing the auth server from loading. I'm working on getting some clarification for you on how that CloudFlare page works or is intended to work. It may very well be the user agent string. But I'll get some more details for you about this.
Login page fails when loaded inside Microsoft Office add-ins
Thank you so much!! This will help is a lot. Our addin users are in pain now. It’s risky for us to do any workaround without understanding how this DDOS prevention logic work. Look forward to your reply. Thanks!!
So I brought this up with one of our engineers. They've made a fix to how the DDoS preventation page works inside of MS Office add-ins. When you get a chance, could you just confirm for me that you're not longer getting stuck at the DDoS prevention page in Excel?
Login page fails when loaded inside Microsoft Office add-ins
Hi @lscanlan , thank you for following up and making the change. Unfortuantely, our users report it still doesn't work. https://appsource.microsoft.com/en-us/product/office/WA104380674?src=office&tab=Overview is our office plugin, if you could provide that link to Hubspot engineering team, it would help them test. I think the DDoS prevention algorithm make the behavior different for different end users. Quite a number of our users are completely blocked, while we can't reproduce the issue on our end. This is quite frustrating! Please help! Thanks!
I've reached out for another update on this one. I haven't heard back since the last message, but I'll convey the urgency for you. Hopefully I'll have something more concrete for you soon.
So rather than the team trying again to make these one-off fixes and hoping that it corrects the issue, they were wondering if you could provide specific log lines. In particular, log lines with blocked requests, or info about the user agent, a header value, or something that we can whitelist on. Or even a small timeframe (the timeframe of when the blocked request happened) with a specific IP address, which could help us narrow things down on our side.
Let me know if it's possible for you to provide that, or if you have any questions.