3 ms·
That's fairly easy to fix by putting your users on user.fooapp.com and your corporate pages on *.foo.com, just like you're already (for a different reason) putt
by mseebach 10y ago
That's fairly easy to fix by putting your users on user.fooapp.com and your corporate pages on *.foo.com, just like you're already (for a different reason) putting static resources on foo-static.com.
- mieko 10y agoI think a plumbing-level security implementation detail should be a little less intrusive than having to move either the corporate domain or millions of user's addresses. I can't imagine Tumblr rolling out HPKP now with this workaround (though github did do the .com -> .io thing, so who knows). The spec should've just included excludeSubDomains=
- mseebach 10y agoFor security, especially at the plumbing-level, simplicity is a virtue.
- nsgi 10y agoThis. It's already best practice because fooapp.com should be on the public suffix list (which allows Let's Encrypt to be used with subdomains, among other things).
- mieko 10y agoThere's still a decent size contingent of non-technical people that look at exampleapp.com the way I'd look at wellsfargo-online-banking.com. I don't blame them: subdomains imply authority. While I'm sure there's more, github.io, herokuapp and GAE/Appspot are the only services I know of following this practice, and they cater to a developer-level technical audience with the assumption that they'll work out a better name.