0000465: OpenID uncaught exception when trying to save OpenID with https (TLS)

Notes
(0000734) macgirvin (administrator) 2012-08-06 15:54	Most OpenID servers force https - and I've been using it fine with https, so something else is going on. I believe it fell back to http when it couldn't get a satisfactory response using https. Then if it couldn't get a satisfactory response with http, it gave up. When you save the entry we do try and validate the server (we had lots of people putting in garbage that didn't know what openid was) and this check is likely failing for an obscure reason. This will likely require a bit of protocol tracing to find out what is happening during discovery on your openid server. I know for instance that the LightOpenID library seems to be particularly sensitive to the content-type served up and if it tries to use discovery and retrieves an xml file, it better darn well be marked application/xml or it fails.

(0000737) ross (reporter) 2012-08-07 08:56	The weird thing about this failure is that it is not global to the site. It only happens on the edit page. If a user never entered a password but use the same provider for their openID then it works without issue. So whatever the validation problem it's explicitly with whatever gets called on the edit page.

(0000738) dkg (reporter) 2012-08-10 14:49	I find i can make the problem go away by setting up an HTTP 302 redirect from http://id.mayfirst.org [^] to https://id.mayfirst.org [^] (previously, the IP address at id.mayfirst.org did not answer at all on port 80). This implies that friendica is indeed trying the http:// version of the URL first, rather than trying the https:// version. This is a security vulnerability, since it would allow an attacker in control of the network to impersonate the cleartext version of the URL. Once i enabled that HTTP 302 redirect and saved my settings page, my row in the user table had the .openidserver field set to https://id.mayfirst.org/openid/provider [^] (it had been the empty string before). And now that the .openidserver field is set explicitly, i can still change my settings, even if the HTTP 302 redirect is gone (i've removed the redirect for now, since it shouldn't be necessary). So the presence of a legitimate URL in the openidserver field appears to be related here. Of possible historical relevance: I created this account by initially logging in via OpenID; i have never used the account with a password. So, some open questions: * Why wasn't user.openidserver populated initially? * Why is the protocol scheme part of the OpenID URL stripped from user.openid? * What happens if the openid provider metadata fetched the base OpenID URL changes, but user.openidserver remains the same? will the authentication remain under control of the original URL referenced by openidserver? if so, that doesn't seem good.

(0000745) v6ak (reporter) 2012-09-03 14:28	It seems that https is ignored: include/text.php: function normalise_openid($s) { return trim(str_replace(array('http://','https://' [^]),array('',''),$s),'/'); }

Issue History
Date Modified	Username	Field	Change
2012-08-06 09:15	nat	New Issue
2012-08-06 15:54	macgirvin	Note Added: 0000734
2012-08-07 08:56	ross	Note Added: 0000737
2012-08-10 14:49	dkg	Note Added: 0000738
2012-09-03 14:24	v6ak	Issue Monitored: v6ak
2012-09-03 14:28	v6ak	Note Added: 0000745

Relationships