Comments 77

Could you please grant me access to your backend so that I may see exactly what is happening?
To do so, from your dashboard go to WPMUDEV => Support => Support Access and click on the "Grant access" button.

I just logged-in on your site and took a look at all your settings and everything else I could think of... Unfortunately I was unable to find anything that would cause this, so I am calling in our coding experts on this one.
Hopefully they'll be able to help out more than me...

Yah, this issue cause because it's make the cookies conflict. I the scenario, you have logged in the subdomain, now the cookie will save you as for the sub domain. But after that, you login in to the mapped domain, now the conflict happened, and wordpess can not verify the cookie value for the new domain. So clear cookie will fix this :slight_smile:

If you have any issues please don't hesitate to let us know so we can assist

Hope you're doing well today and thanks for your question! I would say it's quite unlikely to happen. I've been providing support here for almost 6 months and this is the first time I've seen this issue.

if it does happen then just make note of Hoang's solution to let your client know :slight_smile:

This just happened to me as well. The only difference, is the site that it happened on did not map a domain. I have the domain mapping plugin activated, but the site wasn't using a mapped domain. It just randomly wouldn't let me view the site when logged in. If logged out, I could view the site, but if I tried to view the site when logged in, I received the error: Incorrect or out of date login key

Thankfully this was a test site, however I have no way of knowing how many customers I lost, if this happened to them as well.

Can this be looked into more? My customers who use my sites on my multisite network are not tech savvy people, and I hardly think that asking them to "clear their browsing cookies" is a good solution. This is a bug in the code and should be fixed.

I will check with the developer about this issue, maybe, when the domain mapping found that the cookie validate is not good, the plugin can force to clear the cache automatically, and show a message like "Please try again".

This example is untested, probably not working and I'm not even sure if INPUT_GET is a cookie :smiley: But I think you'll get the idea ^^

For non-code savvy: It basically logs the current user out and redirect them to the login page after 5 seconds.

The principles have been tested, I redirect myself manually from the Error page to the login page on that site and log in again and I will be redirected from there to the website's dashboard, the Error won't occur again after the CDSSO kicked in (for the time being).

Currently I'm testing this on my live site, I'll report back with my customer's complaints xD:

Anyway, I got a very temporary (visual) fix for anyone who has a lot of costumers on their website running into this problem. This does not fix the root cause which I know nothing about. Only apply the code below if you know what you're doing and willing to take the risk.

So, on line 345 (I could be off) in domain-mapping/classes/Domainmap/Module/Cdsso.php change the following line, from:wp_die( __( "Incorrect or out of date login key", 'domainmap' ) );

Hi @Ossi! I cannot reply more than 5 levels deep so this is a bit weird lol.

Anyway, I would like to stress that this does not fix the root problem, this will only redirect the user when the problem occurs so the user can still log in and stays on the website after this error shows up.

It also does give a little more information than "out of date key" does so the non-techy users (which are more than 99% of them?) know what's going on and what to do instead of looking for their car keys.

It also allows the user to interact with your website without fiddling with their browser('s url bar) or even worse, closing the window.

However, it's a nice addition to have and keep (or adjust for the better) although it might not be perfect :slight_smile:

There are a lot of issues with domain mapping and all these issues are caused by this: it's freaking difficult and absolutely unnatural for your browser and server, there are also many different server/website configurations that need to be considered. Luckily Sam, Hoang Ngo and the rest of the WPMUdev team are brilliant :slight_smile:

P.S. I can almost replicate this issue instantly since the last update. About every 1 to 2 re-logs and crossing over the 9 mapped domains I almost always get 2 or 3 sites that give these errors, which of these give the error is random. This also accounts HTTPS sites. My customers have been complaining too so that's why I looked it up and came here. This mostly happens when 2 or more tabs are open on the server, say "maindomain.com = tab1" and "userdomain1.com = tab2" for example.

I'm (or rather, site owners on my network) running into this issue on a too regular basis these days. I'm getting more and more complaints and even though clearing the browser cookie cache or forcing a logout by passing via /wp-login.php?action=logout (is that not a good redirect URL instead of showing any cryptic message!?) works, clients are very unhappy about this.

@Ossi quick question: Are you using any form of Cache? If so, are you using Object Cache?

I our case: yes we are using W3TC for memcached object caching.

We are also using Domain Mapping in combination with Multi-Domains with SSO enabled. So that might also play a role here... And one final note: when I switch the Domain Mapping network options for "Login/Administration mapping" to any other setting, the issue also disappears (without clearing cookies) but after a while it will start again :slight_frown:

For anyone interested, I'm only using Page Cache at this moment. Disabling Fragment cache was a must because it was bugged and Disabling Object cache also improved overall performance - This might differ per server and its configuration. Because of this, I discovered a way to prevent any out of date keys and with that I prevented any SSO loops.

If you're using Apache's MPM Worker I'd advice you to switch to MPM Prefork - This is done on the server level. I'm not sure if it would help you but I noticed a much more steady performance in the admin side of my sites. I'm pretty convinced that this has nothing to do with the bugs described in this topic, but it might just be the weird key.

Anything you can do on the W3 Total Cache level to prevent these problems is as follows:
- Disable all caches besides Page Cache, you can still use the CDN, NewRelic, Varnish, Google Analytics and w/e features.
- Enable "Use single network configuration file for all sites".
- In Page cache, disable Cache URIs with query string variables
- In Page cache, enable "Don't cache pages for logged in users"
- In Page cache, enable "Don't cache pages for the following user roles: Admin, Editor, etc.
- In Page cache, disable Late initialization
- In Page cache, add the following 3 lines of code in "Never cache the following pages:".*/\?__domainmap_action=domainmap-authorize-user.*http://yourdomain\.com/wp-admin/admin-ajax\.php\?action=domainmap-setup-cdssohttps://yourdomain\.com/wp-admin/admin-ajax\.php\?action=domainmap-setup-cdsso

Change yourdomain\.com into your domain :slight_smile:

Alter any other settings to the ones you'd like.

If you have tried out the above suggestions, let us know if it helped you :slight_smile: For me it has :slight_smile:

I would like to add that I found the core problem of this: You're logged in other sessions.

Brilliantly, since WordPress 4.1 the user's profile page contains a "destroy-sessions" options, this will log the user out of all other sessions and will make them enjoy your website again.

I would like to announce that this will solve the problem of "incorrect and out of date keys" if implemented correctly.

I've pulled out all the code that's required and ordered them in order of necessity. All that's needed is for this code to be implemented and the user can log himself out of all other sessions with a click of a button and thus fix the problem instantly.

This could also be done automatically (so without a button, with a notification) to which I do not see any problem, alas they do have to log in again on the other device but hey, they will be able to use the website again :smiley:.

Here's the code, unfortunately I do not have the time to implement this so I'd like to assign this job to @Sam or any other involved developer on Domain Mapping for an overall bug free user experience.

Has any updates been made on this? I'm getting paid customers that are getting this error ("Incorrect or out of date login key"), and it's not creating a good customer experience for them. Can you please let me know if any progress has been made on this?

I haven't faced this problem in a long time. I think this is because I set the Domain Mapping options to the following values in /wp-admin/network/settings.php?page=domainmapping_options

Administration mapping = domain entered by the user
Login mapping = original domain <-- this is the big change, was needed for cache clearing to propagate, this might also work for the cookies and stuff.
Cross-domain autologin = Yes
Verify domain's DNS settings = No
Force http/https (Only for original domain) = Yes ( I use SSL)
Would you like to force http/https in front-end pages: = No (Done through .htaccess)

@Sybre, setting the Login Mapping to Original domain seems to work (so far only tested one day) except for sites using Polylang with the option "Language is determined by domain" enabled and different domains set for each language. In an ideal world I'd like to see Polylang and Domain Mapping play nice together. It would make for a powerful combo but I realize that adding more complexity at this point is not helping :wink:

I think the best case scenario would be to ditch the admin-ajax.php file load (which is just being dumped into the header regardless on what to use from it) and make a nice global cookie that is pulled with JS, or rather with some HTML5 magic when possible.

I'm going to look into this on my own terms when I find the will and time, but don't expect anything special :p

P.S. for the WPMUdev own theme dev: Add this to your CSS (The use for it on this topic post is a good example :smiley:):.job-single .entry-content p, .topic-single .entry-content p { overflow-wrap: break-word; } Thank me later =P

I am having the same issue mostly in safari! So I tested the clearing cache and it works the problem is that after a while I have to clear again. I can deal with this issue but I don't want my users to have to clear cache.

@WrSantiago - I tried the suggestion by @Sybre, setting the Login Mapping to Original domain and the issue seems to occur less but has not gone away on our installation. I agree it's a nasty 'bug' (or unfortunate side-effect of who knows what) that is pestering our clients. And having to explain to them, after the frustration of not even being able to see the front end of their own site (redirect to the ugly message everywhere) how they need to do some stuff on their own browser that they might have never even done before... It's embarrassing to say the least :slight_frown:

In a post earlier on this thread I shared a solution that worked great, until it was overwritten again by the following plugin update:

Just to let others know: we're using the following code to replace the unhelpful "Incorrect or out of date login key" text with some more info and a working logout link:

This (in theory) should force a logout and depending on the original page requested, will simply make the client land on that page or the login form again. This might (slightly) raise an eyebrow or two in surprise but at least the user knows how to log back in and the issue should then have resolved itself. In my opinion a friendlier approach than an unhelpful message that only brings me frustrated clients...

That's weird! I haven't had the problem ever since, although I'm not sure if you've set everything like I have.
I'm also wondering if you're using a caching plugin, I've completely disabled browser caching and have done a lot more on the back-end through Apache. It might just be a sum of solutions that prevents this error from recurring, but we've got to dig deeper!

If you're still getting the issues, I'd love to hear more about your (WordPress) network settings to which you think that might relate to this issue, both front-and back end.

Let's splat that bug :smiley: Because quite frankly it's like you say, it will raise an eyebrow when it happens! Fixing the root of the problem is much better than finding ways to log the user out and in again in the most convenient (and thus most difficult) way :slight_smile:

It might just be a sum of solutions that prevents this error from recurring, but we've got to dig deeper!

And likewise it must be a sum of circumstances that make it happen because it seems not everybody is suffering the issue...

Yes we are using caching. Both DBquery+Object caching (managed by W3TC) in memcached and a content cache by FastCGI Cache on the Nginx server level. Removing these is no long term option for us but I'll try to play with clearing caches etc. as soon as I run into the issue again.

I also have the impression the new Domain Mapping options to do the SSO async and to put the scripts in the footer might be of influence. Last time I ran into the issue on one of the sub-sites, I went back to the main network settings and changed these two options. Then going back to the page with the login key problem, it suddenly was no problem anymore.

I must note that all this time, on another network installation with Donncha's Domain Mapping plugin (and otherwise similar plugins) on a similar server setup (Nginx+FastCGI Caching and memcached for object and DB query caching) there are never problems with the SSO on both original and mapped domain. No idea (yet) about the difference in the login process of these two Domain Mapping plugins but it might be worth investigating. I do notice that Donncha's plugin does not offer the possibility to have the login on another domain than the admin... Maybe the login and admin pages simply always need to be on the same domain to prevent this issue?

The difference I see within your servers is the Object caching being available or not.

In my experience, the Object caching from W3TC is bugged - slow admin area + this was one of the first things that I disabled that lead me to an error free experience cross-domain. Better use batcache or none at all (I took the latter).

The DB Query cache should be done by WordPress itself and your server, please see if you can enable SQL cache within the server and disable that feature within W3TC.

Yes I agree with @mindset . I have been experiencing this for quite some time, and it should be fixed by now. It's extremely irritating. WPMUdev does a great job at releasing new plugins and themes and marketing those plugins and themes, but all that is useless if the plugins don't work the way they are supposed to, or fixed when multiple customers complain about the same bug.

So can someone from WPMUdev please chime in here and let us know what is being done to fix this issue, and when we can expect it to be resolved????

I've had a discussion with the lead developer of Domain Mapping about this, he's currently re-working SSO to reduce load times and is also re-working the way cookies are handled, which should stop any and all issues with caching, varnish and any other types of setups.

It'll need to undergo quite a bit of testing prior to release, but it is being worked and we're aware of the issue, appreciate everyone's patience here.

Yep, we already posted a new thread on this quite a ways back and there still hasn't been a solution, so this is the latest thread I've been able to find and that came up in your search. It has no solution, so I'm confirming that 8 months later, the issue still exists and still needs a solution.

Yep, cookie and cache issue related to the plugin ... We've been using the plugin for 6 to 7 years .... so just trying to see if there might be a solution at hand before we swap it out ... clearing cookies dozens of times a day isn't doable anymore for us ...

On the contact form, select "I have a different question", this ensures it comes through and gets assigned to me.

- Mark to my attention - ATTN: Sam Najian
- Link back to this thread
- Include admin/network access
- Include cPanel (I will need to look at the DB so need PHPMyAdmin or similar)
- Include FTP
- Include any relevant URLS for your site

And please let me know how i can reproduce the issue you're facing.
With the above i'll take a look and try to have a fix for it in the up coming bug fix release which is already on the way.

I noticed there is a 'fundamental' difference in these two plugins: Donncha's domain mapping plugin does not offer the possibility to have the login and admin on different domains and there is no option like "domain entered by the user." Which makes me wonder if the complexity of options provided by WPMUDEV's Domain Mapping has been preventing a solid reproduction and diagnose of the underlying problem...

I do like the option "domain entered by the user" very much. It both guarantees admin accessibility (in case of domain not beeing renewed or incorrect DNS entries) on the one hand, and in the clients eyes 'normal' WordPress operation where the admin is on the same domain as the front (good for Jetpack's Publisize too!) on the other hand. But then, being prevented from logging in at all is terrible. And in some cases (some settings?) after such a message the client would not even be able to get back to the front end without getting the same message over and over again! Absolutely unacceptable :slight_frown: so we tried with a small adaptation of the message (including a logout link) so the client could at least log out, get to see the front end again and then try again. But after a while we decided to go back to Donncha's Domain Mapping.

Please note: we're using three levels of caching. An object cache and database cache provided by W3TC, and a static Nginx FastCGI cache. This complicates things even more and might very well be directly related.

Hope this helps in reproducing and finally fixing it for everybody :slight_smile:

Guys,
*** For those who use domain mapping with multi-domains plugins **
Please use and replace the attached file with the one in wp-content/plugins/multi-domains/multi-domains-sso.php and let me know if the incorrect or out of date issue gets fixed for you.

Bugger. I ran into this issue again yesterday so this is still not completely resolved.

Whatever the settings, whatever the caching solutions (server side or plugins) running, original domain admin on HTTPS, using Multi-Domains alongside Domain Mapping or not ... at some point, someone WILL get the "Incorrect or out of date login key" response. And WHEN they do, they're locked out of their site completely!!! Even visiting the front end will result in getting redirected back to this message. And for normal site admins/users there is NO way to get out if this hopeless loop unless they either know they need to clear browser cookies (and how to do that!) or if they have the insight to manually strip the login key from the URL and revisit the login form.

It looks like it is simply impossible to prevent everyone from EVER landing on that response. It's coded there for a reason after all... So my conclusion: if this cannot be prevented for every case, then the error message MUST be either :

So please, please, please, PLEASE (Yes I know, I'm shouting here but this realy is a serious dealbreaker problem because I'm loosing clients over this!!!) consider applying such a patch alongside any improvements to the SSO process that are added now or in the future. If not, the whole beautiful tower of features that WPMUDEV Domain Mapping has become, is built on quicksand :slight_frown:

Sorry to hear about the inconvenience and i'll use your valuable input for in the next release for sure.
Please let me know if using async SSO helps you with the issue you're facing or you run into any other issue when using async SSO?

I've tried the "Async" option but because the issue appears only very occasionally and irregularly, I cannot say if it makes any difference. All I can say is that it does not seem to completely resolve the issue in all cases.

Should activating the async option diminish the occurrence of this issue? If so, I'll for sure set it to ON on all networks :slight_smile:

I was just about to start a new topic about this, but others are apparently having the same issue.

I've tried various suggested fixes above, but we still get the "Incorrect or out of date login key" error when attempting to view a mapped domain/site if logged in to the main site.

Clearing cookies for both domains did not help. We are not running the Multi-Domains plugin. Three users have reported this issue and I just confirmed it myself. I cannot view the front end nor the dashboard if logged in. When logged out, the site loads fine.

@Ashok @Vinod Dalvi @aristath I have just granted Support Access at http://tripawds.com Could one of you please review my Domain Mapping Settings to see if I have overlooked something simple? Thank you!

I have been dealing with this issue for 18 months or so -- I had to stop working on my network because it became impossible to navigate and work -- Fortunately we had not launched yet -- but I need to take the site live -- and I was hoping that they had fixed it --

This is not good news -- I am a big proponent of wpmudev but this is like the third issue that has brought my development to a standstill or I have had to find a work around -- and though the supports response time for simple issues is excellent - wpmudev does not seem to have the staff to resolve major issues -- I have become very disappointed and my placement of trust and dependency on wpmudev has cost me major delays in my project. I am pretty frustrated with them wpmudev -

Thanks for posting in this thread, however it might be best if you open your own, even if the issues seem closely related. That way it will remain independent of this one and ensure it doesn't confuse issues here if this thread needs reopening again by the author.

It also means the member who started this thread or anyone following it isn't inundated with post notifications each time we respond to each other. A lengthy thread could annoy the original poster.
This also allows us to better track and answer your questions to ensure we don't miss any for you.

We would recommended you to create a new ticket to help get your queries answered quickly. Even if the issue seems closely related, replying here won't help neither of us, as this ticket is over a year old. It sounds like a issue that needs specific attention.

I am not sure what submitting a new ticket will do, I have been dealing with this issue for 18 months or so and so have many others. I had to stop working on my network because it became impossible to navigate and work -- Fortunately we had not launched yet -- but I need to take the site live pretty soon and I still have a ton of work to do yet -- and I was hoping that they had fixed it --

This is not good news -- I am a big proponent of wpmudev but this is like the third issue that has brought my development to a standstill or I have had to find a work around -- and though the supports response time for simple issues is excellent - wpmudev does not seem to have the staff to resolve major issues -- I have become very disappointed and my placement of trust and dependency on wpmudev has cost me major delays in my project. I am pretty frustrated with them wpmudev -

It would be better if you create a new thread in our forums. This way, once you grant support access, we will have a clearer picture of your installation which will help us to provide better assistance.

Make sure that you have the latest versions WordPress and plugins, as jcnjr has suggested.

How do you rate me?

Thank you for rating your experience!

We’re thrilled to hear you had a great experience with . Would you like to leave a comment about your experience?
Thanks for voting on your experience with , we’d love to get some feedback please.
Ohh no! We’re really sorry to hear you didn’t have a pleasant experience with , we’re always looking at how we can improve and would appreciate you provide some further feedback here please.
Type your feedback here

it's great that you had a positive one. Based on your experience in this ticket would you please be kind enough to rate us externally on: