dj-tracker UI login system

[Natgho]

How can I limit the information dj-tracker provides so that only admins can see it? a login page maybe.

[Tijani-Dia]

Hey @Natgho, there aren't authentication checks to access the dashboard as I assume people mostly use dj-tracker locally, for debugging purposes.

To do so, you could add a decorator that requires a user to be logged in. For example:

dj_trackers_urls = [path("dj-tracker/", include(dj_tracker_urls))]

urlpatterns += decorate_urlpatterns(dj_trackers_urls, require_admin_access)

You can find an implementation of decorate_urlpatterns and require_admin_access in the Wagtail source: here and here.

I hope this helps.

[Natgho]

Hi @Tijani-Dia , Thank you for your answer. I will try the method you mentioned and return.

How about adding it as built-in with a key called "login" under settings? https://tijani-dia.github.io/dj-tracker/configuration/

DJ_TRACKER = {
    "LOGIN": True # or False
}

[Tijani-Dia]

Sounds good.

That's a nice suggestion. However, as I mentioned above, I think most people use dj-tracker locally meaning they won't need authentication. I'll be happy to add it if more people request it or when dj-tracker is mature enough to be used on a production environment.

[Natgho]

Actually, the idea came from here, we realized that we were querying too many DBs query in our production environment and we wanted to determine which endpoints were querying these queries. This is how I met dj-tracker :)

I will prepare a PR to add this as built-in.

[Tijani-Dia]

Oh, interesting! Have you already used it on production without issues? It may not work nicely in a multiprocessing environment as each process has a worker thread and they can have conflicting write queries resulting in integrity errors sometimes. That's on my to-do list.

A PR (for this and anything else) would be more than welcome.

[Natgho]

Hmm, yeah, you're right. No, I haven't integrated it yet. I tried dj-tracker locally today and it worked fine. But our production environment is on k8s and works with 5+ pods. It is quite possible to encounter problems like deadlock. Tomorrow I will share this plan with my technical team leader, as far as I can see from the source code, conflicts will not block the flow of the code, only some queries may not be recorded by dj-tracker. What do you think?

I'll be sure to write about the bugs if I run it in production. So this project can move forward. I think it's a very useful app.

[Tijani-Dia]

That's exact, when an error occurs in one of the worker threads, it'll just stop recording the queries in that process. It shouldn't affect the flow at all as you said.

A quick work around the race condition issue I mentioned may be to set the ignore_conflict flag here.

Note: I have work in progress to make it work in a multiprocessing environment, hopefully I'll wrap it up soon.

Thanks!