Details
-
Type: Sub-task
-
Status: Done/Fixed
-
Priority: Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.6
-
Fix Version/s: 4.6.12
-
Component/s: CiviCRM API, Core CiviCRM
-
Labels:
-
Documentation Required?:User and Admin Doc
-
Funding Source:Core Team Funds
Description
When discussing support issues online (via forum, stack-exchange, blog, JIRA, etc), we expect commenters to post relevant details about their configuration. This has a few gaps:
- The forums have a neat feature where you can put some details on your profile, but this doesn't carry over into any other medium, and it's liable to grow stale.
- You can only list details if you know them or feel comfortable collecting them. People often don't know details like their MySQL version or PHP version.
- If details are chosen adhoc, then you might include details which seem obviously connected to the problem. But bugs often involve details which are not obviously connected to the problem.
Of course, the most effective solution is to give other developers/implementers full access to the problem system (or to an identical test system), but that comes with huge trust/security/admin issues. The goal of this ticket is to provide some streamlined tooling to publish as much supporting information as possible while minimizing trust/security/admin issues.
My belief is that we should aim to share these details:
- Version numbers of Civi, CMS, PHP, DB
- List of add-ons in Civi, CMS, PHP
- (This list is probably incomplete, but I'm not specifically advocating any others. Feel free to comment about additions.)
My one concern about this is the potential for systematic abuse. If you tell someone "I'm having trouble, and here's the server address", then they're in a good position to attack/exploit it. If these details are freely published, then attackers could search/crawl the data and find systems running old, vulnerable software.
There are a few ways to address this, but my favorites so far are
A. Don't publish any site-identifying information (such as URLs, paths, DB names).
B. Put the details behind captcha (to keep out robots but let humans in).
C. (Maybe) Put an expiration date so that the info eventually disappears.
I flirted with the idea of putting an ACL on each site profile and allowing folks to request access (a bit like Google Doc), but this approach is more complex (for developers and users) and feels hard to justify for data which isn't truly sensitive (no identities, no credentials). Unless there's a lot of pushback or a strong counter-point, I'm inclined to just do A+B+C.
Attachments
Issue Links
- links to