AppData call takes longer than 5 seconds
Orscheler opened this issue · 14 comments
RainLoop version, browser, OS:
1.16.0 / Chrome & Curl
Expected behavior and actual behavior:
/?/AppData call takes longer than 5 seconds both on my local installation, as well as in the rainloop-demo
Steps to reproduce the problem:
When loading Rainloop or when changing between multiple accounts request the mentioned call is processed and slows down the usage
Logs or screenshots:
time curl 'https://mail.rainloop.net/?/AppData@no-mobile-0/0/1311346818829715/' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="97", "Chromium";v="97"' -H 'sec-ch-ua-mobile: ?0' -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36' -H 'sec-ch-ua-platform: "Windows"' -H 'Accept: */*' -H 'Sec-Fetch-Site: same-origin' -H 'Sec-Fetch-Mode: no-cors' -H 'Sec-Fetch-Dest: script' -H 'Referer: https://mail.rainloop.net/' -H 'Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7' -H 'Cookie: _ga=GA1.2.75753229.1643485940; _gid=GA1.2.1067139009.1643485940; rltoken=55280dad41c41b63e910ccafd677fbcc; _ga=GA1.3.75753229.1643485940; _gid=GA1.3.1067139009.1643485940; _gat=1' --silent --output /dev/null
real 0m5.688s
user 0m0.109s
sys 0m0.030s
Yes I also observe this on both of my servers.
Somehow I assume it could be related to Subscription server on their side. As if you go to Admin Panel -> Licensing
(Keep in mind that this is my wild guess)
it is possible it is actually the same as issue #2160 - on login page, for some reason, there is a curl to http://api.rainloop.net/status/FQDN
as api.rainloop.net seems dead, it incurs a timeout.
The question is why api.rainloop.net is even called at every login. I was not aware, when installing the server that it would make such call to a distant server.
I am not sure to understand clearly the potential privacy issues here.
As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.
it is possible it is actually the same as issue #2160 - on login page, for some reason, there is a curl to http://api.rainloop.net/status/FQDN
as api.rainloop.net seems dead, it incurs a timeout.
The question is why api.rainloop.net is even called at every login. I was not aware, when installing the server that it would make such call to a distant server. I am not sure to understand clearly the potential privacy issues here.
I can confirm it is the same issue.
These requests are related to subscription status verification:
http://api.rainloop.net/status/FQDN- checks the subscription status for FQDN. Expects one of the following responses:- NO - no subscription found
- EXPIRED:timestamp - subscription found, valid until timestamp
- EXPIRED:1898625600 or EXPIRED:1898625700 - a special case of the previous response, displayed as unlimited subscription
http://api.rainloop.net/activate/FQDN/key- attempts to activate a subscription for FQDN using key.- OK - assumed successful activation
- TOO_MANY_CONNECTIONS - assumed failed activation due to rate limit
- ERROR:string - assumed failed activation, the reason is specified in string
The first request is sent when accessing both user and admin interface in order to disable premium features when the subscription is expired or had never existed for the FQDN. The latter is sent when subscription key activation is attempted (after passing local checks).
The API is not used for anything else at the moment.
As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.
Or you can use #2148, as the legal status of this code is uncertain, both because of the presence of AGPLv3 LICENSE file in the root of this repository, and #450. And also, DRM is not good, as you can see (there are many cases of things getting broken because of activation servers going down). Alternatively, switch to something which doesn't have uncertain support status for years.
A thing was missed, TOO_MANY_CONNECTIONS exists for the first request as well..
@yeupou I just realized I did not explain why it is the same issue as #2160, at all.
As you can see here, this function is in Prem provider, and it calls this->Type().
Type function calls $this->Parser($this->Fetcher(false, true)) and gets its result, as you can see here.
In the Fetcher function, you can see the request itself here.
Here you can see the line which defines APP_API_PATH.
So it takes some time until the request times out, and the execution proceeds.
As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.
Prem provider (which does both of the requests) is not present in the community edition, so it is "fixed".
As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.
How did you manage to do that ?
I do not have a license too but I have the timeout as well.
In my case, I decided it was easier to move to snappymail.
Plus, I did not like much finding by accident that servers where pinging a distant server while I never subscribed to anything like this and found nothing in this regards in config.
As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.
How did you manage to do that ? I do not have a license too but I have the timeout as well.
In my case:
-Download community edition from official site
-In previous instalation folder remove everything but the data folder (remember to keep backups of everything)
-Extract index.php and rainloop folder from the downloaded community zip
As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.
How did you manage to do that ? I do not have a license too but I have the timeout as well.
If you are lazy to apply entire #2148, open /rainloop/v/1.16.0/app/libraries/RainLoop/Providers/Prem.php, and replace this code with return 'EXPIRED:1898625600'; if you want to have access to premium feature, or with return 'NO'; if you don't want it.
If you insist on switching to Community edition regardless, you should actually care to search for word "community" in this repository (here), you will notice that the only differences are the absence of Prem.php and different JS files. So you just remove this file and replace the JS files with the ones in Community edition archive.
Missed a few files, here is an actual diff.
Does anyone know how to contact guy other than support@ email ? We paid license $300 less than 2 months ago and now we can't even know if developer is alive or not..
Does anyone know how to contact guy other than support@ email ? We paid license $300 less than 2 months ago and now we can't even know if developer is alive or not..
Treat it as wasted money and don't help copyright holders get more rich. Assuming they are even copyright holders (see issues mentioned earlier).
You should have taken a look at what you are paying for.
IMHO $300 is insane amount for just branding and simple updater, which can be done by another programmer for much cheaper.
( unfortunately snappymail that is a more-or-less rewrite of rainloop has the appdata-stuck problem as well - at least with 2 apaches in a row )