Possible issue and diagnosis for Dropbox connections - VisualCron - Forum

Community forum

bweston
2022-02-08T16:55:12Z
I'd had an issue for a while (on 9.9.0, I think?) where my Dropbox connection would need to be re-authorized every few weeks. Recently (about a week after I updated to 9.9.5, I think) it got to where it didn't even seem to last a day. After updating to 9.9.6 and still having the same problem, I eventually tried something I hadn't thought of before; I switched from the connection using the "Visualcron registered app" in the connection settings to one I'd created a while back using a custom app connection...and it has (knock on wood) kept working since.

This prompted me to look up some details, and I came across a "feature" that I hadn't known about. Based on some information I found - albeit some of which is from a year or two ago - it sounds like, when creating a dropbox app, one can choose how long the authorization for it lasts, including (I think) options of the original "practically indefinitely" and of the accidentally-made-default-for-a-while-when-they-introduced-the-feature four hours.

Four hours seems like it might correspond to the behavior I'd been observing.

Is it possible that the "Visualcron registered app" for Dropbox got its authentication window accidentally set to an impractically short time for a job runner somewhere along the line?
bweston
2022-02-21T17:26:04Z
Going by the Dropbox documentation, it appears that they ended support for long-lived tokens in September (not sure why our custom app kept working for a while), so to restore the expected behavior, the Visualcron workflow or registered app may need to implement support for refresh tokens. I imagine that, despite this being effectively a Visualcron bug by most reasonable standards, that may mean this topic needs to be moved to Feature Requests for organizational purposes. However, in combination with the much less responsive new UI, it makes Dropbox cloud file triggers practically unusable.
Support
2022-02-22T08:35:03Z
Originally Posted by: bweston 

Going by the Dropbox documentation, it appears that they ended support for long-lived tokens in September (not sure why our custom app kept working for a while), so to restore the expected behavior, the Visualcron workflow or registered app may need to implement support for refresh tokens. I imagine that, despite this being effectively a Visualcron bug by most reasonable standards, that may mean this topic needs to be moved to Feature Requests for organizational purposes. However, in combination with the much less responsive new UI, it makes Dropbox cloud file triggers practically unusable.



Can you elaborate the issue a bit please? We are storing and using refresh token
Michael
Support
http://www.visualcron.com 

Please like  VisualCron on facebook!
bweston
2022-02-22T14:25:53Z
Really? Hmm. I will check shortly and see if this is one of those cases where I need to re-create the connection to get the correct behavior. (Of course I won't know for a while, but...)

As it stands, like clockwork, four hours after authorizing the connection, I start getting "A session of the connection 'Visualcron (Official)' has expired - do you want to open the Connection Explorer to restore the session?" for every attempt to contact Dropbox, apparently including the trigger checking for new files. The ones from the trigger come up almost faster than it is possible to close them, which, since they are modal, makes it very difficult to get the trigger turned off while I re-authorize the connection. I've been thinking of writing up a Powershell script for the purpose, but we're only using Dropbox because of one vendor and they plan to move away from it by the end of 2021 so I hadn't put forth the effort.
Support
2022-02-22T14:29:22Z
Originally Posted by: bweston 

Really? Hmm. I will check shortly and see if this is one of those cases where I need to re-create the connection to get the correct behavior.

As it stands, like clockwork, four hours after authorizing the connection, I start getting "A session of the connection 'Visualcron (Official)' has expired - do you want to open the Connection Explorer to restore the session?" for every attempt to contact Dropbox, apparently including the trigger checking for new files. The ones from the trigger come up almost faster than it is possible to close them, which, since they are modal, makes it very difficult to get the trigger turned off while I re-authorize the connection. I've been thinking of writing up a Powershell script for the purpose, but we're only using Dropbox because of one vendor and they plan to move away from it by the end of 2021 so I hadn't put forth the effort.



Please do try and re-create it and let me know the results.
Michael
Support
http://www.visualcron.com 

Please like  VisualCron on facebook!
bweston
2022-02-22T18:51:42Z
Same result.

Also, the "on error reconnect attempts" and "on error reconnect interval" settings on the trigger dialog don't seem to save, which may explain why my prior attempts to make the flood of errors on failure more manageable (say, retry five times a minute apart instead of every ten seconds for ten minutes) didn't work. I have not yet tried setting those through the API instead, but now that I've discovered that issue I probably will.The default interval of ten seconds is barely long enough for the client to finish rendering the alert and respond to it being closed. I have to click through at least a dozen or so of that modal dialog just to get in and disable the thing that's causing them. I'd consider those pretty reasonable default settings for retrying a connection in general, but not for one that can pop up an alert (especially a modal one) every time it's attempted.
Support
2022-02-23T09:41:14Z
Originally Posted by: bweston 

Same result.

Also, the "on error reconnect attempts" and "on error reconnect interval" settings on the trigger dialog don't seem to save, which may explain why my prior attempts to make the flood of errors on failure more manageable (say, retry five times a minute apart instead of every ten seconds for ten minutes) didn't work. I have not yet tried setting those through the API instead, but now that I've discovered that issue I probably will.The default interval of ten seconds is barely long enough for the client to finish rendering the alert and respond to it being closed. I have to click through at least a dozen or so of that modal dialog just to get in and disable the thing that's causing them. I'd consider those pretty reasonable default settings for retrying a connection in general, but not for one that can pop up an alert (especially a modal one) every time it's attempted.



Ok,

Can you please tell me how to reproduce this in steps? I have a dropbox connection added, no issues, works fine for the cloud tasks etc. So what you're saying is that in about 4 hours it will drop it's connection and i would have to re-authenticate?
Michael
Support
http://www.visualcron.com 

Please like  VisualCron on facebook!
bweston
2022-02-23T18:31:46Z
That's what's happening for me, yes, unless there is a variable I haven't accounted for, which is possible.

I don't think a cloud file trigger is necessary to make it happen, but it occurs to me that I'm not 100% sure how recently I last tried to use a timed (about five times a day) check instead of the cloud file trigger, so I suppose I have not completely ruled out that rather than a token expiring, I'm hitting some kind of Dropbox rate limit based on a four-hour window; I will test that today.

That said, assuming the trigger polling interval works as expected, I seem to have had the same four-hour behavior with triggers polling only every ten minutes, and I'd be somewhat surprised if that were triggering such a limit.

Also worth noting, although I'm nowhere near certain I've understood this part correctly: Going by the documentation at https://dropbox.tech/dev...ssions-and-access-tokens , I expected that if the Visualcron implementation used refresh tokens as prescribed, then when I tried to authenticate using my system browser rather than the internal one, the url it took me to would include "&token_access_type=offline", and it didn't. (In fact, I briefly had hopes that just adding that to the url and reloading the page before approving access would fix the problem, but alas, it did not - and shouldn't have, if that were actually part of the issue, since just because the response includes a refresh token wouldn't mean the access token was being handled any differently.) However, it's entirely possible I'm wrong about that being the point at which that parameter would be needed.

I wish I had paid closer attention to when I made which changes and to Dropbox's change announcements, because I don't think the observed behavior fits with the originally announced timeline of their discontinuing long-lived access tokens and requiring the use of refresh tokens starting September 30...but then, I don't think anything else fits both the observed behavior and the timeline either unless they not only do have something that invalidates permissions or tokens based on a four-hour rate limit window, but reduced that limit on at least three separate occasions this year. However, that's all based on vague recollections rather than recorded observations.
bweston
2022-02-24T15:35:29Z
I forgot to check right at four hours yesterday. I will try to remember today. That said, after being checked four times and then left unqueried for 18 hours the connection needed to be re-authorized, the connection needed to be authorized again, which is a problematically short window even if there is also a rate limit involved.

The error message from the task in this state, since I don't think I'd detailed that yet, is:

Exception in Task: Dropbox server reports the following error: 400 "Bad Request"
Error in call to API function "files/list_folder": Must provide HTTP header "Authorization" or URL parameter "authorization".

I usually barely take notice of that error since the modal pop-up saying the session has expired is much more prominent if the client is open.
bweston
2022-03-01T21:35:07Z
Had a busy few days...it's definitely no longer able to connect after four hours, even if it only tries eight times or so during that window.
Support
2022-03-09T15:58:00Z
Originally Posted by: bweston 

Had a busy few days...it's definitely no longer able to connect after four hours, even if it only tries eight times or so during that window.



Continuing this via email, going to investigate myself to see if it drops connection after same amount of time.
Michael
Support
http://www.visualcron.com 

Please like  VisualCron on facebook!
Michael Fjellström
2022-03-11T08:43:06Z
Originally Posted by: bweston 

Had a busy few days...it's definitely no longer able to connect after four hours, even if it only tries eight times or so during that window.



I can confirm that the refresh token only lasts 4 hours. We're investigating this and will get back to you when we have an update on it.
bweston
2022-04-21T13:55:13Z
Just to double-check: It doesn't appear a fix for this has landed yet? I don't see it in release notes or beta version threads; I imagine it's possible I will need to re-create connections once it does land, but I don't want to take the time to do that if the fix isn't even supposed to be released yet.
Michael Fjellström
2022-04-29T15:25:53Z
Originally Posted by: bweston 

Just to double-check: It doesn't appear a fix for this has landed yet? I don't see it in release notes or beta version threads; I imagine it's possible I will need to re-create connections once it does land, but I don't want to take the time to do that if the fix isn't even supposed to be released yet.



A fix should have been made yes, i'm not sure why it's not listed. Did you try the latest version and see if it works?
bweston
2022-04-29T15:39:54Z
I upgraded, and still have the same problem, but in the absence of an entry in the release notes or a report on this thread, I had not tried re-creating the connection and replacing it everywhere it is used yet. I will hopefully try that today or next week.
Michael Fjellström
2022-05-03T14:33:59Z
Originally Posted by: bweston 

I upgraded, and still have the same problem, but in the absence of an entry in the release notes or a report on this thread, I had not tried re-creating the connection and replacing it everywhere it is used yet. I will hopefully try that today or next week.



Please do and let us know if the issue persists after re-creating it.
bweston
2022-05-03T15:20:00Z
I created a new connection yesterday and rather than going ahead and switching the relevant tasks over to it, tried connecting to it with the connection explorer again this morning; there is no change in behavior as far as I can tell. I also note that the query string parameter I mentioned above still doesn't appear in the url when authenticating in an external browser, although I also acknowledge that I'm not sure whether I was correct in thinking it should do so in the first place.

I may try deleting all Dropbox connections and recreating just one later today, although it doesn't seem logical that the new one would have this problem just because the old ones still exist.
bweston
2022-05-26T16:18:33Z
I finally had some time after upgrading to 9.9.8, so I removed all Dropbox connection objects and created a new one to see if that helped. Same behavior seems to persist; the following day the app is no longer authorized.
Michael Fjellström
2022-06-09T13:46:34Z
Originally Posted by: bweston 

I finally had some time after upgrading to 9.9.8, so I removed all Dropbox connection objects and created a new one to see if that helped. Same behavior seems to persist; the following day the app is no longer authorized.



Hi,

Apologize for the long wait time here. Just wanted to let you know we are aware of this issue and our developers are working on implementing a refresh_token method to overcome the 4hour official dropbox token time length.
Scroll to Top