Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


Login loop on wp-admin page

Noticed that MarsEdit was giving errors when trying to login to my WordPress blog. Similarly the wp-admin page would go into a login loop. This didn’t always happen. It looked like some public IPs of my ISP were being blocked. (I’ve seen similar behavior with Teams audio too. On some of my public IPs audio doesn’t work; disconnect & reconnect my WAN connection to get a new IP and if that’s from a different subnet it usually works).

This could be because you have JetPack installed on your block and it’s set to block brute force attacks. The solution is to login to the wp-admin page somehow, then go to JetPack > Settings > Brute force attack protection > expand it > and add your IP to the whitelist section. Repeat of course for each time your public IP changes. (Or you could disable JetPack’s protection I guess, I didn’t want to do that).

My guess is JetPack and whatever else that occasionally doesn’t work me is because some of my public IPs/ subnets are in some database somewhere which marks it as belonging to hackers or bad actors and these database are what is used by all these services to blacklist attacks.

ADFS with Exchange OWA & ECP

Follow the instructions here to setup OWA & ECP authentication via ADFS rather than the default forms based authentication. Here’s another, more concise article. Both articles talk about setting up WAP too which I didn’t do in my home lab. 

I wanted to add something extra to these articles.

In my home lab I have my primary ADFS server, which has a relying party trust setup with OWA & ECP as in these articles. Just to keep things interesting :) I also have a second domain, in a trust relationship with the first domain, and with its own ADFS server and users. The users in this second domain don’t have any Exchange mailboxes – these are hosted in the first domain. The second domain’s ADFS server has the first domain’s ADFS server as its relying party trust; and the first domain’s ADFS server has the second domain’s ADFS server as a claims provider trust apart from the default Active Directory. 

Upshot of the situation is that everyone authenticates with the ADFS server of the primary domain. They are given the choice: 


Selecting “Branch Office” takes them to the second domain ADFS server where they can authenticate and claims are sent to the primary domain ADFS server from where it is passed on to the application. Selecting “Head Office” results in authentication against the Domain Controller of the primary domain itself. Easy peasy.

Now onto the claims setup in the primary domain as part of setting up OWA & ECP. We setup two claims: one takes the WindowsAccountName claim issued by AD and gets the user SID and sends that. 

The other claims takes the WindowsAccountName claim and gets the user UPN and sends that.

So both these claims essentially query AD and send the SID & UPN. They don’t work well with claims passed from another claims provider (such as the ADFS server in my second domain). So what I did is:

  1. On the second ADFS server I already had a rule that passed along all claims to the relying party trust of the primary ADFS server, so I did nothing additional. (If I didn’t have this in place I would have made two rules like I did in the next step). 
  2. On the trust between the primary ADFS server and OWA & ECP I removed the two rules above and made two rules that simply sent UPN & SID as UPN & SID. The idea being that the default rules only query from AD specifically, but I don’t want to limit to that. I will anyways get the UPN & SID claims either from the AD claims or the second ADFS server, so all I need do is pass these on to Exchange. 


That’s it. Now users in the second domain too should be able to use OWA & ECP via ADFS. 

Update: This breaks ECP. Continued in another post.

Trying out MarsEdit

Trying out MarsEdit today. Downloaded a trial version, want to see how it goes. My blogging has reduced a lot last few months – mainly coz I have been super busy, but I don’t want to neglect this blog either. Ever since I switched to macOS I wanted to try MarsEdit but was too stingy to pay for it and didn’t see why I should shell out money when I can do for free via a web UI, but I guess everything’s better consumed via an “app” nowadays and so it just feels more natural to blog via an app than a website. I dunno. Just a reason to try out something I guess. :) 

One thing with a Mac (and Apple in general) is that you tend to spend more. And you don’t mind it too … or at least I don’t. I know with Windows (or Android) apps I’d be stingy and think twice, but with Apple I am fine. That’s the beauty of Apple … they have you reeled in well into the system. 

[Aside] Stretchly – Break time reminder

Via the always resourceful How-To Geek. Came across Stretchly and Big Stretch Reminder. Two software that remind you to take breaks and micro-breaks. I have previously used WorkRave, wanted to try something different now. This time I’ll try Stretchly as I like its UI and is open-source.

Update: Switched to a Mac recently and started using Time Out instead. Stretchly doesn’t properly detect natural breaks (on Mac or Windows) so I began searching for alternatives and came across this.

Reset your self-hosted WordPress password or disable Google Authenticator via phpMyAdmin

No posts for a long time since I am between countries. I got posted to a different branch of the firm I work with, so the past few weeks I have been busy relocating and setting up. Since the last week of March I am now in Dubai. A new place, a fresh start, yaay! Sadly, no blog posts so far as I don’t have time at work or after it. Hopefully that gets rectified soon as things start settling down. 

Today I tried logging in to this blog and it wouldn’t let me. Kept denying access because the username/ password/ Google Authenticator code was incorrect. I know the first two have to be correct because I save them using LastPass so there’s no way I could have forgotten. The last one too has to be correct because it’s automatically generated after all, but who knows, maybe the plugin’s disabled or broken in the past few weeks?

Since this is a self-hosted blog I the idea to use phpMyAdmin and look at the WordPress database. Perhaps I can reset my password from there or disable Google Authenticator? Turns out that’s easy to do. 

Step 1: Login to cPanel of your hosting provider and launch phpMyAdmin. 

Step 2: Click the Databases tab and select your database. 

Step 3: Go over to the wp_usermeta or wp_users table. The former is for Google Authenticator. The latter for password. The latter has a row for each user. Click the Edit link for the user you want, go to the user_pass field, and enter an MD5 hash of the password you want. (If you use DuckDuckGo you can simply type the word followed by md5 and it will give you the MD5 hash! Else try this link). 

In my case I didn’t mess with the password. I suspected Google Authenticator & simply wanted to disable that. So the first table was what I went after. This table has multiple rows. All user meta data belonging to a particular user will have the same user_id. Find the user you are interested in, note the user_id, then find the key called googleauthenticator_enabled.  If Google Authenticator is enabled for the user this will say enabled; change it to disabled and you are done. 

That’s all for now! 

Add Readability and Instapaper ‘Read Now’ links to your posts

Yesterday I went back and read one of my older posts from my tablet. That made me realize my blog doesn’t have a mobile friendly view. Sure, it doesn’t have any ads or widgets, and the posts appear clean on a browser as my emphasis is on the text/ code, but that doesn’t translate well to a mobile device as the fonts are small and a bit of zooming and scrolling is required to hide the left sidebar and other bits. 

Eventually I read the post using a Readability bookmarklet I had on the mobile browser so that got me thinking I must add quick links to do this for each post so any visitors can take advantage of the same. 

I use Instapaper for most of my reading. For some posts that Instapaper has difficulty rendering (mostly posts with a lot of code, pictures) I use Pocket. I prefer Readability over Pocket as its iOS app is terrific, but Readability’s Android app sucks (poor UI, syncing issues, doesn’t keep track of my last read location) and so I use Pocket rather than Readability. 

For publishers Readability offers an embed code. This is good in that it allows one to read the page in a Readability view without adding to Readability (similar to what I did yesterday using the bookmarklet). It also lets you add the page to Readability, print it, send to Kindle, or email – useful stuff. What I don’t like about the embed code, though, is that it pulls in JavaScript from their website and adds a block of buttons to my posts. I don’t want a block of buttons – in my case, all I want is to offer users a link they can click to get the page in a Readability view. 

For readers Readability offers the bookmarklets I mentioned earlier. I wrapped the “Read Now” bookmarklet as a link for my purpose (as I’ll show in a bit). 

Instapaper too gives bookmarklets for readers – the “Instapaper Text” bookmarklet one is what I am interested in. For publishers Instapaper gives an URL that will add the page to the reader’s Instapaper queue. Unfortunately, there’s no similar URL to simply show the page in an Instapaper view without adding to queue. 

Pocket too gives bookmarklets and tools for publishers. However, both options only allow the page to be added to the Pocket queue, there’s no way to just get a Pocket view display of the page. 

So Readability and Instapaper are what I can use. I added the following text to each of my posts (I use the Atahualpa theme so it was just a matter of adding this text to the “Byline” section of each post and applying some formatting):

All this does is that it wraps the Javascript code from the Readability Read Now and the Instapaper Text bookmarklets within an a block like thus:

When a user clicks the text the JavaScript is executed as though they had clicked on the bookmarklet. (Hat tip to this page where I picked up the syntax from. I haven’t programmed with JavaScript so had to search around for how to invoke JavaScript from a link). 

Hope this helps someone! I have put links to both Instapaper and Readability because I prefer Instapaper but it is lousy with code blocks while Readability handles code blocks better. I feel Instapaper is better for text – it has more fonts, background colors, etc.

WordPress post formats

Today I learnt of WordPress post formats. They are useful if you want to have a blog of links for instance, wherein the title of the post will be the link you are referring to and the content is some blurb about the post.

There are many post formats but the formats you can actually use depend on theme you have. Not all themes support asides; here is a list of themes that do. You can also search for themes that support post formats by doing a feature filter for “Post Formats”:


Mind you though, not all themes support all the post formats so it’s important to do a preview to see if the formats you want are supported.

Once you install a theme that supports post formats the supported formats will appear when you compose a new post:


I was confused initially on how to make an “aside” post. This is the type of post you need for a link blog as above. After a bit of trial and error I realized what I have to do is (a) set the post type to “Aside”, (b) Leave the title blank, and (c) have the first entry of the post be a link. Like this:


Google Authorship

Noticed that the JetPack 2.5 plugin for WordPress now adds Google Authorship to WordPress posts. Interesting, but what is Google Authorship?

Turns out Google Authorship is the cool stuff that highlights your post in Google search results like this:


That is neat, indeed. You need a Google+ profile for this to work, and must associate your blog with Google+ and vice versa. Pretty straightforward.

In the process I also discovered Google’s Structured Data Testing tool. Structured data is a way of marking up data in terms of what it is. For instance: while HTML will markup this post with heading and paragraph tags, there’s no way for Google to know what the post title is, what the body is, and so on. That’s where structured data comes in. Using a standard format I can markup this post specifying what each of its elements is, and that way Google has a better understanding of the post and can use it when showing excerpts etc (as in the screenshot above). You can read more about structured data and the supported markup languages here – the tl; dr version is that Google recommends a markup language called Microdata and that uses attributed in standard HTML tags to markup a post.

There are many WordPress plugins that do the marking up for you. I went with one called Itemprop WP – it seemed to be simple and no-frills. This plugin only adds markup to the single post views though, so on the home page view with all the posts together there is no markup. The Atahualpa theme lets me add additional HTML within a post block anyways, so for the main page I manually added the following code to the FOOTER: Homepage and FOOTER: Multi Post Pages sections:

I am using the <meta> tag as I don’t want my name visible to users. It’s just meta information for search engines.

Initial WordPress customizations (Part 1)

Moved this blog to a new host (A Small Orange) yesterday. The blog is now a WordPress self-hosted installation rather than WordPress multi-user/ network.

Installed the WP Super Cache plugin. This makes static versions of all your dynamic pages so there are no PHP/ database calls when users access your website. Each time someone visits a WordPress page typically there are 5 steps that happen behind the scenes. The WP Super Cache plugin eliminates 3 of these 5 steps.

I use the plugin with mod_rewrite so there are no PHP calls due to the plugin either. And I use all the recommended settings, so nothing new to learn here.

Couple of things to keep in mind about WP Super Cache.

  1. Each time you update a post the cache is rebuilt. (Not sure if that’s the default setting or not but I’ve set mine that way).
  2. You can specify a manual expiration time for pages – this way even if you don’t update the blog directly, but have widgets or RSS feeds that indirectly update the blog (but which don’t trigger a cache rebuilt as above) the cache will still be rebuilt every X number of seconds. There’s two things here – (1) you set the expiration time for the pages, and (2) you have to schedule a garbage collector who removes these expired pages and actually rebuilds the cache. So that’s two timers you have to specify. I have set both to a day in my case as this blog doesn’t have any dynamically updated widgets and such.
  3. If you make changes to the theme be sure to delete the cache. As theme changes don’t count towards an update, the cache won’t be rebuilt (unless you have very low expiration and garbage collection timers). So best to manually delete the cache.

WP Super Cache is also helpful in that it will compress the pages for you. This is disabled by default, but I enabled it. It doesn’t seem to compress everything though – stuff like JavaScript etc – so to take care of these I use mod_deflate in my .htaccess file. This is pretty straightforward, and if you are lazy (like me) you can even enable it via A Small Orange’s cPanel.

Google’s PageSpeed Insights and Yahoo’s YSlow are useful browser extensions to quickly identify where a page is slow. In my case they pointed me to minify which seems to be about removing all the whitespace in your CSS and JavaScript files and combining these into one – effectively reducing the number of file requests a browser has to make to the server, and also reducing the size of the files by removing whitespace. Neat idea, actually! There are many WordPress plugins that do this – I went with WP Minify. The other minify plugins made the admin bar of WordPress disappear and so I was concerned if they are messing up anything else.

I had to make one change with WP Minify. Namely, get it to place the minified JavaScript at the bottom of the page. Without this I could see PageSpeed complain of some files missing, so I figured it be a timing issue and tried with the JavaScript in the footer. That worked!

WP Minify is cool in that it also minifies HTML.

I will probably disable WP Minify later on though, as I am in the process of switching over this blog to CloudFlare. Amongst other things CloudFlare also minifies your HTML, CSS, and JavaScript.

There’s some more stuff I am in the midst of doing (setting expiry times for couple of static elements). I’ll make note of these in another post.