Login from GC music room booking page redirects to failed admin dashboard
Privacy Setting = whole site only available to registered users of the Commons ( "I would like my blog to be visible only to registered users of the CUNY Academic Commons")
Issue: When Commons users visit http://musicroombooking.commons.gc.cuny.edu/ when not logged in, and attempt to login from the page presented to them, the website redirects to the dashboard immediately after login, rather than http://musicroombooking.commons.gc.cuny.edu/ .
Because most of the users of the site are not admins, it is giving them the following error: "You attempted to access the "GC Music Program Room Booking Website" dashboard, but you do not currently have privileges on this site. If you believe you should be able to access the "GC Music Program Room Booking Website" dashboard, please contact your network administrator."
Prior to Wednesday, August 13th, users were properly redirected after login to the homepage - http://musicroombooking.commons.gc.cuny.edu/ .
Since the issue was reported, I have tested it on multiple non-admin accounts, and the error is consistently occurring.
I have marked the priority of this ticket as "high" because students have been complaining to the music office that the site is "not working".
Please let me know if you need any additional details to resolve this.
#2 Updated by Boone Gorges almost 8 years ago
- Priority name changed from High to Normal
- Target version set to 1.7
I have put a hotfix into place for this: https://github.com/cuny-academic-commons/cac/commit/0de2e08f706cb9052e7b17dbdedf4660e08e5cd9 Norma, it should now be working as expected - please let me know if it's not. I'm downgrading the priority, on the assumption that the current fix is good enough for the time being (and what I'm about to request of Dan is lower priority).
Dan, I'm reassigning this ticket to you. As you can see, I've made the modification by editing this plugin directly. We've basically forked the plugin, as it's loaded out of mu-plugins, so it's not a huge deal. But I would like to avoid this to the extent that it's possible. Could I ask you to look into the following changes:
1. Figure out a way to do this filtering that doesn't require hardcoding it right into the plugin. You should be able to filter the 'redirect_to' hook, but the question is how to invoke 'add_filter' discriminately. Maybe you can hook to 'muplugins_loaded' (to ensure that MPO has had a chance to load), then reproduce some of the logic at the bottom of ds_wp3_private_blog.php to decide whether to add_filter()
2. The logic I've put in place will build a redirect URL that is based on the originally requested URL. You could make this a bit more elegant by checking to make sure that the user has a decent reason to be going into the Dashboard (eg current_user_can( 'edit_posts' )) before allowing them to go into wp-admin. Not critical, but something to think about.
#4 Updated by Naomi Barrettara almost 8 years ago
Yes, big HUGE thanks to Boone for doing this so quickly!
I tested logging in myself, and even though I am an admin, it is no longer taking me straight to the dashboard - it is successfully taking me from login to the homepage, so I believe it will work properly for non-admin users as well. I will get a non-admin to test this and report back if any problems occur.
#7 Updated by Daniel Jones over 7 years ago
So I've been hacking away at this for a little while now and I think I'm ready to ask for help!
Here's what I've figured out so far:
-The More Privacy Options plugin is using the template_redirect action hook to redirect people, so if we want to override that behavior we'll have to jump it in line with a high priority call to add_action
-However, the functions it hooks into template_redirect all check to see if the user is logged in before they do anything, so I don't think this is what's causing the particular issue with redirects after signing in, because by the time template_redirect gets called wordpress should already be recognizing the user as signed in.
-Instead, it looks like we just need to use the login_redirect filter to override the default redirect behavior on login.
-This way, I think we can actually leave the MPO plugin alone - all its authenticators do is redirect to the login page. I poked around some in the WP core source, and it looks like using the login_redirect filter lets us change a hidden field in the login form called "redirect_to", which I would guess would give us the control we need.
Here's my problem:
For some reason I can't get my function hooked to the login_redirect filter, or any other filters for that matter. I've been trying to add them to the functions.php file in the bp_nelo theme, but no go - I've been testing by printing out $wp_filter['login_redirect'] right after the apply_filters call for login_redirect, and it prints out some other functions but not the one I tried to hook onto it. Any thoughts on why that might be?
Hope this is helpful. Once I figure out how to get hooked into the filter it should be easy to add the controls we want for different MPO settings and different user roles.
#8 Updated by Daniel Jones over 7 years ago
Or we could hook into template_redirect in front of MPOs hooks and use something similar to your hotfix, Boone. I've had the same problem hooking into template_redirect with add_action as login_redirect with add_filter though. Not even able to hook into muplugins_loaded.
#9 Updated by Boone Gorges over 7 years ago
Hey Dan - Your logic looks good at a glance. Let's go ahead with login_redirect.
Your hook issue sounds like it has to do with load order. The theme's functions.php loads after muplugins_loaded and plugins_loaded. For this kind of modification, I'd consider creating a file in wp-content/mu-plugins - these are loaded very early by WP.
#10 Updated by Daniel Jones over 7 years ago
Okay so I think I found a fix for this. I worked on a different branch and pushed these changes with the first time I pushed the branch, so I wasn't able to get a link to the commit but here's the file that I added - https://github.com/cuny-academic-commons/cac/blob/fix-login-redirect/wp-content/mu-plugins/cac-fix-login-redirect.php besides adding that file I changed the MPO file in the mu-plugins folder back to how it was before the hotfix.
It just checks to see if we're on the home blog or not so we don't mess with the My Commons redirecting, and if we aren't it tests the users permissions to decide where to send them. The one thing I had to do that probably isn't ideal is manually set the $current_user global based on the $user global, because only $user is set when the code runs, and I need $current_user to do my permissions check. I wasn't able to do a check of the caps associated with the $user global. If anyone can think of a better way to do this kind of check just let me know.
#11 Updated by Daniel Jones over 7 years ago
Oh wait here's the link to the changeset - https://github.com/cuny-academic-commons/cac/commit/49db4bc7934e889c3e1a8e7d35cdbc10baf169ea