Child Item

CloudRail - Dropbox - Missing client_id

Dropbox login via API has just started failing again with new symptoms (dozens of my users reported failures on logging in). After logging in, and solving the "video puzzle" the log in button appears, but tapping it shows a 'busy cursor' for a few seconds and the login button is displayed again - at that point, dropbox is stuck in a loop.

DId someone try installing a new upgrade over this weekend??

Find more posts tagged with

Comments

Greg-DB

Thanks for the report. This sounds like a different kind of issue than the one in your original thread, so I've moved this to its own thread.

Are you still seeing this issue now? If so, can you let me know the specific steps to reproduce it? It may be helpful if you can share a short screen recording showing the issue. I'm not seeing this behavior myself so that additional information would be useful. Thanks in advance!

cesdewar

Yes, symptoms are slightly different, and yes, the problem still exists. There are thousands of users of my Pimlical Advanced Calendar that use AutoSync, and right now, no one can log in any more into Dropbox from Android Phones (although desktop version of Pimlical is ok). Pimlical uses the former CloudRail libraries to interface with the Dropbox API and log into Dropbox (on both Android and Desktop). Versions of Pimlical/Android from 2+ years ago (which have always worked flawlessly) also now fail, so the certainty is 100% that there has been a very recent change in Dropbox (first reports of this new, 2nd issue appeared 5 days ago, on May 2nd, 2025). CloudRail libraries have not been changed in any way for several years.

I can't attach Video showing failure as this forum apparently does not permit MP4 files to be attached or even linked to via URL(?!?). Here's a URL with the Video (Plays fine after DL and launch under Windows (my Chrome browser won't play it directly) - it's a standard Android Screen Capture file.... https://www.PimlicoSoftware.com/DropboxLoginFailure.mp4

So, I can think of no other rational explanation other than that another update was posted around May 1/2 - that must have happened, right?

Regards,
CESDewar

cesdewar

My reply just disappeared (??). did you/someone remove it?

Pimlical Advanced Calendar logs into Dropbox using the older CloudRail Java libraries that connect to the Dropbox API. This has worked flawlessly for many years until a couple of weeks ago when an update broke it (promptly fixed and then ok) - but then this last weekend, login failed again - this time, the login button appears on the web page but it cycles around endlessly, never logging in. Versions of Pimlical from 2 years ago, also fail and the CloudRail libraries have not been updated in years. There are several thousand Pimlical users who use AutoSync to sync their files with Dropbox - and reports started piling in on May 2nd - a few days ago).

I was not able to attach the screen-capture video file (only fixed graphics are allowed, apparently) either directly or via URL. I am not sure that including a URL directly here is allowed either (maybe why my replies disappeared??).

If you go to my website www followed by PimlicoSoftware and standard dot-com domain and follow it with a slash and 'dropboxloginfailure' followed by standard dot-html - you will see a link to the video file.

Regards,
CESDewar

Greg-DB

Thanks for following up. Your reply was caught by a spam filter; I've now recovered it.

It looks like you're processing the OAuth app authorization flow in a web view in your app. Can you also try it out in the system web browser itself on the device and let me know if the issue does or doesn't reproduce there as well, and also let me know the name and version number of that system web browser? Thanks!

cesdewar

I also put that MP4 video up on a web page on my domain: can't specify directly, so you will have to interpret this:
use PimlicoSoftware with standard dot-com extension, a slash and then dropboxloginfailure with standard dot-h-t-m-l extension.

you can right-click the link there to save it and play it locally (if web browser won't play it directly). Just want to be sure you saw this, and that you know the issue still exists as of May 9th, 2025).

Regards,
CESDewar

Greg-DB

@cesdewar It sounds like my reply from 5/7 didn't make it to you. I've copied it below for reference:

Thanks for following up. Your reply was caught by a spam filter; I've now recovered it.

It looks like you're processing the OAuth app authorization flow in a web view in your app. Can you also try it out in the system web browser itself on the device and let me know if the issue does or doesn't reproduce there as well, and also let me know the name and version number of that system web browser? Thanks!

cesdewar

Web browser logs in fine on Android phone. This is what's bizarre - Pimlical/Desktop uses 100% identical code in Java to access Dropbox via CloudRail (and I think the CloudRail library is identical too(!) as a Java library, and that still works.

BUT this login has worked fine for YEARS on Android - and even old versions of Pimlical/Android from 2+ years ago are failing to log in (so it's not anything changed in Pimlical/Android or CloudRail), AND the first reports of failures started on Friday May 2nd, so something MUST have changed at the Dropbox end that day - but it's impossible to discern what the might be from here as Dropbox is it's hidden in the CloudRail library. Because it failed a couple of weeks prior (and was a failure in a Dropbox update that was acknowledged and fixed), and then 2 weeks later started failing again, my assumption is that Dropbox was attempting to slip in that upgrade again but the fix was incomplete in some way. It would still be very helpful to know if indeed Dropbox slipped in an update on May 2nd... (that just has to be the case)....

Regards,
CESDewar

cesdewar

OK - one of my users found your problem. your new update that you posted in May 2nd, NOW REQUIRES 2-FACTOR AUTHENTICATION be set for logging in via the API. It would be really nice if this update at least MENTIONED that was the issue instead of just cycling back to the login button with no indication whatsoever as to what the problem was (when clearly the program internally knew precisely what the issue was).

I have tested this, and sure enough, on setting 2-factor authentication, and providing the code, it now proceeds to login without problems.

But this new requirement only appeared on May 2nd, 2025, and only on Android phones logging in via the API (logging in via API on Windows apparently still does not require this). If there was just some notification when new updates are posted, that would be helpful. And it would be even nicer if you could restore the original login WITHOUT requiring 2-factor authentication and let the user decide for themselves if they want to burden themselves with an extra, authentication step every time they access Dropbox to use Pimlical's AutoSync for improved security.

Regards,
CESDewar.

cesdewar

No, I spoke too soon. After I got that successful login after setting 2-factor authentication (a user suggested that was the solution after it worked for them), I rather thought it was fixed, but no. Second attempt failed just like it has been failing all the time, with Dropbox constantly returning to the same screen, presenting the LOGIN button but never logging in, and never giving any indication as to why the LOGIN failed.

So the problem is still there.

Regards,
CESDewar

Greg-DB

Thanks for trying that and confirming it works in the system browser and following up with the additional information. That being the case, can you update the app to process the authorization flow using the system browser instead of a web view? Per the Dropbox /oauth2/authorize documentation, this flow is not meant to be performed in a web view (in part because we have found web views to be more susceptible to incompatibilities).

Dropbox users may sign in to Dropbox using a variety of different authentication methods (email and password, with or without two-factor authentication, SSO, etc.). Third party apps don't need to know exactly what method is being used by the user to sign in when they want to authorize an app to access their accounts. When using the OAuth app authorization flow with a redirect URI, for instance, Dropbox will direct the user's browser to the specified redirect URI once the user has finished signing in and authorizing the app.

Unfortunately it sounds like in this case the web view is experiencing an incompatibility with the current version of the web site, so it will be best to make sure you're using the system browser as described in the documentation for compatibility with the web site.