Should you use JDatabaseQuery to build the query instead of hard-coding it? Otherwise, will the query work with other databases?

@dextercowley yep. I've just copy default query to fix error. I'll replace to JDatabaseQuery :)
Need to change on others routers too.

@dextercowley done.

@dextercowley I've updated all routers to use JDatabaseQuery

Tracker issue:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=29428

With this fix: what happens if you rename the article alias from the backend?

Q: Should the old links keep up working?

@mahagr No, they get recent alias field in db. So if you change You should get a error/404 page.

In my humble opinion breaking all the links from Google isn't that good idea administrator decides to change the alias -- at least not if the behaviour was different before and there's a way to find out article ID.

There's also another major drawback on this fix -- I've seen many URLs from coming from both older versions of Joomla and other extensions that do not add alias to the article name. So your change is likely to break a few links which were working before.

Better way to deal with the issue would force redirect if the URL of the article isn't correct (e.g. was renamed or the generated link was missing alias).

@mahagr I think that you misunderstood what this patch does. It doesn't break anything, just fixes the expected behaviour of the content URLs.

If you change the alias of an article is because you want to change the URL. You can keep the old alias or if you want to change the alias and keep the old URL working you should create a redirection from the old url to the new URL.

Extensions should use JRoute to generate valid URLs. Don't fix a bug because some extensions are badly programmed has no sense to me.

We are almost there Júlio.

I have added two files Joomla! standards validation as example of remaining issues. Available if needed to help you to setup CodeSniffer working.

@phproberto please check.

Using just JRoute doesn't work. By default it generates URLs without slugs in it. In order to get aliases right, you need to know exactly how to do that -- including ContentHelperRoute::getArticleRoute() call with 'id:slug' format in the parameters.

Most people do not know how to do that as there's no documentation on it. And the rest of us have just copied the code from Joomla. But I've observed some cases when alias doesn't get added to the article name even if it should -- in other sites the same code is working.

@mahagr

ContentHelperRoute::getArticleRoute() function receives article id and category id as parameters:

public static function getArticleRoute($id, $catid = 0, $language = 0)

Not so hard to understand. But even if you do something:

JRoute::_('index.php?option=com_content&view=article&id=22');

It still generates an ugly URL like "component/content/article?id=22" that works perfectly.

Receiving only the article id like:

require_once JPATH_SITE.'/components/com_content/helpers/route.php';
JRoute::_(ContentHelperRoute::getArticleRoute(22));

Can generate the correct SEF URL that works.

Changing that SEF URL is what this patch checks and should not be allowed if you don't define a custom redirection.

@juliopontes

Applying the current patch fails (another missing ";" ). You should check the patch before commiting.

Also you fixed a few errors but you reintroduced standard validation errors :( This is going to be ethernal if you don't setup codeSniffer.

Do you want me to make a pull request into your commit to fix remaining issues?

@phproberto yep, please help me.

move pull for #505

Hi

With Joomla 3.4.8 you can still forge wrong urls :

This is a potential security issue with Joomla! As it is very easy to show I'm quite sure it's already known and possibly solved somehow.

On a basic Joomla! 3 site, without any extension, nor any .htaccess file, let's just create a few articles and a blog of the articles of the category menu item.

The url is as expected my_domain/index.php/mylist and for each article: my_domain/index.php/mylist/id-myarticle

However if I force the url this way : my_domain/keyword1/index.php/mylist/id-myarticle I don't get a 404 error page as expected but the same content as my_domain/index.php/mylist/id-myarticle !!

If you ctrl-u the newly forged page you see "keyword1" several times on the page.

This is a potential security / reputation threat when you replace "keyword1" with porn keyword!

Of course these pages don't really exist on the server but if a hacker creates such links from another site, the Googlebots can come and crawl these links and ... index the forged urls

thanks

cyril

It might be many things but it certainly not a security issue

Hi Brian

It may be because if a hacker creates another site with these forged urls to you site, when the googleBots crawl the hacker site they will crawl back these wrong urls to your site.

Since there is no 404 the forged urls are considered as valid and the robot will index these forged pages.

Cyril

URL spoofing, while massively annoying and leading to other issues, is not a security issue. Otherwise Amazon is full of security holes because of social engineering attacks that try to spoof their website.

Ok but even if you don't call it a security issue do we agree that for the final site owner he feels his site has been hacked with wrong contents at least on the google pages ?

Unless I forget something here all theses wrong urls give real pages with real contents (CTRL-u) in the google index and this is what is important for most users

cyril

Your example does not work
domain.com/keyword1/index.php/mylist/id-myarticle
will give a 404

There are other ways to spoof a url but thats not one

On 8 March 2016 at 16:27, Pulsar Informatique notifications@github.com
wrote:

Ok but even if you don't call it a security issue do we agree that for the
final site owner he feels his site has been hacked with wrong contents at
least on the google pages ?

Unless I forget something here all theses wrong urls give real pages with
real contents (CTRL-u) in the google index and this is what is important
for most users

cyril

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

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

And through mechanisms such as canonical URLs, sitemaps, and robots.txt directives, these "fake URLs" don't get indexed. Yes, it may be annoying that for a com_content article with ID 1 assigned as your homepage you could access it through /index.php?option=com_content&view=article&id=1, /component/content/article/1, or / (the latter if you've enabled SEF URLs and/or URL rewriting), but internally to Joomla if you have things configured right the canonical URL that gets spit out into the <head> section tells platforms like Google "this is the 'proper' URL for this page, no matter how you got to it".

Brian
I confirm that domain.com/keyword/index.php/mylist/id-myarticle DOESN'T give a 404 but displays the same as domain.com/index.php/mylist/id-myarticle

Cyril

Yes Michael, I think you are right. Since we can tell which url is the cannonical one for Google, other wrong forged urls won't be indexed!

Something else: can we set a cannonical url for a list, not only a content page ?
because the issue here is not only on content pages but also on some list pages.

Tried again and still cannot replicate your exact issue on a clean install
with no htaccess