Asked Repeatedly to Authorize

Hrm, I have a couple of questions to follow up:

do you have Long Lived Tokens set up on the Application(s)? See screenshot:

What version of the module do you have installed?

Yes, long lived refresh tokens and version 3.1.3 of the module.

Each token seems like it only lasts 2 hours (e.g., "Last token was generated at 06/13/2023 10:33 am and expires on 06/13/2023 12:33 pm."). Should they be lasting for longer than that? And is an outdated token what triggers the module to show the "Authorize Your Account" button? It seems like the tokens should be refreshing regularly since we've got cron running every 15 minutes on the site, but it seems like something's falling through the cracks somewhere. It seems to be really inconsistent when we're periodically seeing the need to re-authorize.

So by default constant contact expires the access tokens "Access tokens automatically expire 1440 minutes (86,400 seconds). Making an API call with an expired access token returns a 401 unauthorized status code." so it should be saying 24 hours.. So that 2 hours is odd it may be a typo HOWEVER I don't think that would cause your tokens to need to be reauthorized manually. That time/date is what flags the cron to get a new token so that it doesn't expire.

Some other questions that may help... Is it the production environment that is always needing reauthorizations? Or the dev/staging environments?
We use pantheon, and I know the dev instances (non-live) stop auto-running cron sometimes if it has been inactive for awhile. But it shouldn't happen in the production (live) environment since that doesn't happen.

Are you using configuration sync? If so, when you go to the sync screen /admin/config/development/configuration is ik_constant_contact.tokens listed in the changed group?

Do you have the ik_constant_contact_tokens table in your database? If not, perhaps you need to run database updates? If you have recently done the update where tokens were moved to the database, it could potentially have cause a need to manually re-authorize the app.. but it shouldn't repeat.

I'm gonna keep trying to figure out what's going on, but I'm not sure because I haven't been able to recreate it in my environments that are using the module.

My guess is that the token is somehow expiring without being successfully refreshed. They mention on that documentation page that "If the access token expires, users must reauthenticate and reauthorize your application through Constant Contact. Making an API call with an expired access token returns a 401 unauthorized status code."

So far I've only seen the live pantheon environment with this issue, but I admit I haven't been testing it as consistently on our dev environment. I'll try to set that up today and monitor it over the next few days.

Just to answer a couple of your questions:

• No, we're not using the configuration sync module.
• No, we don't have the ik_constant_contact_tokens table in the database since we didn't end up moving that patched version to the live site before noticing issues.

I'm going to double-check our cron configuration. We've currently got New Relic set to trigger cron every 15 minutes, but I just want to check through the logs and verify that that has been happening especially late at night when few customers would be looking at the site.

One other thing I noticed on my local environment (probably not the cause of the issue, but still strange) is that the "expires on" message from the module page is displaying the current time as the expiration time (see screenshot below). Pantheon environments are still showing that it expires 2 hours after initial authorization.

It does look like cron has been running regularly every 15 minutes. Here are the log messages coming from the ik_constant_contact module:

According to the module's log messages, the tokens were refreshed at 8:47 pm last night but then not again until 9:48 am this morning (when I manually re-authorized). Cron was running throughout the night so I'm not sure what caused the large time gap in refreshing the tokens.

I just wanted to post an update and say that I've been checking in on the settings page approximately every 12 hours over the last few days and this hasn't come up again. I'll continue to monitor it for a few more days. Hopefully it was a temporary fluke? I'm just not sure to be honest.

So strange. I have been a bit swamped so I haven't had a chance to look into this further but thanks for updating and providing all the additional information.

Since I haven't seen this again over the last week, I'm going to go ahead and close this. Must've been a temporary issue in our Pantheon environments.

Thanks for the update! Feel free to reopen or create a new issue if something changes.

Reopening this issue since it happened again today. I believe it happens after we do a code deployment to our live site. The last time it happened was when we did a code deployment on 6/13 and it happened again when we did a deployment last night. Could it be that the config import that is happening on Pantheon is overwriting the current CC tokens with what's stored in config (presumably and old outdated token)?

Hrm, possibly. Do you have any deployment/workflow hooks that runs config:import?

I would try the newest patch in #3215168 → and try and move the tokens into the database.

Yes, I believe the automatic config import is done using their "quicksilver" setup. OK, I might try that.

Marking as fixed due to inactivity. Please reopen if need be. Thanks!