-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix blocking last logins fetching #5880
Fix blocking last logins fetching #5880
Conversation
51ebcec
to
6ba2459
Compare
Thanks. It does seem like eliminating the bella.network requests significantly speeds up the login. |
https://dfdata.bella.network/:
maybe we should use also use the country Endpoint, or do we need the other infos? |
I tried the endpoint, it doesn't seem to work with IPv6 sadly... |
maybe @Thomas2500 can say something about IPv6 and maybe the speed? |
Improves performance of mailcow#5880
Hello @T0biii and @PierrePlt! Regarding the speed of the API: |
Will fixed within next release. Thanks to @Thomas2500 |
It most likely won't be fixed in the next release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my side it looks fine. Sorry for closing this to early that were two seperate things for the same topic...
(Probably)Fixes #5645
The problem was that fetching the last logins source IP's country of origin can sometime take a LONG time (up to a few minutes depending on the speed of the requests to
dfdata.bella.network
).When the country <-> IP relationship isn't cached, this can cause the /user page to take from a few seconds to a few minutes to load for users with a long connection history.
This was caused by a variable declared in
headers.inc.php
that was never used.Removing this variable solves the issue with loading the
/user
page but when changing tab the user would still be confronted by a long loading time since the background request toapi/v1/get/last-login
would block the loading of other pages.The second fix is to only load the last logins when the recent logins menu is loaded.
Not sure if this is the issue the original author had, but this fixes the issue discussed on #5645 on the last few days
Known issue: When
IP_SHORTCOUNTRY
is not cached, opening the/user
page, sliding down until the recent logins section is visible, and then opening another tab needing to make an API request will confront the user with a longer than usual waiting time since the request made by the second tab will be blocked by the request toapi/v1/get/last-login