oh please lets not log sql queries into sql files which are set names and can be accessed with no authentication through automated means. That is a stupid idea.

And yes I know it will only happen with debug mode on... but turning debug mode off doesn't delete those files...

@joomla/security

I agree with @PhilETaylor

I agree, too.

I don't care how these files are named, extended, structured or if they are protected by a #<?php die('Forbidden.'); ?> or an additional .htaccess but logging sql queries was and is a helpful feature. E.g. if pages are redirecting. But not only in these cases where debug console is too unhandy.

From my point of view 2 files would be sufficient, one for FE, one for BE, to have the queries in a chronological order.

Just BTW: I don't would like to have an automatic deletion if debug is off.

Yes, this functionality has been removed. The good new is (or the bad - you decide..) that now not only the executed queries are written to a log file, but also every other information about the current request. This will allow the analysis of redirects for example.
The files will receive a hash file name e.g. /tmp/X63c5161546cb3ad7ba9c85bc6be7cfa3.json

@joomla/security should decide if this is a problem

@ReLater does this solve your issue?

The files will receive a hash file name e.g. /tmp/X63c5161546cb3ad7ba9c85bc6be7cfa3.json

How is a cleanup supposed to work? When are those files deleted?

Yes using md5 in a hash file name is still a security problem - there are a limited. Number of md5 hashes and these can be easily enumerated by a speedy bot

Why is it a Json file ?

Using .htaccess restriction is unacceptable as it’s platform specific

——
Sent from my iPhone - sorry - if needed I’ll send longer email from my desk later.
——

On 14 Sep 2018, at 16:16, David Jardin notifications@github.com wrote:

The files will receive a hash file name e.g. /tmp/X63c5161546cb3ad7ba9c85bc6be7cfa3.json

How is a cleanup supposed to work? When are those files deleted?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

The file writing is a feature of the debug bar package, it is not a Joomla add-on. The fact it is in the web space is a limitation of Joomla.

How is a cleanup supposed to work? When are those files deleted?

I'd say that it is the responsibility of the user/admin to manage the contents of their tmp directory. AFAIK there is nothing in Joomla! cleaning up tmp files?

Why is it a Json file ?

This is by design. We can explore other options that exist. See: http://phpdebugbar.com/docs/storage.html#storage

I'd say that it is the responsibility of the user/admin to manage the contents of their tmp directory. AFAIK there is nothing in Joomla! cleaning up tmp files?

Exactly that's the issue: our average user would never ever clean up his tmp directory, that's just not realistic.

We have the option to log executed queries in J3 as well - how do we handle those files?

We don’t.

On Fri, Sep 14, 2018 at 11:04 AM Brian Teeman notifications@github.com
wrote:

We have the option to log executed queries in J3 as well - how do we
handle those files?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#22137 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfofOxHjBIY2tsNCICLMzmAw5VQrcmks5ua9NzgaJpZM4WkUL-
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

We dont handle the files or I am mistaken and we dont have that functionality?

oh and dont forget that as of Joomla 3.9 (and not yet merged into joomla 4) we have automatic log rotation and deletion

We dont handle the files or I am mistaken and we dont have that functionality?

My image above is Joomla 3 with activated "log queries" or how it's called. Deactivated by default. The users have to delete the sql-files and they're unprotected.

does this solve your issue?

As long as it doesn't become too complicated to "unpack"/decode these files I myself can live with it or a similiar solution and are able to code a custom tool/extension.

A just "Nice to have" would be a timestamp/date at the beginnig of the file names to make orientation/ordering easier if one copies them or whatever.

@ReLater please test the "new" behaviour for handling logs in j3

I will.

As far as I see without testing only php files will be removed by log rotation https://github.com/joomla/joomla-cms/blob/staging/plugins/system/logrotation/logrotation.php#L175

And only if they are in Joomla log_path https://github.com/joomla/joomla-cms/blob/staging/plugins/system/logrotation/logrotation.php#L129

Concerning Joomla 3: Have a look please on pr #22187
Maybe just a temporary solution(?)

I agree with @PhilETaylor and all other JSST members that have expressed their concerns above.

I'm also against logging highly sensitive data such as SQL statements and POST parameters into permanent files on the server as a standard core feature. It is against many privacy regulations, including the EU GDPR.

It is imho ok to have an API for a separately installable third-party debugging plugin to log those into a more appropriate location and form than Joomla core can do.

So you are essentially saying that the debug plugin and logging API should
be removed from core because they provide tools that allows someone to
write “sensitive” data somewhere. That’s a paranoia response.

Debugging anything in Joomla that is done by another person, has a
redirect, or provides a non-HTML response is already a black box. Right
now that means core hacking or working against an environment where you
have a step debugger (ext/xdebug) installed and enabled. The debug bar
package provides a mechanism of reaching into this black box without core
hacks or being an advanced developer who can get a step debugger running.
It comes at the expense of logging data somewhere (default filesystem, the
package has out-of-the-box solutions for something like Redis or a database
on a PDO connection, or we write a custom implementation of the storage
interface).

It is an acceptable risk to provide these tools to assist in tracing
problems. What we fail to do is explain this risk and what data is created
where and how it can be purged.

It is not acceptable to further cripple the ability to debug issues on a
website or make it a task that only “senior” developers can perform.

On Fri, Sep 14, 2018 at 6:29 PM beat notifications@github.com wrote:

I agree with @PhilETaylor https://github.com/PhilETaylor and all other
JSST members that have expressed their concerns above.

I'm also against logging highly sensitive data such as SQL statements and
POST parameters into permanent files on the server as a standard core
feature. It is against many privacy regulations, including the EU GDPR.

It is imho ok to have an API for a separately installable third-party
debugging plugin to log those into a more appropriate location and form
than Joomla core can do.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#22137 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoapIcK56feI5yeu9C1URbT9Zuwucks5ubDvvgaJpZM4WkUL-
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

I agree with @mbabker
But since I believe that paranoia doesn't have to be always a bad thing, I made a PR so people can go to sleep in peace ? hopefully...

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/22137

closed as having Pull Request #22188