]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/plugins/openid/troubleshooting.mdwn
Merge remote-tracking branch 'smcv/ready/limit'
[git.ikiwiki.info.git] / doc / plugins / openid / troubleshooting.mdwn
index c59f7346ab5c5e857b3c238dcd35aa8db40711bf..12cd9bedbdef5a0f30f8f3e9638c573a6dc0f32f 100644 (file)
@@ -1,6 +1,6 @@
 **TL;DR**
 
-[[!toc levels=3]]
+[[!toc levels=4]]
 
 # An odyssey through lots of things that have to be right before OpenID works
 
@@ -56,6 +56,68 @@ unlikely-to-be-blacklisted value is; if there is one, it's probably the
 next one all the rude bots will be using anyway, and some goofy provider
 like mine will blacklist it.
 
+> If your shared hosting provider is going to randomly break functionality,
+> I would suggest "voting with your wallet" and taking your business to
+> one that does not.
+>
+> In principle we could set the default UA (if `$config{useragent}` is
+> unspecified) to `IkiWiki/3.20140915`, or `IkiWiki/3.20140915 libwww-perl/6.03`
+> (which would be the "most correct" option AIUI), or some such.
+> That might work, or might get randomly blacklisted too, depending on the
+> whims of shared hosting providers. If you can't trust your provider to
+> behave helpfully then there isn't much we can do about it.
+>
+> Blocking requests according to UA seems fundamentally flawed, since
+> I'm fairly sure no hosting provider can afford to blacklist UAs that
+> claim to be, for instance, Firefox or Chrome. I wouldn't want
+> to patch IkiWiki to claim to be an interactive browser by default,
+> but malicious script authors will have no such qualms, so I would
+> argue that your provider's strategy is already doomed... --[[smcv]]
+
+>> I agree, and I'll ask them to fix it (and probably refer them to this page).
+>> One reason they still have my business is that their customer service has
+>> been notably good; I always get a response from a human on the first try,
+>> and on the first or second try from a human who understands what I'm saying
+>> and is able to fix it. With a few exceptions over the years. I've dealt with organizations not like that....
+>>
+>> But I included the note here because I'm sure if _they're_ doing it, there's
+>> probably some nonzero number of other hosting providers where it's also
+>> happening, so a person setting up OpenID and being baffled by this failure
+>> needs to know to check for it. Also, while the world of user-agent strings
+>> can't have anything but relatively luckier and unluckier choices, maybe
+>> `libwww/perl` is an especially unlucky one?
+
+>>> Yippee! _My_ provider found their offending `mod_security` rule and took it out,
+>>> so now [ikiwiki.info](/) accepts my OpenID. I'm still not sure it wouldn't be
+>>> worthwhile to change the useragent default.... -- Chap
+
+#### culprit was an Atomicorp ModSecurity rule
+
+Further followup: my provider is using [ModSecurity](https://www.modsecurity.org/)
+with a ruleset commercially supplied by [Atomicorp](https://www.atomicorp.com/products/modsecurity.html),
+which seems to be where this rule came from. They've turned the rule off for _my account_.
+I followed up on my ticket with them, suggesting they at least think about turning it off
+more systemwide (without waiting for other customers to have bizarre problems that are
+hard to troubleshoot), or opening a conversation with Atomicorp about whether such a rule
+is really a good idea. Of course, while they were very responsive about turning it off
+_for me_, it's much iffier whether they'll take my advice any farther than that.
+
+So, this may crop up for anybody with a provider that uses Atomicorp ModSecurity rules.
+
+The ruleset produces a log message saying "turn this rule off if you use libwww-perl", which
+just goes to show whoever wrote that message wasn't thinking about what breaks what. It would
+have to be "turn this rule off if any of _your_ customers might ever need to use or depend on
+an app or service _hosted anywhere else_ that _could_ have been implemented using libwww-perl,
+over which you and your customer have no knowledge or control."
+
+Sigh. -- Chap
+
+> Thanks for the pointer. It seems the open-source ruleset blacklists libwww-perl by default
+> too... this seems very misguided but whatever. I've changed our default User-Agent to
+> `ikiwiki/3.20141012` (or whatever the version is). If we get further UA-blacklisting
+> problems I'm very tempted to go for `Mozilla/5.0 (but not really)` as the
+> next try. --[[smcv]]
+
 ## Error: OpenID failure: naive_verify_failed_network: Could not contact ID provider to verify response.
 
 Again, this could have various causes. It was helpful to bump the debug level
@@ -103,6 +165,15 @@ Unfortunately, there isn't a release in CPAN yet that includes those two
 commits, but they are only a few lines to edit into your own locally-installed
 module.
 
+> To be clear, these are patches to [[!cpan LWPx::ParanoidAgent]].
+> Debian's `liblwpx-paranoidagent-perl (>= 1.10-3)` appears to
+> have those two patches. --[[smcv]]
+>
+> Irrelevant to this ikiwiki instance, perhaps relevant to others:
+> I've added these patches to [pkgsrc](http://www.pkgsrc.org)'s
+> [[!pkgsrc www/p5-LWPx-ParanoidAgent]] and they'll be included in the
+> soon-to-be-cut 2014Q3 branch. --[[schmonz]]
+
 ## Still naive_verify_failed_network, new improved reason
 
     500 Can't connect to indieauth.com:443 (SSL connect attempt failed
@@ -136,6 +207,19 @@ not be used by `IO::Socket::SSL` unless it is
 
 Then a recent `Net::SSLeay` perl module needs to be built and linked against it.
 
+> I would tend to be somewhat concerned about the update status and security
+> of a shared hosting platform that is still on an OpenSSL major version from
+> pre-2010 - it might be fine, because it might be RHEL or some similarly
+> change-averse distribution backporting security fixes to ye olde branch,
+> but equally it might be as bad as it seems at first glance.
+> "Let the buyer beware", I think... --[[smcv]]
+
+>> As far as I can tell, this particular provider _is_ on Red Hat (EL 5).
+>> I can't conclusively tell because I'm in what appears to be a CloudLinux container when I'm in,
+>> and certain parts of the environment (like `rpm`) I can't see. But everything
+>> I _can_ see is like several RHEL5 boxen I know and love.
+
+
 ### Local OpenSSL installation will need certs to trust
 
 Bear in mind that the OpenSSL distribution doesn't come with a collection
@@ -164,6 +248,11 @@ That was fixed in `LWPx::ParanoidAgent` with
 which needs to be backported by hand if it hasn't made it into a CPAN release
 yet.
 
+> Also in Debian's `liblwpx-paranoidagent-perl (>= 1.10-3)`, for the record.
+> --[[smcv]]
+>
+> And now in pkgsrc's `www/p5-LWPx-ParanoidAgent`, FWIW. --[[schmonz]]
+
 Only that still doesn't end the story, because that hand didn't know what
 [this hand](https://github.com/noxxi/p5-io-socket-ssl/commit/4f83a3cd85458bd2141f0a9f22f787174d51d587#diff-1)
 was doing. What good is passing the name in
@@ -187,6 +276,18 @@ server name for SNI:
 
 ... not submitted upstream yet, so needs to be applied by hand.
 
+> I've [reported this to Debian](https://bugs.debian.org/761635)
+> (which is where ikiwiki.info's supporting packages come from).
+> Please report it upstream too, if the Debian maintainer doesn't
+> get there first. --[[smcv]]
+> 
+> Applied in pkgsrc. I haven't attempted to conduct before-and-after
+> test odysseys, but here's hoping your travails save others some
+> time and effort. --[[schmonz]]
+
+> Reported upstream as [LWPx-ParanoidAgent#14](https://github.com/csirtgadgets/LWPx-ParanoidAgent/issues/14)
+> _and_ [IO-Socket-SSL#16](https://github.com/noxxi/p5-io-socket-ssl/issues/16). -- Chap
+
 # Success!!
 
 And with that, ladies and gents, I got my first successful OpenID login!