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?

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.

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

---

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.

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.

---

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.

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?

---

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.

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.

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.

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.

---

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.

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.

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?

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.

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.

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.

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.

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.

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?

Hi,

I just wanted to let you know that this should be fixed in our 9.9.9 beta build here: https://www.visualcron.c...aspx?g=Posts&t=10621 

That's great. Unfortunately I can't test that, because the currently available beta also appears to pass the command as the first argument to itself in an Execute Command task. It looks like it might do this INSTEAD of passing the specified arguments - that is, "echo echo" rather than "echo echo test" when it's supposed to be doing "echo test" - but I don't have time to verify; I need to roll back to a non-broken version.

I look forward to the proper release.

In the meantime, I think I have finally found a workaround, which I feel slightly silly for not having come up with sooner. We'll see how that goes...in about four hours, I guess.

I don't suppose you could tell me what the 18-digit number after the tilde, appended to the access token that is stored as the refresh_token field of the connection in 9.9.8, actually means?

Edit and edit again: I think I figured it out myself...I think it is the time UTC in ticks that the access token Visualcron got from Dropbox the last time I went through the authorization process will expire, and Visualcron won't try to connect using the stored token if the timestamp stored with it says it shouldn't work.

Based on this, in turn, I think I have now fixed the workaround I mentioned above...using my own app instead of the visualcron official one, I can refresh the token and update its recorded expiration (which is what I missed the first time around) using the API.

The drawback is that I think one or two more people theoretically have access to dig out the refresh token from where I implemented it than already had that level of access to the Dropbox account.

That said, it works.

Good news: My workaround has been working for the past week. The connection still works in the Connection Explorer, in fact.

Bad news: Despite being able to browse in the connection explorer, I get the connection expired error from the connection's Test button, from the Download Cloud Files tasks, and from the trigger. I'm not sure what would explain that unless either using the connection everywhere but the explorer somehow requires something the explorer doesn't, that needs some property of access that the access tokens I'm getting with my refresh token don't have (or that's somehow using a different access token), or if 9.9.8 has another internal time check that I haven't figured out how to reassure.