search

rage / tmc-core-abandoned

0 stars 1 forks source link

Include helpful debugging details for paste submissions #29

Open jamo opened 10 years ago

jamo commented 10 years ago

For example include

Most of these are available from System.getProperties().

Server doesn't support this atm...

ljleppan commented 10 years ago

An initial implementation could work by writing this info to a temporary file (tmc-debug.log? ) that would be sent to the server with the paste-submission and deleted afterwards. This would allow us to essentially implement this feature without any changes to the server.

The most major problem with this implementation would be possible file name collisions but these could be mitigated by choosing a sensible file name and documenting the feature.

This "easy" implementation raises some worries about user privacy. A few possible solutions come to mind:

  1. Make a off-by-default settings variable to control whether debug data is sent.
  2. Ask the user if he would like to also send debug data before sending in the paste.
  3. Make a wholly new "send debug data" menu item that is essentially the current pastebin action with this debug data.

Of these three, I feel like options 1 would be best.

It would also be handy to allow users to use this feature to also send any log files, as discussed in #30.

jamo commented 10 years ago

I would prefer adding one more field to the submission instead of a file. JSON object containing 'private' data, which may be accessed only by administrators. (and later with better permissions, only by few persons.

jamo commented 10 years ago

And yes we need to have option for enabling/disabling this. Best solution would be using tailoring so that we can set default values for it. just like current settings for tmc-netbeans-plugin.

mpartel commented 10 years ago

Since we don't need this data in the vast majority of cases, in the interests of privacy, I vote for option 3: a new menu item for sending all of this + the netbeans logs.

Ideally there'd be a dialog where the user can preview what is being sent. At its simplest the dialog could just briefly describe what is being sent.

I guess the most personal piece of data here is the local username that is visible in paths. Not too serious IMO, although it could concievably be automatically anonymized. Anything else?

I think making a new controller + model + simple view for this shouldn't take terribly long. Stuff from the "Files" tab view can probably be reused.

ljleppan commented 10 years ago

Personally I'm most worried about the env-map, since that could potentially include API keys or other similar private or non-public information. This could be mitigated by restricting the information collected to a set of predefined environment variables, but that in turn might not be enough for all debugging needs.

Letting the user preview the information before sending sounds like a good idea. Allowing the user to edit the information (e.g. to hide some environment variables) would be optimal, but is probably too big of a hassle to implement at this point.

As for the data, at this point I'm thinking about something like this:

Any additions to the list and comments about the env map are most welcome.

mpartel commented 10 years ago

If we allow preview, making the textareas that display the info editable is probably easy.

Good point about the API keys. We could try to be slightly smart about envvars by filtering out vars like _KEY and ACCESS etc. On Nov 10, 2014 9:41 PM, "Leo Leppänen" notifications@github.com wrote:

Personally I'm most worried about the env-map, since that could potentially include API keys or other similar private or non-public information. This could be mitigated by restricting the information collected to a set of predefined environment variables, but that in turn might not be enough for all debugging needs.

Letting the user preview the information before sending sounds like a good idea. Allowing the user to edit the information (e.g. to hide some environment variables) would be optimal, but is probably too big of a hassle to implement at this point.

As for the data, at this point I'm thinking about something like this:

  • From System.getProperty():
    • java.vendor
    • java.version
    • os.arch
    • os.name
    • os.version
    • Charset.defaultCharset()
  • TMC Core version
  • TMC Client ID
  • TMC Client version
  • Parent name ("Netbeans", "Eclipse", "Mozilla Firefox")
  • Parent version
  • Environment variables map
    • Maybe just a subset?
    • IDE log file

Any additions to the list and comments about the env map are most welcome.

— Reply to this email directly or view it on GitHub https://github.com/rage/tmc-core/issues/29#issuecomment-62460366.