heypete

Cool. I sent you a few bucks. Thanks again for the quick response.

In regards to Varnish, I’m afraid I don’t really know the details, but https://www.varnish-cache.org/docs/3.0/tutorial/purging.html seems to suggest that the Varnish server can respond with various HTTP status codes to indicate if it’s successfully purged the cache. I know my particular host does, but I have no idea if that’s a universal thing or not.

Honestly, don’t worry about the status code thing. I was more or less thinking out loud. ??

Awesome. That was quick, and it works great. Thanks!

Do you have a PayPal link or some other way for me to send you a bit of cash?

In regards to Varnish itself, thanks for the tips and I totally understand there’s not any way to read the logs (I can’t either: they’re on separate, dedicated cache servers run by the host.) from within WordPress. I was just hoping there’d be a way to see if the response had a 200 HTTP status code or some other error code that might indicate something went wrong.

Shiny, I’d appreciate it. I’m happy to offer a donation bounty as an encouragement. ??

On a related note, is there some sort of debug mode so one could view the response from the Varnish server to confirm that it’s correctly received the request and has acted on it or? It’d be nice to make sure things are working correctly or, if not, what the error message is.

I ask because my host has a particular arrangement where, instead of running Varnish on the same server as Apache, there’s an array of load-balanced Varnish caches that sit in front of the back-end web servers. The Varnish caches hold onto data for a long time without automatically purging. This causes issues if I don’t manually purge the cache for the feed, as subscribers won’t see any new postings until I get around to doing that: I’ve had stale data sitting in the cache for around a week before I finally got wise and manually purged it.

D’oh. I just noticed that “Disable regular WordPress username/password login to ensure terminated employees can not login in the future” is a feature for the Premium plugin and is not available for the free plugin. Seems reasonable to me.

My apologies for the noise. I’ve marked this thread as resolved.

I think that having a backup code (as an option, not as a requirement) would be a good idea — yes, I can edit the database and regain access to a lost account but that’s still a bit of a hassle. Not everyone wants to (or feels comfortable with) directly accessing the database and figuring out what to do.

Since the “app password” feature is already an option, how would this be any different than simply adding another password?

Hi Henrik,

Fair enough.

For reference, gooze.eu (located in France) sells the tokens and other such devices. I have no affiliation with them other than as a customer so don’t think I’m trying to spam for them. I’m in Switzerland, and I agree that such tokens are not commonly available at retail (though Blizzard and PayPal both offer hardware tokens for more secure logins, so they’re not unheard of).

If you want some help in regards to iPhone compatibility, please feel free to contact me off-forum and I’d be happy to help as I have a iOS device here for testing. That said, the nice thing with the various Google Authenticator apps on different platforms (and on hardware tokens) is that they all implement the same standard, keeping life a bit easier. ??

I may be one of the rare people who doesn’t leave home with a smartphone: I have a rather “dumb” phone that makes calls and sends/receives SMS messages. It’s nice because the battery lasts for weeks. I also have an iPod Touch (which runs the iOS Google Authenticator app, among other things) but I don’t like carrying it around all the time when I’m not going to be listening to music (one less thing to carry). My hardware token is on my keyring, which is always with me.

Anyway, if you ever decide to change your mind and want to support OATH-compatible hardware tokens I’d be happy to help in whatever way I can.

Cheers!
-Pete

Hi Henrik,

Yes, there is a free app from Google, but not everyone has their smartphones (or compatible devices) with them at all times. Hardware tokens also offer a degree of isolation compared to smartphones: the token has no interface with the outside world and so is much less likely to be hacked or otherwise compromised compared to an smartphone.

I use the Google Authenticator app for some sites, but prefer the hardware token for others — as both the token and the Google Authenticator app both implement the OATH standard (albeit it with different time intervals), this isn’t usually a problem.

I appreciate the desire for simplicity, but it’s also nice to have some choices that would allow users to use other OATH-compliant software/devices rather than be limited to the behavior of a specific smartphone app.

Rather than fork the plugin, I’d be happy to contribute some patches that implement the features I propose while also maintaining the simplicity of the user interface. You’d be under no obligation to implement the patches, of course, but I figured I could be of some use. ??

Cheers!
-Pete