DirectPHP

[davidascher]

It appears that the extension "DirectPHP" has been found to be vulnerable and is now unpublished and added to the VEL. I cannot find any way to locate the developer now that all the info about this extension has been removed from the JED snd the url from where this extension used to be downloaded is either not functioning or no longer working.

What is the best way to find a similar extension to replace this? Or to locate the developer to check on their plans?

[SharkyKZ]

It can be replaced by migrating your PHP code to a proper extension. Embedding PHP code in articles is never a good idea.

[JAVesey]

What is the best way to find a similar extension to replace this? Or to locate the developer to check on their plans?

Notwithstanding @SharkyKZ’s advice above, take a look at Regular Labs’ “Sourcerer” extension.

[davidascher]

It can be replaced by migrating your PHP code to a proper extension. Embedding PHP code in articles is never a good idea.

I had been using Regular Labs "Sourcerer" extension for this purpose until I discovered DirectPHP which seemed to be a little easier to use. It sounds like you would advise against using "Sourcerer" as well. Can you explain what the issue is with embedded PHP in an article? It's not obvious to me.

Thanks

[SharkyKZ]

I don't even know where to begin. I didn't think why storing executable PHP code in a database is a terrible idea would ever need an explanation. It's a whole can of worms relating to security, stability, debugging and maintainability. Just to give an example, anyone with author/editor rights can execute PHP code. Even Pro version, which offers "Advanced Security Settings", is not secure enough. Furthermore, it's wrong to have any sort of write logic in the presentation layer. It is very likely to fail in some cases, for example, with caching enabled. For your own sake you should take some time to read extension development documentation and migrate your code to a proper extension.

[davidascher]

It sounds like you meant the issue to be putting PHP code into an article rather than putting PHP code in a database.

I have never worked with a Joomla site that allows numerous folks to add or alter content in articles. I understand that many Joomla sites are used by organizations where all the visitors to the site are all 'members' who must log in to even see the content and that many of them can provide/delete/modify content. I'm working at the opposite end, where there is typically one superuser (me) to take care of all the administrative stuff (maintaining users, extensions, updates, backups, troubleshooting, etc.) and one or possibly two users with only enough privileges to allow them to create and manage articles in a limited number of categories.

The risk of anybody misusing some php code that I've tucked into an article that only I can manage (but visitors can view), seems pretty minimal. I can understand your anxiety about this in the 'general' Joomla case, but in a very much restricted Joomla environment, I don't see the risk. I don't know how typical either extreme type of Joomla site is - and while I appreciate that Joomla can be used with such a wide range of management/usage scenarios, I hope I'm not missing something important about security.

[davidascher]

I don't even know where to begin. I didn't think why storing executable PHP code in a database is a terrible idea would ever need an explanation. It's a whole can of worms relating to security, stability, debugging and maintainability. Just to give an example, anyone with author/editor rights can execute PHP code. Even Pro version, which offers "Advanced Security Settings", is not secure enough. Furthermore, it's wrong to have any sort of write logic in the presentation layer. It is very likely to fail in some cases, for example, with caching enabled. For your own sake you should take some time to read extension development documentation and migrate your code to a proper extension.

I hope I didn't hit a raw nerve. If so, it was unintentional. AND I sincerely hope that you haven't decided to take revenge. One of the Joomla sites that I manage has been hacked pretty seriously both yesterday morning and this morning - and of course the hack involved the use of Sourcerer's "{source}" tag.

[gws]

@davidascher

AND I sincerely hope that you haven't decided to take revenge.

non of your sites are mentioned ? What you have in an article is stored in the database. If you are not comfortable with hacks there is a service available from mysites.guru , I have no affiliation with that site, the first audit is free.

[davidascher]

I should have indicated that my revenge remark was meant to be read in an ironic tone. I don't know if any emojis or shirt codes to use to indicate that.

The coincidence of the attack on the site in question and this conversation did result in a flicker of suspicion that I was being put in my place, but that was overwhelmed by my respect for those very knowledgeable folks who provide us dummies with invaluable info.

[Matt Bourne]

Have you tried to embed the code directly into this component and use the module to be embedded anywhere you wanted

https://extensions.joomla.org/extension ... r-scripts/

[davidascher]

I'll have a look at it... I presume the php script resides in a file and gets included into the article or module at run time??

thanks for the pointer.

[Matt Bourne]

I'll have a look at it... I presume the php script resides in a file and gets included into the article or module at run time??

thanks for the pointer.

It's even simpler, just paste the php or js code into the component and you can load them in their module, which you can embed into anywhere like your article and so on

I did some PHP and MYSQL integration to manipulate the existing component into another new "component" or functions, like sorting the active member login based per days and weeks or creating an unique affiliate link for each member.. you're no longer bound to the Joomla strict coding and can use the pure core php scripts inside your website

That's my opinion as a newbie here