Fixes handle()-related strict warnings such as "Strict Standards:
Declaration of AdminPanelAction::handle() should be compatible with
Action::handle()"
Ref. #190
I used this hacky sed-command (run it from your GNU Social root, or change the first grep's path to where it actually lies) to do a rough fix on all ::staticGet calls and rename them to ::getKV
sed -i -s -e '/DataObject::staticGet/I!s/::staticGet/::getKV/Ig' $(grep -R ::staticGet `pwd`/* | grep -v -e '^extlib' | grep -v DataObject:: |grep -v "function staticGet"|cut -d: -f1 |sort |uniq)
If you're applying this, remember to change the Managed_DataObject and Memcached_DataObject function definitions of staticGet to getKV!
This might of course take some getting used to, or modification fo StatusNet plugins, but the result is that all the static calls (to staticGet) are now properly made without breaking PHP Strict Standards. Standards are there to be followed (and they caused some very bad confusion when used with get_called_class)
Reasonably any plugin or code that tests for the definition of 'GNUSOCIAL' or similar will take this change into consideration.
like leprous boils in our code. So, I've replaced all of them with //
comments instead. It's a massive, meaningless, and potentially buggy
change -- great one for the middle of a release cycle, eh?
The Net::OpenID::Server perl module that LJ uses appears to be very picky about input, and rejects most request types unless the data comes in as GET parameters (apparently following OpenID 1.1 rules, rather than OpenID 2.0 rules which permit any request to be POSTed but requires that if so, the data must all be in the POST body).
Apparently something got updated on LJ at some point that's either added that behavior or (more likely) added the OpenID 2.0 namespace info to discovery, which tells the Janrain-based OpenID libraries that they should go ahead and do POST requests instead of redirects to GET requests... thus breaking everything. ;)
GET should be just fine for both 1.1 and 2.0 though, and also saves having to sit through that lame autosubmit page.
Switched the authentication submission from checking whether it should redirect to GET or do a form POST, to simply always doing the redirect to GET.
Tested against providers:
* LiveJournal
* Google
* LaunchPad
* identi.ca
To enable the admin panel:
$config['admin']['panels'][] = 'openid';
Or to set them manually:
$config['openid']['trusted_provider'] = 'https://login.ubuntu.net/';
$config['openid']['required_team'] = 'my-project-cabal';
$config['site']['openidonly'] = true;
OpenID-only mode can still be set from addPlugin() parameters as well for backwards compatibility.
Note: if it's set there, that value will override the setting from the database or config.php.
Note that team restrictions are only really meaningful if a trusted provider is set; otherwise,
any OpenID server could report back that users are members of the given team.
Restrictions are checked only at OpenID authentication time and will not kick off people currently
with a session open; existing remembered logins may also survive these changes.
Using code for Launchpad team support provided by Canonical under AGPLv3, pulled from r27 of
WordPress teams integration plugin:
https://code.edge.launchpad.net/~canonical-isd-hackers/wordpress-teams-integration/trunk
* throwing in our spinner
* cleanup of texts
* "If this doesn't go through click the button" instead of just a mystery button
* slightly faster submission: immediate at end of page rather than waiting for jQuery to confirm document setup completion
- avoid notice spew when checking sreg items that weren't provided
- fix keys spec for user_openid, clears up problems with removing openid associations
- fix keys spec for user_openid_trustroot
Since core JS loads were moved to the bottom, the JavaScript was being run before jQuery was loaded, so the onload event never got set. Moved it down to the scripts section.
Added 4 new events involved in XRDS: StartUserXRDS, EndUserXRDS, StartPublicXRDS, EndPublicXRDS
Added OpenID provider functionality (no delegation support [yet])
As a first step to pluginizing our OpenID support, I've moved the
important OpenID-related files to a dedicated plugin directory. Many
of these classes are still referred to by libraries that are still in
core.