Hi,
I’ve gotten Shibbolize to sort of work.
If I try and login to a site like:
site.machine.domain.tld
I get sent to my IDP, and then back to my SP, but to the wrong site:
machine.domain.tld
Of course I can switch to any of the sites associated with this WordPress MU site, but this could be potentially confusing to users. How would I investigate what is happening, and correct it?
]]>Hi,
Just wondering people’s experiences with this plugin with WordPress multisite, v3.9.1. Any issues?
Also, is this plugin still being actively supported?
Thanks,
Dan
]]>I have the plugin installed and configured.
When I go to wp-login, I can select Shibboleth and authenticate.
My user is created in wordpress (I know this by inspecting it by logging in with the native admin user).
The problem is that when I login, it simply takes me back to the wp-login page. I can see the Shib session is active; The user is created from the HEADER variables, yet wordpress does not regcognize the user when I try to browse to wp-admin. Instead it takes me to the login page.
I don’t understand why I can’t access wp-admin.
I have the global setting ‘allow users to register’ off and I also do not have ‘use shibboleth for default login’ option enabled.
I have tested this on a couple of different instances, with no luck. I can see the user created after authentication, the Shibboleth session is active but the user session is not recognized by WordPress.
A few more details on my setup:
Debian 8.0(Jessie) with the following packages:
wordpress 3.9.1+dfsg-1
libapache2-mod-shib2 2.5.3+dfsg-1+b1
php5 5.6.0~b5+dfsg-4
mysql 5.5.37-1
apache 2.4.9-2
I also found this error in my Apache logs which I assume has to be related (site obfuscated). It looks like a shib hook/action failing, which I assume must be where wordpress is failing. Could this be a SQL syntax bug?
]]>[Wed Jul 02 11:12:57.825900 2014] [:error] [pid 23338] [client 99.234.122.9:55501] WordPress database error Table ‘wordpress.wp_blogs’ doesn’t exist for query SELECT blog_id AS id, CONCAT(domain, path) AS site FROM wp_blogs made by wp_signon, wp_authenticate, apply_filters(‘authenticate’), call_user_func_array, shibboleth_authenticate, shibboleth_authenticate_user, shibboleth_get_user_roles, shibboleth_get_sites, W3_Db->query, W3_DbCache->query, W3_DbCallUnderlying->query, W3_Db->query, W3_DbProcessor->query, W3_Db->default_query
Regarding the following code:
function shibboleth_session_active()
{
return apply_filters('shibboleth_session_active', isset($_SERVER['Shib-Session-ID']));
}This fails on our fcgid-based PHP infrastructure. What we have found is that the name is changed at some point between mod_shib and WordPress and so it requires $_SERVER['Shib_Session_ID'] instead.
This breaks standard mod_php setups, though, so I believe shibboleth_session_active() will need to be aware of both and grab whichever one happens to be populated.
]]>Our environment does not support short tags, which are used in the following lines in options-admin.php:
<td><input type=”text” id=”shibboleth_superadmin_header” name=”shibboleth_superadmin[header]” value=”<?= $shib_super_admin[‘header’] ?>” style=”width: 100%” /></td>
<td><input type=”text” id=”shibboleth_superadmin_value” name=”shibboleth_superadmin[value]” value=”<?= $shib_super_admin[‘value’] ?>” style=”width: 100%” /></td>
<div class=”header”><h3>Site: <?=$site->site?></h3></div>
As “<?=” is a shortcut for “<?php echo” this can easily be fix to support any generic php installation by updating the lines to the following:
<td><input type=”text” id=”shibboleth_superadmin_header” name=”shibboleth_superadmin[header]” value=”<?php echo $shib_super_admin[‘header’] ?>” style=”width: 100%” /></td>
<td><input type=”text” id=”shibboleth_superadmin_value” name=”shibboleth_superadmin[value]” value=”<?php echo $shib_super_admin[‘value’] ?>” style=”width: 100%” /></td>
<div class=”header”><h3>Site: <?php echo $site->site?></h3></div>
More info: https://www.php.net/manual/en/ini.core.php#ini.short-open-tag
]]>When users log out, the are automatically taken to the wp-login.php page. It would be great if they were redirected to the home page instead. A bigger issue is that the “Lost your password?” link doesn’t redirect them to the link I entered in Shibbolize. This is a multisite installation. My guess is that it’s a compatibility issue with 3.6.
]]>First of all, thanks for a rock-solid plugin! It’s very clean, simple, and works great for network sites.
Second, I’d like to make a feature request. While automatic user creation is awesome for sites that need it, I don’t like the prospect of letting unauthorized users sign in to my sites, even if it just creates a subscriber account. This is for use in education, so the only users I want being able to log in are those instructors or students who I’ve explicitly added.
You already have a checkbox for whether or not SSO logins will be synchronized with existing accounts. What about making another checkbox to also deny automatic account creation? I think a good implementation might be to let the user authenticate with their SSO credentials, but then show them a (customizable?) message that lets them know they’re not allowed to login to the backend. Then they could be automatically redirected to the front page (or some other customizable location).
The above suggestion assumes that no group membership information is being provided with the SSO session. Of course, if there is group membership info, we’d want to streamline things by allowing automatic account creation. But what about users who shouldn’t have access based on their group (i.e. site is public, but login is restricted to faculty, so students should be denied login)? I’d still like to see them denied login access and redirected to the front page. Maybe a better function for the checkbox would be “Deny automatic creation of unauthorized users.”
This is certainly not a requirement of this plugin, but from a user management standpoint, it’s gravy.
Thanks again!
]]>