First image shows incorrect data as scraped on Facebook (wrong image)

Second image shows nonsense stream item that the RSS item links to

Third image shows actual event page.

The RSS item link should really point directly to the event itself.

DM

Hello DM,

This is actually correct because when you share a stream item, it should actually link to the "action" rather than the "object". For instance, if someone were to join a group, you want others to see that person's action rather than the group.

If we were to change this behavior, imagine when there are 20 different group joins to the same group. Your feed linkage would be irrelevant since it would result into displaying 20 same group objects.

Not so, the title contains unique data about the action, but the link should take the user to view the object...

e.g.

<title>DeeEmm Joined the group EasySocial</title>

<link>http://www.itemlink.com</link>

This way each of the 20 joins to the group will display something different...

User DeeEmm joined EasySocial

User Mark joined EasySocial

User Jenny joined EasySocial

User Mick joined EasySocial

User....

Well you get my point.

The stream is just an information stream - its purpose is exactly the same as the RSS feed - to notify users of activities in the community. The stream is not the community itself. This relationship between the RSS feed and the stream is fundamentally flawed.

Basically what we currently have is an RSS feed that links to the Stream that links to the actual activity - This expects the user to click twice to get to the object that the RSS item actually refers to. This is bad practice. One click is all you should ever need. What's worse is that it does not link to the actual stream item but to some non-existent 'group' (try it - its not very good). It really does not work very well as it doesn't even work in accordance with your designed intent.

What you are promoting is the stream itself not the object, when in truth no one is interested in this. The RSS feed should mirror the contents of the stream not link to it. The RSS feed is simply another vehicle for communication, Same as the stream, or notifications, or email notifications; ultimately the user is interested in the object itself, not the stream item about the object.

DM

Hmnnnn, so I decided to write an extension to generate an RSS feed to my liking as it will probably be easier than trying to change the way that you perceive the intent of RSS. So to make a start I used the example from the developer documentation...

require_once( JPATH_ROOT . '/administrator/components/com_easysocial/includes/foundry.php' );

$data = Foundry::stream()->get( $options );

So I print_r() the output to the screen (as you do) to see what it contains and what do I see staring me in the face?

MY DATABASE USERNAME AND PASSWORD!!!

I can also see the email addresses and hashed passwords of the users that have posted to the stream items.

NOT GOOD!!!

No reason to have this data available within the stream object. An unnecessary vulnerability waiting to happen.

My expectation would be to see the stream object data and nothing else. If I want to know info about the user I will interrogate the user object. I cannot think of any reason at all to want to expose the database username and password to a class object.

Please remove this data from this object (and any other objects that have the same data).

DM

Dm, I really don't see why this as an issue at all. If you ever run the codes below, you'll see your passwords too.

$config = JFactory::getConfig();



var_dump($config);

exit;

I don't see a point in hiding these objects from the stream object because the password that you see from the stream object is from Joomla's configuration.

Hi Mark,

I apologise in advance if my manner seems harsh but it's just our Aussie way

Joomla has it's own in-built security, it is maintained and reviewed by a team much larger than yours that test for security issues before releasing updates to the public. Security exploits in Joomla are pretty rare but still do happen from time to time, security exploits in third party extensions are much more common and form 95% of all exploits.

Without meaning to sound rude, since installing EasySocial some two or three weeks ago I have lodged some 15 support tickets, many of which relate to bugs. With so many issues it appears to me that it is really only a matter of time until you have a security issue with one of your releases. There is then a possibility that this allows this object to be exposed and at the point that this happens you will be giving thousand of script kiddies free access to sensitive data without them even having to try. This is not a place that you want to visit, believe me.

It all comes down to risk management. There is really no need for this data to be returned in any of your components. There is a database abstraction layer in Joomla specifically so that you do not need to make the database calls yourself, you simply utilise Joomlas in-built JDatabase method without ever having to need to access the password or username.

All it takes is one small mistake that allows that object to be exposed and script kiddies the world over will be rubbing their hands together.

Now, don't take this the wrong way, it is not that I am saying this will ever happen, it likely will not, but if for some reason it did, the fact that you expose the configuration variables within your component means that there is a much higher potential for damage than if you did not.

In short. You do not need to expose them, so don't.

If you are not prepared to remove these variables from your data object, then the very least that you could do is obfuscate the username and PLAIN TEXT password so that in the event of a security issue they are not human readable.

Mistakes happen. Minimise your losses before the event and protect your reputation. Don't wait until after the event and think 'jeesh I wish I had taken note of that DM bloke'.

DM

Mark,

Any comment?

DM

Hi Arlex,

Thanks for the reply. I can see that the issue is not originating with ES.

I understand that it is not a security issue in itself, but if there was a security issue then the risk of exposing the database username and password is greatly increased, the risk is similar to that of using global vars.

Call me old school but that's fckd. It's not good coding practice at all. I would definitely have expected better from Joomla. The database calls should be sewn up within a private class and utilize class abstraction to allow only the methods to be exposed.

I will report over at Joomla and see what they say.

DM

Okay, keep us updated then what Joomla respond.

Will do.

Keep us updated