Google appliance unable to index pages after 1.17.0 upgrade

Jump to: navigation, search

About a month ago, I upgraded one of our MW 1.13.3 installations to MW 1.17.0. I've gotten through most of the issues except one huge one. This wiki is indexed ... err, was indexed ... by our Google appliance before the upgrade. Since the upgrade, the Google appliance cannot authenticate pages to index them. I applied the fix for Bugzilla 30275, but there was no change.

Both the wiki and the Google appliance are on an intranet, behind a firewall, not accessible from the internet.

Pages on the wiki are protected against reading unless the user is logged in.

Julie C.19:18, 13 January 2012

We are still having this issue. I've tried changing every variable introduced since 1.13.0 that looked like it could possibly have an effect. I have been actively trying to disable some of the cross-site hacking code, as if someone gets through the firewall, we've got bigger issues than wiki-spam to contend with.

Julie C.19:15, 6 February 2012
 

The log in process changed between 1.13 and 1.17 (specificly in 1.15.3). Your google appliance thing probably needs to be updated. See bugzilla:23076 for the technical details of the change.

Bawolff07:25, 7 February 2012

Yes, this is the change I have been trying to undo. I will try harder. In the meanwhile, I'll see if the GSA administrator can get an upgrade. He previous said he couldn't, that it would be a customization that would cost big money AND get zapped by the next regular GSA upgrade.

Julie C.15:10, 7 February 2012

Note, the change in the login process was for security reasons - it wasn't changed just for the heck of it.


The new login process is quite similar to the old process, the only difference is one has to pass the wpToken value in as well.

Bawolff15:48, 7 February 2012

We have a special case ... this is an intranet wiki behind a firewall. If hackers get inside the firewall, we've got bigger problems than just keeping our own sales guys from giving confidential R&D information to customers. ;) The security risk is acceptable.

Julie C.18:26, 7 February 2012

Well then the easy solution is to not have read rights restricted to logged in users.

Bawolff22:30, 7 February 2012

Unless that is a requirement. Which it is.

Julie C.22:09, 9 February 2012
 
 
 

I successfully hacked it, yay! Of course, the hack isn't getting our other bots that tie our miscellaneous data sources together working, but at least GSA is happy again.

Big huge caveat on this: I've mentioned that this is on an intranet wiki, inaccessible from the regular internet. Implementing this will leave your wiki vulnerable to attack. This works for me, this may or may not work for you.

In ../includes/templates, comment out the line that adds the hidden form field wpCreateaccounttoken".

In ../includes/api/ApiLogin.php, have the case for LoginForm::NEED_TOKEN take the same path as LoginForm::SUCCESS, comment out the original NEED_TOKEN code.

In ../includes/specials/SpecialUserlogin.php, do the same switch statement case swap that was done in ApiLogin.php.

Julie C.22:08, 9 February 2012
 
 
 
Personal tools

Variants
Actions
Navigation
Support
Download
Development
Communication
Toolbox