I don't use Kunena, however, I installed it and logged in successfully. Is this an upgrade from v3.8.3? Have you posted in Kunena forum to see if this an issue with other users?

Yes this was an upgrade from v3.8.3
I am just posting a message on the Kunena forum now.

Sounds like an issue with redirect on login

I have posted a message on the official Kunena forum here and waiting for feedback.
I have been using Kunena for 5 years and not experienced a problem like this before.
https://www.kunena.org/forum/k5-0-support/150516-joomla-3-8-4-breaks-kunena-5-0-13-login

The same happened with several extensions of mine when performing a login.
It turns that this issue is related to the Language Filter plugin inside the onUserLogin method. Indeed it has been changed due to the 'looking for associations' purpouse.

I found that the line 647
$query = $this->app->getRouter()->parse($uri);
causes a login/redirect break when the $uri is empty.

@csthomas

I see that there is some problem with login, for example, with Community builder. After upgrade to 3.8.4 i can't login through CB in frontend. I see that not only me: https://www.joomlapolis.com/forum/145-community-builder/238466-community-builder-login-module?limitstart=0

I am seeking a solution for Language Filter plugin

To all: does that mean that each of your sites is a multingual site and uses Associations?

@csthomas
related? #19497

To all: does that mean that each of your sites is a multingual site and uses Associations?

For me it is true
But i am not sure that there is association with login module. At least i do not see this association in menu.

Same problem here.
Two languages on beta site

login redirect issue

see: https://next.talking-business.de/de/cb-login

One solution for the moment, IF you your site is multingual and the languagefilter is set to use Associations, is to set automatic language change to "No".

For the moment one solution is to disable the 'Automatic language change' as @infograf768 said.
I had to patch and release an update for all my affected extensions. The solution is to set the 'login_redirect_url' param in the active menu that overrides the automatic change.

If only we had beta releases so that developers could test things first

@brianteeman it's not always easy to test everything during the beta release phase. Most of bugs bubble up when the stable is released.

To all: does that mean that each of your sites is a multingual site and uses Associations?

My site is English only.
System/Language Filter was already Disabled and login via Kunena does not work.

Login via main website does work OK, but login via Kunena (inside of website) does not work.
If I login via website first and then go to Kunena, I am logged in and can access Kunena.
I can also Logout OK via Kunena.

Can you folks put value of the return field from the login forms?

It looks like <input name="return" value="aHR0cDovL2xvY2FsaG9zdC9+dG9tYXNoL2E0L2luZGV4LnBocC9lbi8=" type="hidden">

The Kunena login doesn't have a return field. The regular one has one. It should not be required anyway.

It's supposed that a return field must not be mandatory. Things must work anyway.

It is not mandatory.

I can not replicate the problem.
I installed kenuna on my local apache enable/disable multilingual, php 7.2 on ubuntu and all still works.

@csthomas have you tried even with multilanguage enabled and 'automatic language change' enabled?

Yes, I will check a few more things like install joomla on different domain.

Sites to test if you like:
https://www.sermonspeaker.net/forum.html
https://www.bakual.net/forum.html

So I have to start that https://www.bakual.net/component/kunena/ return 404 on GET request.

@Bakual How you set 404 on /component/kunena/?

it's not always easy to test everything during the beta release phase. Most of bugs bubble up when the stable is released.

The only way bugs creep in to a stable release that cannot be caught by running from the git development branch or installing nightly builds or tagged alpha/beta/RC packages is by way of security patches which are obviously not shared publicly until release. Over 99% of "bugs [that] bubble up when the stable is released" are bugs that live in the development branch.

How you set 404 on /component/kunena/?

I didn't set that myself and haven't debugged anything yet. My guess is just that some code tries to redirect to a page other than the currently active (forum.html) for whatever reason and that fails. I'm not even sure why /component/kunena fails because imho it should actually work. Similar links like https://www.sermonspeaker.net/component/sermonspeaker work fine.

But then, one shouldn't end up with "/component/kunena/" anyway because there is a perfectly valid menuitem and it should just redirect back to that forum page (used to do just that).

My guess is just that some code tries to redirect to a page other than the currently active (forum.html) for whatever reason and that fails.

The only that i found is the multilanguage plugin feature 'automatic language change'

A member of the Kunena support forum has posted a temporary fix to this problem here:
https://www.kunena.org/forum/k5-0-support/150516-joomla-3-8-4-breaks-kunena-5-0-13-login#197954

He has advised to do this:
Replace libraries/src/Router/SiteRouter.php with the one from Joomla 3.8.3.

Temporary fix works on my site.

Replacing a core file is not a solution.

About Kunena,

Link to form action is generated as JRoute::_('index.php?option=com_kunena');, there is missing a view, therefore menu item can not be found.

Note: Maybe createUri method should check if view is set and if not then add active Itemid.

At kunena component people set in global kunena configuration option Direct Component Access = NO. After that login to kunena return error 404.

Temporary options for now:

1. Direct Component Access set to Yes or
2. If you change JRoute::_('index.php?option=com_kunena'); to JRoute::_('index.php'); at components/com_kunena/template/crypsis/layouts/widget/login/login/default.php then all back to normal.

This should help:

diff --git a/libraries/src/Router/SiteRouter.php b/libraries/src/Router/SiteRouter.php
index 6dbabc1ea0..9f8daaf833 100644
--- a/libraries/src/Router/SiteRouter.php
+++ b/libraries/src/Router/SiteRouter.php
@@ -708,7 +708,7 @@ class SiteRouter extends Router
 
                if ($itemid === null)
                {
-                       if (!$uri->getVar('option'))
+                       if (!$uri->getVar('option') || !$uri->getVar('view'))
                        {
                                $option = $this->getVar('option');
 
@@ -717,6 +717,13 @@ class SiteRouter extends Router
                                        $uri->setVar('option', $option);
                                }
 
+                               $view = $this->getVar('view');
+
+                               if ($view)
+                               {
+                                       $uri->setVar('view', $view);
+                               }
+
                                $itemid = $this->getVar('Itemid');
 
                                if ($itemid)

Link to form action is generated as JRoute::_('index.php?option=com_kunena');, there is missing a view, therefore menu item can not be found.

Then that is a bug as well. Because components have a "default view" feature which makes sure it will work. The router at least should return the first Itemid found for a given component if no view is specified. If the currently active one is from the active component, it should take that.

Direct Component Access set to Yes

That indeed works. Interesting enough the URL in the browser is still forum.html after login.

I added PR #19501 which should resolve one part of problem but I have not enough information about

I found that the line 647
$query = $this->app->getRouter()->parse($uri);
causes a login/redirect break when the $uri is empty.

@joeforjoomla
Can you test PR and check if it still generate a problem. Do you have any error log?
When you disabled the automatic change language, on what page are you redirected and on what page you should be redirected after enable the automatic change language.
The $uri link is some how restricted, only for registered?

@csthomas i tested the PR #19501 but it doesn't resolve the problem. At least not the one due to the language filter plugin. It seems a bit unrelated too.

My extension perform a login using the $app->login method and after that the login is successful there is a normal redirection to a component page.
The problem arises when the parse method is fired in the language filter plugin, indeed the $uri variable is empty. The user state 'users.login.form.return' is not defined (is not supposed to be mandatory). This causes the router parse method to redirect someway but i can't determine exactly how. On a website i got redirected to the home page, on another website i got a browser error ERR_INVALID_REDIRECT

A quick solution will be to check if "users.login.form.return" is not empty, and then generate the new JUri.
Because all new stuff may be reverted then I will wait with that patch.

I agree @csthomas

Closed as the routing changes have been reverted for 3.8.5 with #19512