With the rebranding of Piwik to Matomo, this commit:

• copies the piwik module to matomo and rebrands
• notes that the piwik module is deprecated
• updates the javascript to the current Matomo version

Fixes #132

This PR fixes #117,

• moving the tests out of the analytical package and into a /tests folder,
• and simplifying setup.py, removing all test set up code.

Tests should be able to run locally, in the end. Coverage shall be submitted to coveralls from a Travis CI only.

When looking at the code when it is formatted with Black there are a number of cases where it would be a bit more readable if plain pytest asserts were used.

I've done a few files as an example. Is this wanted? Let me know what you think.

Hi Joost,

I think I've caught a subtle bug in how get_required_setting handles SETTING_DELETED.

As I understand it, when you set a settings key to SETTING_DELETED via @override_settings you intended for it to raise an AttributeError when retrieved via get_required_setting.

However, instead of raising an AttributeError in the getattr call -- as I think you intended it -- it's instead failing the regexp check. This line returns a valid DeletedSettingDescriptor object that then proceeds to raise AnalyticalException because it never matches the supplied regexp.

The end result is all the tests that rely on a missing settings key raising an AnalyticalException pass, but not for the intended reasons.

I played around with the code a bit and think I figured out a way around it. You can see the commits here: https://github.com/edavis/django-analytical/compare/master...setting-deleted

2a1e2d3f is the meat of the fix while the other two are more cosmetic but override_settings related. Basically, I check if a value is set to SETTING_DELETED and if it is I delattr it from self.default_settings which is where the value appears to come from. All the tests still pass and stepping through it with a debugger shows it raising an AttributeError as expected in the getattr call in get_required_setting.

I'm far from an expert on Django's settings machinery, but I think this should do it. If you're interested, feel free to pull from my setting-deleted branch.

A test matrix shall give us a quick answer on what broke when some jobs fail. It's a bit like writing tests: "A test should ideally do just a single thing."

This change splits up the linear test jobs, mainly defined by their Python version in use, into all Python-Django combinations we test against. Basically, we let GitHub Actions do the same thing as Tox does, when we run the test suite locally:

$ tox -l
py36-django22
py36-django30
py36-django31
py37-django22
py37-django30
py37-django31
py38-django22
py38-django30
py38-django31
py39-django22
py39-django30
py39-django31
...

This removes the check in the code that limits the Intercom widget to authenticated users. I'm not sure why the check was there: Intercom is intended for use with both anonymous and authenticated users.

This also updates the Intercom tests to add a conventional test_render_internal_ip.

I added support for GA's _setSampleRate and _setSiteSpeedSampleRate settings for my needs and then saw _setSessionCookieTimeout and _setVisitorCookieTimeout would be easy to add too.

I've updated the tests and the docs and thought it might be of interest to other developers. Thanks for this project! Steve

Hey there,

This is Steven, the guy who also added gaug.es support. This PR adds support for intercom.io, as well as fixing up some annoying inconsistent fails because of json's inconsistent dict rendering order.

Believe everything's here (tests, docs, etc), if not, ping and I'll add it quickly!

Thanks again for the great lib, -Steven

Do you plan to support Piwik? (Has this been requested before?)

An (elderly) example of JavaScript code used for Piwik is available at e.g. django-piwik-analytics

Google has in it's conditions for enabling UserID requirement, that prohibits sending personal data (such as e-mail address) to analytics. I am using e-mail address as username, so using GTag would break the requirements for me.

This enables me to set user UUID for the UserID parameter.

I am getting an error when setting a Measurement ID for GOOGLE_ANALYTICS_GTAG_PROPERTY_ID as my project uses an App+Web property.

GOOGLE_ANALYTICS_GTAG_PROPERTY_ID setting: must be a string looking like 'UA-XXXXXX-Y': 'G-XXXXXXXXXX'

I think gtag.js inherently supports both features, and the test case for this should be fixed to take both strings.

Hi!

Thanks so much for creating this repo. I'm having trouble doing basic mixpanel tracking.

I've set up my template html file to look like this:

{% load analytical %}
{% load mixpanel %}
<!DOCTYPE ... >
<html>
    <head>
        {% analytical_head_top %}

        ...

        {% analytical_head_bottom %}
    {% mixpanel %}
    </head>
    <body>
        {% analytical_body_top %}

        ...

        {% analytical_body_bottom %}
    </body>
</html>

and my settings.py file looks like:

INSTALLED_APPS = [
    ...
    'analytical',
    ...
]

I also added my MIXPANEL_API_TOKEN to settings.py as well, and I have django-analytical==3.1.0 in my requirements.txt file.

I deployed these changes to a test website, so it's in prod, not dev.

I think I must be missing something -- should I be making any other code changes to enable tracking?

Thanks!

Addition service Liveinternet. Several implementation options have been made as per the documentation:

1. in the form of a single image combining the counter and the LiveInternet logo
2. in the form of two images, one of which is a counter (transparent GIF size 1x1), and the other is the LiveInternet logo. This placement method will allow you to insert the code of the invisible counter at the beginning of the page, and the logo - where the design and content of the page allows.

The setup.cfg file contains configuration data that used to be read by tools like Tox and Sphinx.

The respective values now appear in pyproject.toml and tox.ini, and it looks like the entire file is hence obsolete.

I'm not 100% sure whether ReadTheDocs reads the file, but I guess building the docs should work just fine without it.

We have been contacted by junior security researchers who pointed out that one of our regular expressions in the Matomo module makes software using Analytical vulnerable to Regular expression Denial of Service attacks (ReDoS).

I'm publishing this information in the faith that this vulnerability cannot be exploited easily in our context, because the Matomo server URL is a configuration setting that is not user supplied.

Details

From analytical/templatetags/matomo.py, line 20:

# domain name (characters separated by a dot), optional port, optional URI path, no slash
DOMAINPATH_RE = re.compile(r'^(([^./?#@:]+\.)*[^./?#@:]+)+(:[0-9]+)?(/[^/?#@:]+)*$')

The problematic bit is the repetition (]+)+) after a piece that induces backtracking.

Anyone willing to assist in fixing this issue is very welcome! :pray:

Potential Solution Approaches

1. Simplify the regular expression (remove or limit the repetition)
2. Use urllib.parse.urlparse and/or related functions
3. A combination of 1. and 2.

Example: (note that urlparse alone seem unsuitable for our use case)

class MatomoNode(Node):
    def __init__(self):

        # avoid ReDoS vulnerability not using a regex with backtracking
        parsable_url = '//' + getattr(settings, 'MATOMO_DOMAIN_PATH', '')
        result = urlparse(parsable_url)
        if result.scheme or (not result.netloc and not result.path):
            # make this fail

Background Reading

• Cloudflare outage on July 2, 2019 (postmortem)
• OWASP attack description

posthog.com/ is an open source product analytics platform, comparable to Mixpanel. I think they'd make a great addition and would probably support an integration somehow.

Hi,

Thank you for this library! I've been using this for Google Analytics but having trouble loading user-id information there.

It seems like per Google documentation the code required to send user_id information looks like this:

gtag('config', 'G-XXXXXXXX', {'user_id': 'USER_ID'});
gtag('set', 'user_properties', { 'crm_id' : 'USER_ID' });

What the library renders is this:

gtag('set', {'user_id': 'USER_ID'});
gtag('config', 'G-XXXXXXXX');

Perhaps this is not sending the user id to GA properly? If you think this is the case, I can happily submit a PR to address this.