Output debug info only to logged-in users

jakob · 2016-10-16 18:55:03

I like the idea a lot of having the debug infos show when logged in without exposing it to the outside world.

makss wrote #302240:

It is not always possible to identify the user logged on(txp cookie). For example in the multisite installation is impossible.

I have a tentative suggestion for multi-site setups that resolves that problem along with several other anomalies of the multi-site installation process. It’s for v4.6 beta 3 so not quite up-to-date with the latest version but I’ve been trialling it for a while now with a multi-site installation located parallel to the textpattern directory.

etc · 2016-10-16 19:38:16

jakob wrote #302247:

I have a tentative suggestion for multi-site setups that resolves that problem along with several other anomalies of the multi-site installation process.

Interesting, thank you. Unfortunately, I ignore most of multi-site setup subtleties, but will test.

makss · 2016-10-16 20:18:52

Another option: Debugging only for me.

In the admin interface display `magic link` after clicking on which set a `magic_debug_cookie`.
Only for this cookie(browser) enable debug mode. The whole site can continue to work normally (‘live’ mode).

I do not want to become attached to the authorization Textpattern, so I suggest creating a separate `magic_debug_cookie`.
For security, can create one-time debugging keys (link/cookie) and to limit the lifetime of the cookie.

Last edited by makss (2016-10-16 20:24:56)

maverick · 2016-10-16 23:08:12

Just an fyi/fwiw in case you want to see how one of the “other guys” do it. Symphony CMS drew some inspiration from Textpattern early on in its development. Maybe it can return a spark of inspiration :)

Symphony CMS DevKits Extensions

(edited for grammar)

Last edited by maverick (2016-10-20 14:47:35)

colak · 2016-10-17 04:37:14

makss wrote #302250:

Another option: Debugging only for me.

+1. Putting the site in debug mode also allows the community to diagnose problems and offer help. As such ‘Debugging only for me.’ should be followed by ‘Debugging visible to everyone’ which is our current way of working.

makss · 2016-10-17 05:59:30

colak wrote #302253:

Putting the site in debug mode also allows the community to diagnose problems and offer help. As such ‘Debugging only for me.’ should be followed by ‘Debugging visible to everyone’ which is our current way of working.

Yes, of course. All modes(live, testing, debug) will work without any changes.
I propose to add a separate `magic_debug_cookie`. If the cookie is set, the output in the debug mode.

Bloke · 2016-10-17 07:57:54

makss wrote #302254:

All modes(live, testing, debug) will work without any changes. I propose to add a separate `magic_debug_cookie`. If the cookie is set, the output in the debug mode.

We’d also need a way to turn it off though, i.e clear the cookie. Otherwise, if you want to return to normal operation in the same session, you’d have to hunt the cookie down and delete it manually. Restarting the browser doesn’t necessarily clear the session, as it remains attached for some time afterwards (30 mins, an hour, browser dependent).

I kinda like the symphony approach because it keeps everything separated, but it’s a bit of a hassle having to install a dev pack first. Also, once installed, if you forget to uninstall/disable it, anybody can add ?debug to the URL and potentially reveal sensitive information.

I like our current system, but having some way to keep the front-end “clean” to visitors while allowing me to dump system info and play with new forms on a live site would be a bonus. Yes it should be done in a staging area, but that’s not always desirable for quick modifications.

Sometimes I temporarily add a new Hidden article called ‘Admin only’ or something and put debug info in there as it’s only available to logged-in users and doesn’t show up front-side. But that’s no good if you’re testing tweaks to Pages/Forms and want to see, for example, whether a plugin is going to work to output some additional info. That’s why I’d like some way to markup my code so I could drop in tags that don’t show up to regular visitors. Like a <txp:debug>...</txp:debug> tag pair, inside which I can drop whatever I want and only I or other privileged users can see it.

etc · 2016-10-17 08:58:28

Wow, I didn’t mean to open a Pandora box, but all ideas are really interesting. Anyway, whatever core solution we choose, it should work in every setup. I’m currently illiterate in multi-site settings, anyone seeing how to do it please share. Meanwhile, this tiny plugin should work for “traditional” setups:

# Name: etc_private_debug v0.1 
# Type: Public plugin
# 
# Author: 
# URL: 
# Recommended load order: 1

# .....................................................................
# This is a plugin for Textpattern CMS - http://textpattern.com/
# To install: textpattern > admin > plugins
# Paste the following text into the 'Install plugin' box:
# .....................................................................

YToxMTp7czo0OiJuYW1lIjtzOjE3OiJldGNfcHJpdmF0ZV9kZWJ1ZyI7czo2OiJhdXRob3Ii
O3M6MDoiIjtzOjEwOiJhdXRob3JfdXJpIjtzOjA6IiI7czo3OiJ2ZXJzaW9uIjtzOjM6IjAu
MSI7czoxMToiZGVzY3JpcHRpb24iO3M6MDoiIjtzOjQ6ImNvZGUiO3M6MTQ5OiJnbG9iYWwg
JHByb2R1Y3Rpb25fc3RhdHVzOw0KDQppZiAoJHByb2R1Y3Rpb25fc3RhdHVzICE9ICdsaXZl
JyAmJiAhaXNfbG9nZ2VkX2luKCkpIHsNCiAgICAkcHJvZHVjdGlvbl9zdGF0dXMgPSAnbGl2
ZSc7DQogICAgVHJhY2U6OnNldFF1aWV0KHRydWUpOw0KfSI7czo0OiJ0eXBlIjtzOjE6IjAi
O3M6NToib3JkZXIiO3M6MToiMSI7czo1OiJmbGFncyI7czoxOiIwIjtzOjQ6ImhlbHAiO2I6
MDtzOjM6Im1kNSI7czozMjoiYTMxYWNmYmRhOWFhMzVmODdjZjljOTJiNDE2ZTI3ZjMiO30=

If enabled, it should hide (most) debugging info from the outside world. To restore the standard behavior, just disable the plugin.

Last edited by etc (2016-10-17 14:37:28)

ruud · 2016-10-17 14:06:48

Tiny indeed!
Can you change abc_ to etc_ please?

etc · 2016-10-17 14:40:32

ruud wrote #302262:

Tiny indeed!
Can you change abc_ to etc_ please?

Sure, if it stops nobody from modifying whatever he wants.

etc · 2018-11-03 20:17:46

I revisit this topic in 4.7 context, being still skeptic about revealing sites structure to everybody.

makss wrote #302240:

It is not always possible to identify the user logged on(txp cookie). For example in the multisite installation is impossible.

It looks like this is no more the case in 4.7, thanks to @jakob patch?

Bloke wrote #302255:

I’d like some way to markup my code so I could drop in tags that don’t show up to regular visitors. Like a <txp:debug>...</txp:debug> tag pair, inside which I can drop whatever I want and only I or other privileged users can see it.

Now we have <txp:if_logged_in /> for this, but the general debugging info is still accessible to everybody.

So, is it ok to switch unlogged users to testing in debug mode? This way the eventual errors would still be displayed, but not the tag structure in the page source. Note that this does not need an extra db query, since in 4.7 we call is_logged_in() for dev theme preview anyway.

colak · 2018-11-04 05:57:54

When I think about security, I agree with you.
When I think about how many problems were solved by people in this forum just by checking the debug screen, I don’t.

I’m wondering if there is a goldilocks method.

Textpattern CMS

Textpattern CMS support forum

#13 2016-10-16 18:55:03

Re: Output debug info only to logged-in users

makss wrote #302240:

#14 2016-10-16 19:38:16

Re: Output debug info only to logged-in users

jakob wrote #302247:

#15 2016-10-16 20:18:52

Re: Output debug info only to logged-in users

#16 2016-10-16 23:08:12

Re: Output debug info only to logged-in users

#17 2016-10-17 04:37:14

Re: Output debug info only to logged-in users

makss wrote #302250:

#18 2016-10-17 05:59:30

Re: Output debug info only to logged-in users

colak wrote #302253:

#19 2016-10-17 07:57:54

Re: Output debug info only to logged-in users

makss wrote #302254:

#20 2016-10-17 08:58:28

Re: Output debug info only to logged-in users

#21 2016-10-17 14:06:48

Re: Output debug info only to logged-in users

#22 2016-10-17 14:40:32

Re: Output debug info only to logged-in users

ruud wrote #302262:

#23 2018-11-03 20:17:46

Re: Output debug info only to logged-in users

makss wrote #302240:

Bloke wrote #302255:

#24 2018-11-04 05:57:54

Re: Output debug info only to logged-in users

Board footer