Headache of the moment: SSO
Okay so earlier in the week I decided to try and implement a single-sign-on (SSO) system for the platform at That Website Guy.
SSO is when you log in on one site (say thatwebsiteguy.net), and when you then click through to your site on the platform from your account dashboard you’ll still be logged in. This would also work in reverse, if you signed in to your website’s admin dashboard and then clicked through to go to thatwebsiteguy.net to manage your site subscription or whatever, your session would carry over without the need to log in again with the same details.
Before, whenever I’d tried to implement it I’d never been able to actually get it to work, so the flow was to sign in on thatwebsiteguy.net > click through to your site’s admin panel > sign in again, or sign in on your site > click through to manage your site’s subscription on thatwebsiteguy.net > sign in again. Administering the network creates an even bigger headache with this flow, as whenever I needed to manually make changes to each site on the network I’d need to sign in over and over and over again. With Google’s NoCAPTCHA on the login pages this quickly becomes pretty annoying.
Which brings me to now. I got fed up with the CAPTCHA, and rather than disabling it and lowering the security of the network for my own convenience, I decided to take another look into SSO. To my utter amazement it seemed to work – for the most part at least.
There still seems to be some details that need ironing out – like https-to-http sessions not working, and potential redirect loops on some sites which I think might be caused by caching, but I’ll keep working to figure out fixes. Aside from all that I’m chuffed with the breakthrough in progress, and I’ll update this post with any new developments.
UPDATE 27/3/18:
Okay so I thought I fixed a redirect loop issue that sometimes occurred when you visit a new site after logging in which seems to be related to the performance app serving a cached version of the page where you’re still logged out – triggering the auto-login which refreshes the page and serves you the same logged-out page from cache. Evidently not.
The fix was to add /dm-sso-endpoint/(.*) to the performance app’s “Never Cache (URLs)” setting, and at first I thought it worked for the issue.
For my own reference I’m disabling the Cross-domain asynchronous login to see if that has any effect. 🤞
UPDATE 27/3/18:
That definitely didn’t work, and created an even more obvious redirect loop that totally blocked access until site cache was cleared so I’ve re-enabled asynchronous login.