Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REGRESSION - Wrong redirect after login on front-end since 3.4.6 #8689

Closed
Klipper opened this issue Dec 14, 2015 · 150 comments

Comments

@Klipper
Copy link

commented Dec 14, 2015

Steps to reproduce the issue

  • In administrator create menu-item to login-page (index.php?option=com_users&view=login).
  • On the options tab of 'Menus: Edit Item': add URL at 'Login redirect'

Expected result

Redirect to entered URL after login.

Actual result

Reload front-end, click the login link, enter Username and Password in the presented login-form and login. You will get redirected to the user profile of the user who login, instead of to the url you added at the 'Login redirect' option.

System information (as much as possible)

Redirect worked like a charm in 3.4.5 and before...
The trouble started with the 3.4.6 update.

Additional comments

Tested on 6 different sites and on multiple hosts too.
For best compare:

Add a redirect-url in Joomla 3.4.5 you will see correct redirect, after update to 3.4.6 redirect to the url fails and userprofile will be showed.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2015

Confirmed


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8689.

@brianteeman brianteeman changed the title Wrong redirect after login on front-end since 3.4.6 REGRESSION - Wrong redirect after login on front-end since 3.4.6 Dec 14, 2015
@infograf768

This comment has been minimized.

Copy link
Member

commented Dec 15, 2015

I used a full url (internal as it must not be external) and it works here, whether as a menu item or from the login module.

@infograf768

This comment has been minimized.

Copy link
Member

commented Dec 15, 2015

Forgot to say I tested on staging.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

Can you explain what you mean by a full url.
In my test I redirected to "blog"
It worked on one site and didn't work on the other
On 15 Dec 2015 8:26 am, "infograf768" notifications@github.com wrote:

Forgot to say I tested on staging.


Reply to this email directly or view it on GitHub
#8689 (comment).

@infograf768

This comment has been minimized.

Copy link
Member

commented Dec 15, 2015

I used something like (Sample Sites in sample sql)
index.php?option=com_content&view=article&id=38

tested on an updated 3.4.5 and I had no issue, whether before killing the session or logging with another browser where no session was set.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

Thanks I will retest with a non-sef url. Can you also test with a sef url

On 15 December 2015 at 08:51, infograf768 notifications@github.com wrote:

I used something like (Sample Sites in sample sql)
index.php?option=com_content&view=article&id=38

tested on an updated 3.4.5 and I had no issue, whether before killing the
session or logging with another browser where no session was set.


Reply to this email directly or view it on GitHub
#8689 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@infograf768

This comment has been minimized.

Copy link
Member

commented Dec 15, 2015

No issue either when using
http://localhost:8888/Joomla_3.4.5/index.php/content-modules here

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

I personally worked on this for the Joomla 3.4.6 release.

There is no regression - there is a security fix.

Let me explain, prior to Joomla 3.4.6 there was a security bug that allowed a hacker to redirect a user after login through incorrect use of the redirect url, as it can be overwritten by user supplied data.

In Joomla 3.4.6 additional hardening of JURI::isInternal() took place - with full unit testing (a rare thing in Joomla!) the isInternal() function was truely hardened.

To be clear, as the docs are not, the redirect url MUST be an internal url, it MUST start with index.php? and be a non-sef url.

Examples:
index.php?option=com_content&view=article&id=38

Incorrect examples of a redirect url:
http://bbc.co.uk/
http://mysite.com/blog
/blog

Yes these might have worked in the past - but that was due to a bug in the way Joomla validated the urls. Now that security has been applied and the urls tested correctly the above examples will fail.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

My tests with Joomla 3.4.6 (NOT staging) using the test sample data

  1. index.php?option=com_content&view=article&id=38
    Works correctly
  2. index.php/park-home
    Redirects to index.php/parks-home/login with a 404
  3. /park-home (with full sef enabled)
    Redirects to /user-profile/profile

This undocumented change has now broken existing web sites which were setup
correctly

On 15 December 2015 at 09:03, Brian Teeman brian@teeman.net wrote:

Thanks I will retest with a non-sef url. Can you also test with a sef url

On 15 December 2015 at 08:51, infograf768 notifications@github.com
wrote:

I used something like (Sample Sites in sample sql)
index.php?option=com_content&view=article&id=38

tested on an updated 3.4.5 and I had no issue, whether before killing the
session or logging with another browser where no session was set.


Reply to this email directly or view it on GitHub
#8689 (comment)
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

@brianteeman what you were relying on in the past was Joomla allowing incorrect handling of the passed url to the redirect param. What has now happened is that its been "fixed" to work correctly and the security bug you were relying on in the past has been fixed.

The redirect url should be an internal url starting with index.php. This has always been the case, but due to a security bug, other input has worked.

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

Please see the examples and unit tests at the bottom of this file:
https://github.com/joomla/joomla-cms/blob/staging/tests/unit/suites/libraries/joomla/uri/JURITest.php

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

As stated in my example a url with index.php/parks-home did not work - that
type of url is not in the unit tests

You may say it has always been the case that a non-sef url should be used
and it was a bug that you could. I dont really care about that

What I care about is that existing web sites that were working perfectly
have now been broken. There is nothing in the release notes to say that.
The tooltip for the "link" does not state that you must use a non-sef url
etc etc

On 15 December 2015 at 09:17, Phil Taylor notifications@github.com wrote:

Please see the examples and unit tests at the bottom of this file:

https://github.com/joomla/joomla-cms/blob/staging/tests/unit/suites/libraries/joomla/uri/JURITest.php


Reply to this email directly or view it on GitHub
#8689 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

It would have been easier if the redirect link in the menu item was the same as in the login module which does NOT ask for a url but presents a dropdown select of available menu items to redirect to.

Thats much easier to use but his will still mean that anyone using a redirect will have to update their link

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

I agree further work on communicating should be done - however the tool tip states that it should be an internal url and not an external one.

In Joomla 3.5.6 you select the login/logout redirection URL from a dropdown in the module - without any typing - in the module, however I see now that when you create a menu item to the login page, the options allow you to type in anything you like - although the tool tip states it must be internal and not external there is little other assistance.

The fix was to fix a security issue

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

I have added another test for partial SEF and it tests correctly as an internal URL so your bug is not related to the changes made to the JUri::isInternal function.

     * Test hardening of JUri::isInternal against non internal links
     *
     * @return void
     *
     * @covers JUri::isInternal
     */
    public function testPartialSEF()
    {
        $this->assertTrue(
            $this->object->isInternal('index.php/parks-home'),
            'index.php/parks-home should be internal'
        );
    }
@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

The fix was to fix a security issue

doesnt change the fact that it has broken existing web sites

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

No, it has fixed a security issue that you were relying on - there is a huge difference.

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

@Klipper can you please provide the examples of the URLS that you have set manually as your redirect url, as well as telling me if they are the login or logout redirection urls please.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

Thinking aloud
Isnt is possible for Joomla! to try to unwrap the SEF URL to non-SEF before redirection and THEN perform the isInternal() check.

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

yes - although this has never been a feature, and if the plan is to move to a "select menu item to redirect to from the dropdown" then it would not be a needed feature.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

It cant be a plan as it would break backwards compatibility but then you
just did that with your untested code

On 15 December 2015 at 09:45, Phil Taylor notifications@github.com wrote:

yes - although this has never been a feature, and if the plan is to move
to a "select menu item to redirect to from the dropdown" then it would not
be a needed feature.


Reply to this email directly or view it on GitHub
#8689 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

The code was tested Brian, by several humans, and came with full unit tests both before and after refactoring of the 3 lines of code.

The security issue reported was resolved and the documented feature still works correctly after application of the changes. I'm sorry that you chose to rely on buggy insecure code for your redirection, however I make no excuse for coding in a secure manner - even if that breaks your choice to use the bug to your advantage.

The changes are minor - and only effect the isInternal function, and only check if the provided url is an internal one - as it has always done - but now it correctly identifies user supplied data of urls which are not internal as such - whereas before a hacker could redirect you to anywhere on the internet if they so chose.

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

Also I believe it is the case that the redirection page will become a dropdown, as this is already the case when adding a link to the Logout page as a menu item, and when editing the Login module - the only place this is not yet the case is on a Login Menu Item options.

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

I have just tested again, manually, and then with unit tests, the partial sef url "index.php/search" as the login redirection page in a menu item it works as advertised, redirecting me to index.php/search on login.

I still see no bug here, when the correct url is provided, starting with an index.php as it always should have been the case, (as thats the way the code was written).

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

Internal link - a link on my site
External link - a link on another site
On 15 Dec 2015 9:57 am, "Phil Taylor" notifications@github.com wrote:

The code was tested Brian, by several humans, and came with full unit
tests both before and after refactoring of the 3 lines of code.

The security issue reported was resolved and the documented feature still
works correctly after application of the changes. I'm sorry that you chose
to rely on buggy insecure code for your redirection, however I make no
excuse for coding in a secure manner - even if that breaks your choice to
use the bug to your advantage.

The changes are minor - and only effect the isInternal function, and only
check if the provided url is an internal one - as it has always done - but
now it correctly identifies user supplied data of urls which are not
internal as such - whereas before a hacker could redirect you to anywhere
on the internet if they so chose.


Reply to this email directly or view it on GitHub
#8689 (comment).

@markboos

This comment has been minimized.

Copy link

commented Dec 15, 2015

More like relative and absolute maybe.

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

What Im looking for here, from people, is concrete examples of urls they believe should be allowed to be used, and fail. At the moment I have not got that from the opening poster or Brian.

Not one person who tested the fix before release expressed any issues - and with full and complete unit test coverage before and after I have faith that the changes apply the security required, while at the same time allowing valid internal urls to be used as they have always been.

However if you have been relying on a security bug, and relying on the lack of filtering of user supplied information, then I make no excuse for breaking that. Joomla needs to be secure.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2015

I have provided valid internal urls that do not work any more

On 15 December 2015 at 10:32, Phil Taylor notifications@github.com wrote:

What Im looking for here, from people, is concrete examples of urls they
believe should be allowed to be used, and fail. At the moment I have not
got that from the opening poster or Brian.

Not one person who tested the fix before release expressed any issues -
and with full and complete unit test coverage before and after I have faith
that the changes apply the security required, while at the same time
allowing valid internal urls to be used as they have always been.

However if you have been relying on a security bug, and relying on the
lack of filtering of user supplied information, then I make no excuse for
breaking that. Joomla needs to be secure.


Reply to this email directly or view it on GitHub
#8689 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@mbabker

This comment has been minimized.

Copy link
Member

commented Dec 21, 2015

In the edit view the tooltip for the Default Page field starts with "Sets this menu item as the default or home page of the site." and the grid view for the menu item list uses a home column with a tooltip that says "Default".

@joomdonation

This comment has been minimized.

Copy link
Contributor

commented Dec 21, 2015

I know it is system default menu item. I just don't understand why the router return variables of system default menu item even when the given uri is even not a url of the site (like the sample URL http://google.com/abc in the sample code I wrote above)

There is also another issue with the router which I reported at #8742.

Seems our router still has some issues/bugs.

@teleputer

This comment has been minimized.

Copy link

commented Dec 22, 2015

I would just like to mention that urlencode and base64_encode both add a forward slash to the string "/index.php...." Thus when testing an decoded variables using isInternal, it will fail.

@joomdonation

This comment has been minimized.

Copy link
Contributor

commented Dec 23, 2015

OK. Today, I give it another try. Most of the code is borrowed from JRouterSite class. Below is the code:

public static function isInternal($url)
{
    $app  = JFactory::getApplication();
    $uri  = static::getInstance($url);
    $base = $uri->toString(array('scheme', 'host', 'port', 'path'));
    $host = $uri->toString(array('scheme', 'host', 'port'));

    // Validate base url
    if (stripos($base, static::base()) !== 0 && !empty($host))
    {
        return false;
    }

    // Decode URL to convert percent-encoding to unicode so that strings match when routing.
    $path = urldecode($uri->getPath());

    // Remove base path from url, in case site is in sub-folder
    $basePath = static::base(true);
    if ($basePath && JString::strpos($path, $basePath) === 0)
    {
        $path = str_replace($basePath, '', $path);
    }

    // Remove / character from the path
    $path = trim($path, '/');

    if (empty($path) || JString::strpos($path, 'index.php') === 0)
    {
        return true;
    }

    if ($app->get('sef_rewrite'))
    {
        // Remove language code if it is available in URL
        if ($app->getLanguageFilter())
        {
            $languages = JLanguageHelper::getLanguages('sef');
            $parts     = explode('/', $path);
            $sef       = $parts[0];

            if (isset($languages[$sef]))
            {
                $path     = str_replace($sef . '/', '', $path);
                $lang_tag = $languages[$sef]->lang_code;
            }
        }

        // Remove the suffix
        if ($app->get('sef_suffix'))
        {
            if ($suffix = pathinfo($path, PATHINFO_EXTENSION))
            {
                $path = str_replace('.' . $suffix, '', $path);
            }
        }

        $segments = explode('/', $path);

        if (count($segments) > 1 && $segments[0] == 'component')
        {
            $option = 'com_' . $segments[1];
            if (JComponentHelper::isEnabled($option))
            {
                return true;
            }
        }
        else
        {
            $items           = $app->getMenu()->getMenu();
            $route_lowercase = JString::strtolower($path);

            foreach ($items as $item)
            {
                if ($item->route && JString::strpos($route_lowercase . '/', $item->route . '/') === 0 && $item->type != 'menulink')
                {
                    // Usual method for non-multilingual site.
                    if (!$app->getLanguageFilter())
                    {
                        return true;
                    }
                    // Multilingual site.
                    elseif ($item->language == '*' || $item->language == $lang_tag)
                    {
                        return true;
                    }
                }
            }
        }
    }

    return false;
}

The base url must he validated. I use the code from Joomla 3.4.5

if (stripos($base, static::base()) !== 0 && !empty($host))
{
        return false;
}

Could @PhilETaylor helps review that part to see whether it is secure? If not, could you please help with the code to make sure that part (base url) validated properly ?

The path of given URL also must be validated:

  • The / character is removed (using trim command) before the path is checked. So index.php, /index.php, or /index.php/ is the same
  • If path starts with index.php, the url is internal url. This is the same with the original implementation of this method
  • If the URL is a SEF URL:
  • If the site is a multilingual website, the path starts with language-code/menu-item-alias/sub-menu-item-alias to be an internal url.
  • If the site is a single language website, the url must has path starts with menu-item-alias/sub-menu-item-alias to be an internal url
  • The special sef url component/content/article/1 is also considered as a valid internal URL

I think it covers most of the cases we discussed so far. Hope to receive feedback so that we can implement this method properly.

@infograf768

This comment has been minimized.

Copy link
Member

commented Dec 25, 2015

@joomdonation
I tested your proposed code here.
On a monolanguage site:
I used as redirect

article-category-list/73-nouveaupour-testmail.html

But my test site is in a folder, therefore I get a 404 as the link obtained on login redirection is

http://localhost:8888/article-category-list/73-nouveaupour-testmail.html

instead of

http://localhost:8888/trunkgitnew/article-category-list/73-nouveaupour-testmail.html

Now, concerning multilingual:
we just do not use the redirections set in the login module or login menu item.
see the method onUserLogin:
https://github.com/joomla/joomla-cms/blob/staging/plugins/system/languagefilter/languagefilter.php#L518-L595

As these depend on the user preferred site language and if login from an associated item or not.

@joomdonation

This comment has been minimized.

Copy link
Contributor

commented Dec 25, 2015

@infograf768 : The code I proposed only used to check if the given URL is internal or not. It doesn't handle the redirection. The redirection is handled by different code https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/application/web.php#L479

From what I can see from the code, the redirect method doesn't handle redirection properly when your site is in a sub-folder. But that's a different issue.

@skurvish

This comment has been minimized.

Copy link

commented Jan 10, 2016

Where are we on this? I am postponing my upgrade to 3.4.6 and beyond as I know this is an issue on my sites.

@PhilETaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2016

@skurvish No changes are planned to this for the Joomla 3.4.x series. Postponing your upgrade to Joomla 3.4.8 puts your Joomla site the situation where you will be hacked running Joomla 3.4.6 - if you dont like these changes you should still upgrade to Joomla 3.4.8 and then just change the core code you dont like to suit your own needs - afterall its open source and free (free as in freedom).

@skurvish

This comment has been minimized.

Copy link

commented Jan 11, 2016

True, but then I am left with core changes I have to manage for every J! update.

@kerstyn

This comment has been minimized.

Copy link

commented Jan 22, 2016

Please can someone provide simple instructions of how to fix this issue for those of us who have upgraded and now are struggling. I think that I have tried with both internal and external URLS (not completely sure I understand the difference), neither work. My tests are documented here: http://forum.joomla.org/viewtopic.php?f=708&t=904115&p=3358221#p3358221

Thanks.

@artisandawn

This comment has been minimized.

Copy link

commented Jan 23, 2016

I am experiencing the same problem (Joomla 3.4.8), has a solution been determined? If so, please provide clear instructions on how to fix the issue.
Thanks so much,
Dawn

@jcata

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2016

Hi,
I'm experiencing the same problem in Joomla 3.4.8 , and the trouble is in JUri::isInternal($data['return']) that detect

JURI::base(); -> http://localhost/torresbus/
$data['return'] -> /torresbus/index.php?option=com_buses&task=travel.procesdata

for JUri::isInternal($data['return']) is false, before update it works ok.

thanks a lot

@joomdonation

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2016

I proposed a PR fixes this issue #9069. Could you (users had this issue) help testing the PR?

@mannybiker

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2016

@infograf768, you inform us that

we just do not use the redirections set in the login module or login menu item.

Could something like this be considered inside the languagefilter.php, after line 552 in order to take into account the redirection parameter when the system have to automatically change the language after the user login?

if (is_null($this->app->getUserState('users.login.form.return'))) {
    // Try to get association from the current active menu item
    $active = $menu->getActive();
} else {
    $active = $menu->getItems( 'link', $this->app->getUserState('users.login.form.return'))[0];
}
$foundAssociation = false;

The problem is that without this implementation the redirect parameter in the login menu is ignored and if you use the "Login menu for guest and Logout menu for registered" setup method, without a correct redirect you will see the error "You are not authorised to view this resource".

@infograf768

This comment has been minimized.

Copy link
Member

commented Mar 23, 2016

@mannybiker

Not sure I understand,
anyhow this code $this->app->getUserState('users.login.form.return'))[0] throw a parse error

@ggppdk

This comment has been minimized.

Copy link
Contributor

commented Mar 23, 2016

A question why URLs inside database configuration should be checked by isInternal()?

  • if the database was hacked, then the site is hacked already
  • maybe we can set a flag inside the session if the URL is coming from DB ???

otherwise the code of components and modules / etc could be updated to get the redirect URL from DB (if such configuration exists) and use it when the isInternal() check for return URL (that comes from session) is not passing the check

@mannybiker

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2016

@infograf768 Sorry for my unclear explanation.
It is a well discussed problem, when you have to create a menu with login and logout link, where you want the login link to be only visible for guests and the logout only to registered users. To avoid raising "You are not authorised to view this resource" you need to redirect the users to a valid page after the login otherwise the CMS try to redirect him to the same login page that is no more available since the user is now identified as registered. Here the vital need to have the redirect parameter of com_users working also when languagefilter plugin is enabled on a MultiLanguage site, but as you said "we just do not use the redirections set in the login module" in case of MultiLanguage.

The return url is set in the users.login.form.return register key before executing the onUserLogin in the languagefilter, but the setUserState used in that method overwrite the redirect parameter set in the com_users. For this reasons I used the getUserState('users.login.form.return') to read if there is already a value and if it is, I use that one. I did not test all the cases, for sure it is just a hack I needed to apply, but the code I posted should work since I am using it. But pay attention, it is not
$this->app->getUserState('users.login.form.return'))[0] but
$menu->getItems( 'link', $this->app->getUserState('users.login.form.return'))[0];
the [0] is for the array getItems returns, moreover this way you would have a ")" in ")[0]" that is not opened anywhere :)

@infograf768

This comment has been minimized.

Copy link
Member

commented Mar 26, 2016

$menu->getItems( 'link', $this->app->getUserState('users.login.form.return'))[0];

returns a parse error on PHP 5.3.x. I just corrected a similar code ;)
see #9562
Not a big deal. Will test again your proposal.

@infograf768

This comment has been minimized.

Copy link
Member

commented Mar 26, 2016

@mannybiker
hmm, can't test here, I also have errors on php 5.4.4 when I try to dump. Please create a PR and explain how to test in details including the pages set for guest and registered and the settings in mod_login. Use screenshots to clarify.

@brianteeman

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2016

Closed as this has been continued elsewhere


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8689.

@infograf768

This comment has been minimized.

Copy link
Member

commented Apr 16, 2016

@PhilETaylor
Unwanted consequence of this: it breaks login to read more as the return uses JRoute(). We are redirected to the user profile instead of the article.:
#9846

@adambako

This comment has been minimized.

Copy link

commented Jun 23, 2016

if you close this, why i still have this issue on joomla 3.5.1?

no matter if i use sef or non-sef url redirect after login dont work and it always open user profile page..

@infograf768

This comment has been minimized.

Copy link
Member

commented Jun 23, 2016

The bug has been solved (for core templates) in
#9959

and will be available in 3.6.0 release.

Look at the code there and modify your template to fit.

@laoneo

This comment has been minimized.

Copy link
Member

commented Jun 23, 2016

Should we not route the links anymore in our extensions or what?

@infograf768

This comment has been minimized.

Copy link
Member

commented Jun 23, 2016

As far as I know, it concerns only "return" when JUri::isInternal() is used.

@Mocha365

This comment has been minimized.

Copy link

commented Jul 27, 2016

Hopefully this will help...and for the record, when I was using the earlier versions, I recall that logging out did work and would end up on the home page as it should. But over the last while, I noticed this is no longer happening. Here are my results and testing (local testing environment). So it appears it's not quite fixed in 3.6.

LIVE SITE Logout with SEF on and I am using Joomla 3.6
https://www.shapedpixels.com/index.php?option=com_users&task=user.logout&735f809f209e3857bbbaf3d005e96f8a=1&return=L3N1cHBvcnQK

Here is what happens to me...my test local site on XAMPP using the core login menu item link as well as the login module. I am using the default Joomla template, not my own.

Menu Item - Login Page with SEF off
I click on the menu item, takes me to the login page, I then login. I get redirected to my page that I set (this works).
I click on the menu item "Login" again. Takes me to the logout page. I click the logout button. I am redirected to the home page (this works).

Menu Item - Login Page with SEF on
I click on the menu item, takes me to the login page, I then login. I get redirected to my page that I set (this works).
I click on the menu item "Login" again. Takes me to the logout page. I click the logout button. I am redirected to the home page (this works).

Login Module - Login Page with SEF off
I click on login on the module. I get redirected to the Members Home page (this works)
I click on the Logout button on the module. I stay on the page I logged on (although now it's blank without content.) (breadcrumbs say "Home":

Login Module - Login Page with SEF on
I click on login on the module. I get redirected to the Members Home page (this works)
I click on the Logout button on the module. I stay on the page I logged on (although now it's blank without content.) (breadcrumbs say "Home":
I also noticed that menu items set for "Registered" are still shown in my menu. But if I click on one, I have to log in.

Using the Extension Quick Logout with a Menu Item - Login to the Login page and I have SEF off
I click on the menu item, takes me to the login page, I then login. I get redirected to my page that I set (this works).
I click on the menu item "Logoout". It logs me out to some crazy URL that gives a page without content (breadcrumbs say "Home":
http://localhost/joomla/index.php?option=com_users&task=user.logout&aa95e57f38e43844435ec7b260f4cce7=1&return=L2pvb21sYS9pbmRleC5waHA/b3B0aW9uPWNvbV9jb250ZW50JnZpZXc9ZmVhdHVyZWQmSXRlbWlkPTEwMQo=

Using the extension Quick Logoout with a menu Item - Logout and I have SEF on
I click on the menu item, takes me to the login page, I then login. I get redirected to my page that I set (this works).
I click on the menu item "Logoout". It logs me out to some crazy URL that gives a page without content (breadcrumbs say "Home":
http://localhost/joomla/index.php?option=com_users&task=user.logout&3c8e9a2830407b11319a7f0b8cbf2937=1&return=L2pvb21sYS8K

Possibly related, but if I set the login menu item as Internal URL instead of Menu Item, I set the urls using dynamic structure:

Login:
index.php?option=com_content&view=article&Itemid=9

Logout:
/
But I also tried this:
index.php?option=com_content&view=featured

After saving, I get this Warning:
Only one of the login redirect fields should have a value.
Only one of the logout redirect fields should have a value.

Then everything gets set back to default settings prior to my changing to use Internal.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8689.

@mannybiker

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2016

@Mocha365 You need to clear the textfield of the custom URL or to select Default in the listbox to use the relative opposite option and save without errors.

For the Logout plugin you are right, the new modifications break the plugin, but since this is not part of the core of Joomla I do not think this should be the right place to talking about. Instead the author of the plugin could be asked about it, if he is still intentioned in updating his script.

In any case something like this should fix the problem if you are using the new redirect feature via the menu item selection, in the login module:

change this in the quicklogout.php file:
This line
$url = JUri::getInstance(JURI::base())->toString(array('scheme','host')).JRoute::_($item->link . '&Itemid=' . $item->id,false);
with this
$url = $params->get("quick_logout_redirect");

and

$loloc .= base64_encode( htmlspecialchars_decode( $url )."\n" );
with this
$loloc .= base64_encode( htmlspecialchars_decode( $url ));

@capsites

This comment has been minimized.

Copy link

commented Aug 31, 2016

I experienced this issue on an Intranet site we have setup with Single Sign On. My frontend editors have a link to 'logout' so they can see pages the same as other users (without unpublished articles). After an update from 3.4.1 to 3.6.2 they were no longer able to logout. Clicking on the logout link, then logout button went as usual and did not produce any errors on the site or in logs, but the user remained logged in.

After a few days of banging my head against the wall I found this issue tracker and decided to experiment with my logout URL in the menu item 'options' tab. The original URL i was using was "/index.php?nosso=2". In the end I simply removed the leading slash so it was "index.php?nosso=2" and my problem is resolved.

I'm glad that work was done to improve security, but it took days of searching to find that this was the root cause. Communication is key.

Thanks,
Nick


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8689.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.