Users logged out on front end (mapped domain) while logged in on admin (original domain)

Hi,

I have set the Domain Mapping options:
- Administration mapping: original domain
- Login mapping: original domain
- Cross-domain autologin: Yes

Now, when a logged out user goes to his site and tries to connect via http://mapped.dom/wp-admin/ he will get redirected to http://site.original.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F which is as expected but the user cannot log in. He will get redirected to the same login! Is it because of that mapped domain in the redirect_to paramter?

Only when accessing via an initial request like http://site.original.dom/wp-admin/ (resulting in redirect_to with the original domain) it is be possible to actually log in.

But then, when visiting the front end again (to verify changes for example) the user appears to be logged out. No admin bar and no 'Edit' links...

I also noticed that when setting:
- Administration mapping: mapped domain
- Login mapping: original domain
it effectively becomes impossible to log in at all... It might be wise to not allow this combination of options.

  • RavanH

    Hi @Vinod Dalvi, thanks for taking this up :slight_smile:

    Yes, with login and admin both to mapped domain it works just fine. I see others encoutered the same issue like https://premium.wpmudev.org/forums/topic/cannot-login-redirects-back-of-login-page and maybe https://premium.wpmudev.org/forums/topic/cannot-login-to-admin-with-wwwdomainorg-site-special-case (unresolved) and https://premium.wpmudev.org/forums/topic/domain-mapping-and-login-question (unresolved?)... But...

    It's just that I have several reasons to prefer the original domain for both login and admin:

    1. if anything happens with a mapped domain (exiration or problems with DNS settings) the site owner would no longer be able to connect to his/her site admin.

    2. I use Social Login (plugin by OneAll) to allow users to log in with their gmail / live / yahoo account and this works best if all login action is happening via subdomains of the main network domain.

    Anyway, shall I create a test site with login so you can see what's happening? Can I send you account info via PM?

  • Vinod Dalvi

    Hi @RavanH,

    Thank you for your detailed reply.

    I will see if I can get the lead developer in here with his invaluable insight into this plugin for his advise for us.

    Please send me your admin credentials by following below steps.
    - Send an email using our secure contact form on https://premium.wpmudev.org/contact/
    - Select "I have a different question" from the dropdown
    - On the subject enter "Attn: Vinod Dalvi".
    - Include the URL of this post in your message so that I may track this issue better
    - Include a link to your website
    - Include your admin credentials (username + password)
    - Include FTP Details

    Kind Regards,
    Vinod Dalvi

  • Rone

    Also wanted to chime in and say I am having this same issue and have been for quite some time.

    @Vindod - Yep, all my users have that checked.

    I think it may to do with the cross-domain login feature not working properly.

    When logged in as the super admin, I can access the dashboards of all sites on the network without having to login again.

    However the admin bar does not show up when visiting the front-end site of any mapped domain, while logged in as super admin. My users also experience this same behavior.

    Interestingly (strangely), I can get the admin bar to show up on my mapped subsites, but it requires me to login to each of my sites at mapped-domain.com/admin

    After re-logging in there, the admin bar shows up on the mapped domain just fine. However, if cross domain login was functioning as I think was intended, these additional logins should not be necessary for me as the super -admin or any of my users who may be users of multiple mapped sites on my network to get the admin bar to show-up on the front end of any mapped domains.

    Note this current multiple-login requirement, also requires you to logout of each site as well. Instead of just logging out of one and being logged out of all sites.

    I've also been following this ticket, as that's my exact setup (wildcard SSL, domain mapping plugin configuration) as I think they may be related: https://premium.wpmudev.org/forums/topic/domain-mapping-cross-domain-login-with-https

  • Rone

    Just quick update on the info below. I just went in to reconfirm the behavior I was as experiencing (quoted below) just last week, but now I can't get the admin bar to show up at all on the front-end of mapped domains, regardless of logging in as super-admin to the network dashboard or logging into a mapped domain individually at mapped-domain.com/admin

    I think I may have updated to the latest version of Domain mapping this past Sunday, which may have caused the change in behavior described below.

    Hope that helps.

    When logged in as the super admin, I can access the dashboards of all sites on the network without having to login again.

    However the admin bar does not show up when visiting the front-end site of any mapped domain, while logged in as super admin. My users also experience this same behavior.

    Interestingly (strangely), I can get the admin bar to show up on my mapped subsites, but it requires me to login to each of my sites at mapped-domain.com/admin

    After re-logging in there, the admin bar shows up on the mapped domain just fine.

    ....

    Note this current multiple-login requirement, also requires you to logout of each site as well. Instead of just logging out of one and being logged out of all sites.

  • BryanMan

    Hi @RavanH and everyone here,

    I'm facing the same problem as well.

    I do not have the answer here on how to change what, but I know that this can be done because I went to wordpress.com and check it out.

    If i give you a hypothetical example, it wouldn't be fair - because it might just be my theory only.

    Therefore, I google it and found one example here.

    1) Goto http://hypeandgenius.com/

    2) Then goto http://hypeandgenius.com/wp-admin

    Here you'll be redirected to this URL http://hypeandgenius.wordpress.com/wp-login.php?redirect_to=http%3A%2F%2Fhypeandgenius.wordpress.com%2Fwp-admin%2F&reauth=1

    Now try to mix and match with your URL above.

    http://site.original.com/wp-login.php?redirect_to=http%3A%2F%2Fmapped.com%2Fwp-admin%2F&reauth=1

    vs

    http://hypeandgenius.wordpress.com/wp-login.php?redirect_to=http%3A%2F%2Fhypeandgenius.wordpress.com%2Fwp-admin%2F&reauth=1

    The difference here is obvious, your mapped.com is supposed to be site.original.com
    in
    http://site.original.com/wp-login.php?redirect_to=http%3A%2F%2Fmapped.com%2Fwp-admin%2F&reauth=1

    Yes, having said these, my PHP is not strong enough, that's why I couldn't find the answer, only detect the difference.

    My assumption is that everyone here should be using the Domain Mapping plugin from WPMU, And if you guys are good enough, my guess is that the file to change is class.domainmap.php ( please check the plugins file for domain mapping)

    I've tried to look at it before but I'm not on the levels of editing this file.

    Perhaps anyone here can give a try and post it here.

  • RavanH

    Testing 4.1.2.beta.2 with the options Administration mapping and Login mapping both set to 'original domain', I see no different behavior than before. No admin bar (or 'edit this page' links) on the front side when logged in via the original domain. And still impossible to log in when arriving via the url mapped.dom/wp-admin/ ... or rather: it says "succesfully logged in, you'll be redirected..." after which the login form appears again asking to reauthenticate.

  • RavanH

    Hi @Eugene Manuilov to help reproducing:

    Did following tests, each time with browser cache and cookies cleared:

    TEST A
    With the options Domain/Login Mapping set to "domain entered by the user."

    1. Visit site on mapped.dom > not logged in (good)
    2. Visit ori.ginal.dom/wp-admin/ > redirected to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fori.ginal.dom%2Fwp-admin%2F&reauth=1 (good)
    3. Log in via form > message "you are logged in succesfully..." + redirect to dashboard on ori.ginal.dom/wp-admin/ (good)
    4. Revisit mapped.dom > admin bar visible (good)
    5. Visit mapped.dom/wp-admin/ > dashboard (good)
    6. Log out from mapped.dom/wp-admin/ > redirected to login form (good)
    7. Visit mapped.dom > admin bar not visible (good)
    8. Visit ori.ginal.dom/wp-admin/ > redirected to login form (good)

    So test A passed with flying colors.

    TEST B
    With the options Domain/Login Mapping set to "domain entered by the user."

    1. Visit site on mapped.dom > not logged in (good)
    2. Visit mapped.dom/wp-admin/ > redirected to mapped.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (good)
    3. Log in via form > message "you are logged in succesfully..." + redirect to dashboard on mapped.dom/wp-admin/ (good)
    4. Revisit mapped.dom > admin bar visible (good)
    5. Visit ori.ginal.dom/wp-admin/ > dashboard (good)
    6. Log out from ori.ginal.dom/wp-admin/ > redirected to login form (good)
    7. Visit mapped.dom > admin bar still visible (not good)
    8. Visit mapped.dom/wp-admin/ > dashboard (not good)

    Note step 7 and 8 failing.

    TEST C
    With the options Domain/Login Mapping set to "original domain."

    1. Visit site on mapped.dom > not logged in (good)
    2. Visit ori.ginal.dom/wp-admin/ > redirected to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fori.ginal.dom%2Fwp-admin%2F&reauth=1 (good)
    3. Log in via form > message "you are logged in succesfully..." + redirect to dashboard on ori.ginal.dom/wp-admin/ (good)
    4. Revisit mapped.dom > admin bar visible (good)
    5. Visit mapped.dom/wp-admin/ > redirect to ori.ginal.dom/wp-admin/ (good)
    6. Log out from ori.ginal.dom/wp-admin/ > redirected to login form (good)
    7. Revisit mapped.dom > admin bar still visible (not good)
    8. Revisit ori.ginal.dom/wp-admin/ (or click Edit link in admin bar) > redirected to login form (good)

    Note step 7 failing.

    TEST D
    With the options Domain/Login Mapping set to "original domain."

    1. Visit site on mapped.dom > not logged in (good)
    2. Visit mapped.dom/wp-admin/ > redirected to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (redirect is good, but note the mapped.dom in the redirect_to parameter)
    3. Log in via form > message "you are logged in succesfully..." + redirect to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (not good)
    4. Revisit mapped.dom > admin bar visible (good)
    5. Visit mapped.dom/wp-admin/ > redirect to ori.ginal.dom/wp-admin/ (good)
    6. Log out from ori.ginal.dom/wp-admin/ > redirected to login form (good)
    7. Revisit mapped.dom > admin bar still visible (not good)
    8. Revisit ori.ginal.dom/wp-admin/ (or click Edit link in admin bar) > redirected to login form (good)

    Note step 3 and 7 failing.

  • RavanH

    Today I did a repeat of test TEST D on another site in the same network, this time with www in the mapped domain. This time with different results...

    TEST E
    With the options Domain/Login Mapping set to "original domain." and www in the sites mapped domain.

    1. Visit site on mapped.dom > not logged in (good)
    2. Visit mapped.dom/wp-admin/ > redirected to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (redirect is good, but note the mapped.dom in the redirect_to parameter)
    3. Log in via form > message "you are logged in succesfully..." + redirect to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (not good)
    4. Revisit mapped.dom > admin bar not visible (not good)
    5. Visit mapped.dom/wp-admin/ > redirected to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (not good)
    6. Visit ori.ginal.dom/wp-admin/ > redirected to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (good)

    Note step 3 and following are now failing.

    Very strange...

  • RavanH

    To be sure, I redid TEST E on that same site but this time with the mapped domain WITHOUT www. The results where the same, so it does not look like it's related to www or not www. There are no (other) plugins activated on that site.

    Another strange thing I notice is that when being logged in on ori.ginal.dom/wp-admin/ and I attempt to log in via mapped.dom/wp-admin/ (and failing again, see step 3) then I find that I am logged out when I revisit ori.ginal.dom/wp-admin/ !!

    Very confusing.

    @Eugene Manuilov - I really hope you can make any sense of it all. Thanks for your continued efforts in further improving this great plugin :slight_smile:

  • Eugene Manuilov

    TEST B
    With the options Domain/Login Mapping set to "domain entered by the user."

    1. Visit site on mapped.dom > not logged in (good)
    2. Visit mapped.dom/wp-admin/ > redirected to mapped.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (good)
    3. Log in via form > message "you are logged in succesfully..." + redirect to dashboard on mapped.dom/wp-admin/ (good)
    4. Revisit mapped.dom > admin bar visible (good)
    5. Visit ori.ginal.dom/wp-admin/ > dashboard (good)
    6. Log out from ori.ginal.dom/wp-admin/ > redirected to login form (good)
    7. Visit mapped.dom > admin bar still visible (not good)
    8. Visit mapped.dom/wp-admin/ > dashboard (not good)

    Note step 7 and 8 failing.

    The SSO doesn't logout from all mapped domains if you logged out from original domain. It means that TEST B and TEST C works as expected right now (currently i am not sure whether it is good idea or not to propagate logout on all mapped domains * all accessible sites).

    TEST D
    With the options Domain/Login Mapping set to "original domain."

    1. Visit site on mapped.dom > not logged in (good)
    2. Visit mapped.dom/wp-admin/ > redirected to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (redirect is good, but note the mapped.dom in the redirect_to parameter)
    3. Log in via form > message "you are logged in succesfully..." + redirect to ori.ginal.dom/wp-login.php?redirect_to=http%3A%2F%2Fmapped.dom%2Fwp-admin%2F&reauth=1 (not good)
    4. Revisit mapped.dom > admin bar visible (good)
    5. Visit mapped.dom/wp-admin/ > redirect to ori.ginal.dom/wp-admin/ (good)
    6. Log out from ori.ginal.dom/wp-admin/ > redirected to login form (good)
    7. Revisit mapped.dom > admin bar still visible (not good)
    8. Revisit ori.ginal.dom/wp-admin/ (or click Edit link in admin bar) > redirected to login form (good)

    Note step 3 and 7 failing.

    Step 3 is definitely an issue. Work on it. Step 7 is the same as TEST B and TEST C.

  • RavanH

    @Eugene Manuilov - just uploaded and tested. The issue of step 3 seems to be solved. After login I get redirected to the admin page on the original domain correctly.

    Still, there is a weird problem. I did Test E again and at step 4 it still does not show the admin bar on the mapped domain front end after logging in (step 3) successfully. If I edit a post and hit "Preview Changes" I still get the "You do not have permission to preview drafts." error message page.

    But... This was in the Chromium browser with cleared browser cache. Then I repeated the test in the Opera, Chrome and Firefox browsers, and there this issue did not occur!

    Anyway, I would argue for a synced logout (per site, not network wide) on both mapped and original domain. Right now (at least in Opera) when a user logs out from the back-end on the original domain, he/she is still logged in on the front end. This is not only confusing but actually useless because when the user hits "Edit This" he/she will still have to log in again on the back end...

    Also, the fact that when logging out from the font end (mapped domain) the user is actually logged out from the back-end on the original domain. Which is inconsistent with the reverse case. But funnier still is the fact that on the front end, the user is still logged in!

    Case in point, two tests with some funny results:

    TEST F
    With the options Domain/Login Mapping set to "original domain" and logged in as site admin on both original and mapped domain:

    1. Log out from mapped.dom admin bar > redirected to login form with message "You are now logged out." (good)
    2. Revisit ori.ginal.dom/wp-admin/ > redirected to login form (in my opinion: good)
    3. Revisit mapped.dom > Admin bar still visible (not good, whatever you argue)

    TEST G
    With the options Domain/Login Mapping set to "original domain" and logged in as site admin on both original and mapped domain:

    1. Log out from ori.ginal.dom/wp-admin/ > redirected to login form (good)
    2. Visit mapped.dom > Admin bar still visible (in my opinion: not good)
    3. Log out from admin bar on mapped.dom > redirect to error page saying: "You are attempting to log out of [site name]. Do you really want to log out?" (strange)
    4. Follow log out link > redirect to login form with message "You are now logged out." (good)
    5. Revisit mapped.dom > Admin bar still visible (not good, whatever you argue)

    So in short, in Chromium I cannot be logged in on the front end, in other browsers I cannot log out of the front end.

    Just too strange...

  • RavanH

    @Eugene Manuilov - the difference between Chromium and the other browsers is due to the fact that Chromium (version 32.0.1700.102 Ubuntu 13.10) blocks indirect cookies (from other domains) by default. I tested allowing cookies from the original domain too but that was not enough, I needed to allow cookies from the original top level domain (main site) too. After that, the behaviour was same as with the other browsers.

  • Casey

    Hey guys, sorry to butt in, but i've been testing this as well.

    At the moment, it's working perfectly for me. Never before has this plugin been viable for my application, i've had to use the wordpress free version, but now it is :slight_smile:

    Everything looks to be working great, except for the fact that it takes about 20 seconds for the network settings domain mapping options page to load?
    The other pages are snappy but this one lags on a 'waiting for sitename.com'

    I haven't tested this on multiple browsers, but it happens each and everytime on the latest Google Chrome on Mac OSX 10.9

    This isn't a problem, as i won't need to access this page again. But it makes me wonder what's going on, as far as mysql queries and things.

    Cheers for your hard work Eugene.

  • Casey

    I've found a bug to do with SSL on the beta 1.3 version of Domain Mapping.4.1.2

    On the domain mapping page under the tools menu on subsites (where you enter that subsites domain) the 'Map Domain' button doesn't work under https://

    Soon as Force_SSL_ADMIN is turned off, it works again.

    Not sure if anyone else uses SSL, but this is a bug that almost halts the use of either SSL or domain mapping.

    Alternatively, is there an alternate page, or settings page that i can add a new domain to a subsite?

    Cheers :slight_smile:

  • Eugene Manuilov

    Hi @Casey

    At the moment, it's working perfectly for me. Never before has this plugin been viable for my application, i've had to use the wordpress free version, but now it is :slight_smile:

    Really glad to hear it :slight_smile:

    Everything looks to be working great, except for the fact that it takes about 20 seconds for the network settings domain mapping options page to load?

    On the domain mapping page under the tools menu on subsites (where you enter that subsites domain) the 'Map Domain' button doesn't work under https://

    You have quite weird problems. I have rechecked it and everything works fine on my end even under SSL. I suppose there could be some influence from 3rd plugin at your end. Could you deactivate all plugins, except Domain Mapping and recheck it? Let me know.

    Regards,
    Eugene

  • RavanH

    Just replaced Networks for WordPress with WP Multi Network to test but that made no difference. Go to jessandcom.fr/wp-admin/ and notice how the address becomes jessandcom.eclectic.pro/wp-login.php?redirect_to=http%3A%2F%2Fjessandcom.fr%2Fwp-admin%2F&reauth=1 where the redirect_to parameter still holds the mapped domain making a log in impossible...

    Another funny thing: if I do the above while logged in as Super Admin on the main domain, I find myself being logged out when I return to the main site.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.