API key and authentication codes keep resetting

Yikes Jon, as the test engineer here I have never seen this issue occur nor heard about it. I’ve reached out to Sean, the developer, to get his thoughts. While we wait, if you could come up with steps to reproduce that would be awesome. But, I will understand why you may not be able to given the very odd intermittent nature of this issue.

In the meantime, if you have this issue again, it would be best to “log out” then log back in. I say “log out” because we haven’t yet setup an actual log out button. Instead, on the Benchmark > Settings page, delete the contents of all three fields (i.e., API Key, Authentication Token, and Automation Pro Token) then click Save Changes. Once logged out, log back in. In fact, do this now to make sure we’re all on the same page.

Hi @jonfurse and @randywsandberg

Thanks for getting in touch about this issue. Let’s try to figure it out!

So what occurs to me here is that the API-Key field is only set when the plugin settings are saved and when the plugin is upgraded from v2.x to v3.x, but the Authentication-Key is renewed up to twice daily – to renew before it expires on ui.benchmarkemail.com servers and becomes non renewable (requiring username+password which we do not store for security reasons).

For Randy, a test case here is to install the Crontrol plugin and run wpbme_token_renew to see if we can replicate anything with the renewal process of a given set of keys, maybe during certain times of day. It’s possible that a bad server response there may not be getting caught and skipped by our plugin, though we do check for a specific Token parameter in the response.

Most of all, I’d like to know which token(s) is/are changing and what the change is to.

Also the post-to-campaign feature described here uses both keys. It uses the API-Key to create the campaign record and set initial values, then the Authentication-Key to redirect the user to the campaign editor modal for that campaign. The final key is only for a JavaScript asset for Automation Pro workflow tracking.

One thing I can definitely do in the next version is add some more wpnonce filters, to tighten things up further, say if the problem is happening with the form submission on the Settings page.

I’ll work on some minor updates for our next version getting close here, but let me know if we get any further data on this one. Thanks again for reporting ??

Many @randywsandberg and @seanconklin for your helpful responses. I’ve followed Randy’s advice and ‘logged out’ and logged back in again and I can confirm I’m still able to publish Benchmark campaigns. I wonder now if the log in function is relatively new or whether I inherited the configuration already ‘logged in’ and therefore didn’t know other than to manually apply the API key. I guess the two are equivalent but perhaps there’s some subtlety there?

Anyway, I’m unable to replicate the fail scenario unfortunately as I don’t know what the trigger is. If/when it happens again, I’ll record version numbers of WP and BE to see if it’s an upgrade.

Hi @jonfurse. The upgrade logic triggers when the wp_options value for wpbme_db_version is not ‘3.0’. It’s possible some server caching could lock that up and trigger the import from the legacy benchmark-email-lite_group settings value, if you have that still populated, also within the wp_options table.

If using server object caching (by your hosting service) it’s a good idea to periodically check your wp_options table for any oversized rows (over 60k characters long). Caching is never perfect and can cause weird issues. Once every few months sounds about right there! It’s hypothetical, but worth a look.

Other health checks I usually do is install the Crontrol plugin to check for any late cron items, and I use WP Optimize plugin to scan the database for junk records to cleanup. It never hurts!

Do let us know if the problem returns and specifically what gets changed to what and where. A screenshot or any specifics we can get may help.

In the meantime @randywsandberg and I will continue testing and will consider all possible causes. We’ll leave this ticket unresolved until we have a clear fix or you confirm it to be all cleared-up.

hi Sean/Randy,

Well, it’s happened again (at the weekend, of course!). By happened again, I mean the same as before: “Create Email Campaign” from a post, the user (any admin user, since admin seems to be necessary to execute the BME plugin), is presented with “Sorry, you are not allowed to access this page.” for URI “/wp-admin/admin.php?page=wpbme_interface&post=27539”. This time it’s just the authentication token that’s not populated. The API key is correct.

I’ve checked versions and I can confirm it’s definitely not triggered by either WP or BME upgrade as I still have the versions I posted 3 weeks ago.

I’ve also had a look at the wp_options table and I can confirm there are no very large sized rows in there. I’m afraid I don’t know WP well enough to follow your Control advise Randy. There isn’t much to screenshot either – just the failure page and empty authentication token on the settings page.

I’ve repeated the advice from before to ‘logout’ and log back in again and this has worked, as it did last time. For how many weeks?

I would be keen to understand if you’ve managed to replicate the issue or whether I should be looking at anything else next time it happens.

Many thanks

Jon

Hey Jon, so sorry to hear this. Must be super frustrating to say the least! Is there anything you can remember doing prior to this happening again? Anything at all website related will be helpful in figuring this out. And no, other than manually deleting the API Key and/or Authentication Token and saving the page, I haven’t been able to reproduce the issue. Obviously, that doesn’t mean it doesn’t exist. But, we do need a reproducible case so we can fix it. Thus, anything you or your site did around the time of the issue will be very helpful. Thanks in advance!

P.S., Prior to this issue happening, have you ever simply saved the Benchmark > Settings page???

P.P.S., If possible, please list out the plugins and their versions that you use along with WordPress itself and your theme.

• This reply was modified 4 years ago by Randy Sandberg.

Hi @jonfurse,

Thanks again for passing along the details. From what you describe it sounds like the entry vector here is not the v3 upgrade logic, rather the wpbme_token_renew process.

That process runs twice daily in the WP cron system plus upon UI interface launch when the TTL has been reached (aged over 24 hours). This is done to keep your Authentication-Key (UI auth token) current. That token is issued by Benchmark servers for 48 hours as we understand it must be renewed prior to expiration.

I noticed in the code that when the Benchmark server response does not contain a proper token we clear the existing value. The theory there is that the token it’s trying to replace must already be bad, but in this case seemingly makes more sense to leave it intact until the next cycle. So I’m removing that line of code in the next version, which Randy is in the process of testing for a release soon. We’ll be sure to get that released within three weeks so you hopefully don’t see this happen again ??

That doesn’t mean that your UI token renewals are good though. Let’s see as to why the token was not coming back from the server. Does your website execute WP cron properly? WordPress itself has a health check that includes something for this under WP Admin > Tools > Site Health. If it says “A scheduled event is late” then you should investigate that further with your web host. There should be a one minute pulse happening on the server to wake the cron scheduler. In some cases I’ve used a third party monitoring tool to send that pulse, but some web hosts block that as they prefer to do it internally. Secondly, you can install the Crontrol plugin to view what’s in cron manually. Finally, the WP-CLI tool can be used to view and run WP cron events.

I’m leaving this ticket open until we have another month or so of evidence that it’s resolved with this next version 3.4

Best,
Sean