Josh Eby

Thank you! Glad it is working well for you!

So after looking into this, I have “Network: True” set in the plugin header which makes it so it can only be enabled at the network level. So if you don’t network activate it and go to the plugins page on sub-site, there is no option to activate and it says Network Only.

Sorry for the delay in response. I have seen the same issue. My workaround right now is to disable the plugin before adding it to ManageWP. Once it has been added, you can turn it back on and everything continues to work fine. My plan is to figure out how to not filter the users when a request from ManageWP comes in, but I have not had time to investigate it yet.

Well it was intended to be network activated, but to be honest I have never tested activating it on a single site as part of a multisite install.

I suspect it may work and only enable the functionality on that single site. I will try to test that out as you have me wondering now…

Thank you! Glad someone else found it useful!

Sounds good! The only reason I ever started trying to figure it out was that I have one site that does display https on the site info tab. Not sure how that one got that way and the rest didn’t. Only thing I can think of is that I think that site has been https from the start and the others were converted to https.

Thanks for your help.

I used the following for search and replace.
https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

The siteurl and home in the options tables and sitemeta table are all https and correct. The only place I still see http is on the site info tab under the network admin.

https://goo.gl/JkMkp3

OK, so I have figured out that WP stored the roles/capabilities in the wp_options table. So what is the recommended method for modifying roles/capabilities with a plugin? Activate and Deactivate? I am guessing it would be considered bad practice to have this running on admin_init considering it doesn’t need to run every page load…

Thoughts???

It looks like ‘edit_pages’ does exactly what I wanted. It allows them to access the pages menu and edit pages that they are the author of. Also allows them to create new pages, but they have to be reviewed and approved by an editor which is a bonus.

Thank you!

Yeah the entire dashboard and login process happens on the unmapped domain so then I should be all set.

Thank you for your help!

Well, the good news is I think I got it working. I was changing the domain on the $current_site object as well as the $current_blog object. I noticed in the original sunrise.php it was not being changed for the $current_site object. Removed that line and remote logins appear to be working. Going to do some more testing, but things look promising.

The remote login appears to happen when the redirect occurs when you go to the front-end from the admin area based on my testing.

I am still interested to know if there is anything to worry about by performing the remote login on the non-SSL side of things. I have found a few articles regarding how the authentication cookies work and I think it should be fine, or at least no worse than things are with a default install.

My reason for attempting this is so that I can force SSL for Admin/Login using a wildcard SSL on the original sub-domain address… (i.e. example.network.com) and then have the front-end served from standard HTTP on the mapped domain (i.e. example.com).

Now that I understand a bit more about how this works, would I essentially be removing any security I added using the SSL on the original domain by authenticating them on the non-SSL mapped domain as well?

Their login would have happened over SSL, but this process will set the auth cookies on the non-SSL domain as well which means those cookies would be getting sent to the server unsecured. This would prevent someone from grabbing the username and password, but not necessarily the keys in the cookies.

I think I can reverse engineer the remote login to work the other direction, meaning that the initial login happens at the original domain and them remote login makes the authentication happen on the mapped domain, but am just curious if I am going to be defeating the purpose of using SSL in the first place.

My initial thoughts are that it is no different than a typical WordPress site when they only enforce SSL on the admin side. They are still logged in on the front-end, just over HTTP. So maybe it isn’t a big issue.

I am not 100% familiar with the exact way WordPress uses the cookies to maintain authentication so I am hoping to get some insight from others with more experience.

Thank you in advance for your help.

The login page is being displayed using the original domain right now. Is the intent to login from the mapped domain and then it logs you into the original domain in the background?

Well support logged in and fixed it, but didn’t tell me what they did. So I asked… I am thinking it was an issue with the menu setup in the admin side of things.

Anyways… thank you to everyone for their time and help!

After a bit more looking, it appears the issue only may be if you are logged in. If I log out and then refresh the page the menus are correct. This is not the case however with just the parent theme active.

I will wait and see what I get from support.