Expected behavior (based on orthogonality and code review) is if any plugin returns false, the logout process is aborted. In that case, onUserLogoutFailure event is triggered. If the logout is successful, onUserAfterLogout is triggered instead.
If you return false, the appropriate events are triggered. However, the user is still "mostly" logged out anyway. This is because plugins/user/joomla/joomla.php does its logging-out code in onUserLogout, rather than in onUserAfterLogout.
As a result, it is not actually possible to abort the logout process. Either the return values should not be checked at all, or the stock plugins should use onUserAfterLogout instead. Or a new onUserBeforeLogout event added, I guess.
Joomla! 3.3.6 Stable [ Ember ] 01-October-2014 02:00 GMT
Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
Apologies if this is the wrong place for API issues.
Set to "closed" on behalf of @vdespa by The JTracker Application at issues.joomla.org/joomla-cms/4497
Category | Plugins | ⇒ | Authentication Plugins |
Status | New | ⇒ | Known Issue |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-10-27 20:27:15 |
Uh, I wrote that in the wiki after submitting this bug. It's a "known issue" because I reported it here and in the documentation?
So is this just a regression in 3.3.6?
No, apologies, the phrasing on the wiki could be better. I meant that it occurs as of at least 3.3.6. (When I was first working on that page, it hadn't been updated since 1.8, so I didn't want to confuse versioning issues further.)
It occurs in at least 2.5. I don't know if it occurs before that. The reason it feels like a bug is that a new event was added sometime between 2.5 and 3.3.6, "onUserAfterLogout", which could be used to circumvent this issue if all the stock components used it. But a couple of stock components still don't use the new event. It seems like someone mostly-fixed this issue, but missed some spots.
So it should be pretty straightforward to finish off, but I've got no experience with git, so it will be a while before I can submit a PR for it.
I don't have problems with it being considered a Known Issue if that seems like the right thing to do, I just don't want to screw up the process because of having edited the wiki!
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4497.
Status | Known Issue | ⇒ | New |
Set to "open" on behalf of @vdespa by The JTracker Application at issues.joomla.org/joomla-cms/4497
I am reopening this.
@heimburg - unfortunately if this issue is that long in the CMS, the chances of it getting fixed are slim, especially if nobody volunteers to investigate further and to submit a PR.
Actually if you have the time to look into it more closely, you have here an introduction on how to submit a PR: http://docs.joomla.org/My_first_pull_request_to_Joomla!_on_Github
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4497.
Labels |
Added:
?
|
Status | New | ⇒ | Closed |
Closed_Date | 2014-10-27 20:27:15 | ⇒ | 2015-05-08 22:19:01 |
Closed_By | ⇒ | zero-24 |
Quoting the documentation: "NOTE: as of 3.3.6, returning false does not work correctly, because stock components perform their logout operation during the onUserLogout event. So even if your plugin returns false, the stock ones have already run anyway. Thus, the user will be "mostly" logged out even if you return false. There is no actual way to cleanly abort logout."
So I am marking this as a known issue. If you can investigate and can propose a fix, please submit a PR on github with testing instructions.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4497.