Open amanzone opened 1 year ago
Does your kimai instance is self-hosted ? If it does, does it use a self-signed certificate ?
Yes, it's a self hosted kimai installation. It uses a Let's Encrypt certificate.
BTW, I forgot to mention that the old Kemai version I'm coming from (0.4.0) works without issues.
Are you able to build/run from source ?
Yes, I built version 0.9.3 I'm currently testing
Ok then please comment line 121 of kimaiClient.cpp
Build and try.
Very well, thanks! I'll try and let you know. Good evening!
Thank you.
So, I've commented out line 121 and built. Unfortunately there's no difference that I can see.
Here comes the full log:
myuser@myPC:~/Tmp/kemai-0.9.3$ ./build/src/Kemai
qt.core.qobject.connect: QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*)
[2023-05-23 08:06:42.949] [kemai] [debug] ===> [GET] https://myurl.com/api/customers
[2023-05-23 08:06:42.953] [kemai] [debug] ===> [GET] https://myurl.com/api/projects
[2023-05-23 08:06:42.954] [kemai] [debug] ===> [GET] https://myurl.com/api/activities
[2023-05-23 08:06:42.954] [kemai] [debug] ===> [GET] https://myurl.com/api/users/me
[2023-05-23 08:06:42.955] [kemai] [debug] ===> [GET] https://myurl.com/api/version
[2023-05-23 08:06:42.955] [kemai] [debug] ===> [GET] https://myurl.com/api/config/timesheet
[2023-05-23 08:06:42.956] [kemai] [debug] ===> [GET] https://myurl.com/api/timesheets/active
[2023-05-23 08:06:43.670] [kemai] [error] <=== Error on request [timesheets/active]: Error transferring https://myurl.com/api/timesheets/active - server replied:
Bad Gateway
[2023-05-23 08:06:43.671] [kemai] [error] Client error: Error on request [timesheets/active]: Error transferring https://myurl.com/api/timesheets/active - server replied:
Bad Gateway
[2023-05-23 08:06:43.884] [kemai] [error] <=== Error on request [projects]: Error transferring https://myurl.com/api/projects - server replied:
Bad Gateway
[2023-05-23 08:06:43.984] [kemai] [error] <=== Error on request [customers]: Error transferring https://myurl.com/api/customers - server replied:
Bad Gateway
[2023-05-23 08:06:44.085] [kemai] [error] <=== Error on request [users/me]: Error transferring https://myurl.com/api/users/me - server replied:
Bad Gateway
[2023-05-23 08:06:44.085] [kemai] [error] Client error: Error on request [users/me]: Error transferring https://myurl.com/api/users/me - server replied:
Bad Gateway
[2023-05-23 08:06:44.377] [kemai] [error] <=== Error on request [activities]: Error transferring https://myurl.com/api/activities - server replied:
Bad Gateway
[2023-05-23 08:06:45.185] [kemai] [debug] <=== [version]: {"version":"1.30.5","versionId":13005,"candidate":"stable","semver":"1.30.5-stable","name":"Ayumi","copyright":"Kimai 1.30.5 by Kevin Papst and contributors."}
[2023-05-23 08:06:45.185] [kemai] [debug] ===> [GET] https://myurl.com/api/plugins
[2023-05-23 08:06:45.198] [kemai] [debug] <=== [config/timesheet]: {"trackingMode":"default","defaultBeginTime":"now","activeEntriesHardLimit":1,"activeEntriesSoftLimit":1,"isAllowFutureTimes":true,"isAllowOverlapping":true}
[2023-05-23 08:06:45.598] [kemai] [debug] <=== [plugins]: [{"name":"ExpensesBundle","version":"1.33.0"}]
On the other hand, if I test the old version I've been using so far, everything seems to be working fine. Here come the full log for version 0.4.0:
myuser@myPC:~/Tmp$ ./kemai/build/src/app/Kemai
[2023-05-23 08:13:13.059] [kemai] [debug] ===> [GET] https://myurl.com/api/timesheets/active
[2023-05-23 08:13:13.806] [kemai] [debug] <=== [{"user":1,"tags":[],"id":60436,"begin":"2023-05-23T08:02:32+0200","end":null,"duration":0,"activity":{"id":158,"project":{"id":60,"customer":{"id":22,"name":CUTCUTCUT":[]}]
[2023-05-23 08:13:13.820] [kemai] [debug] ===> [GET] https://myurl.com/api/customers
[2023-05-23 08:13:13.820] [kemai] [debug] ===> [GET] https://myurl.com/api/users/me
[2023-05-23 08:13:14.705] [kemai] [debug] <=== [{"id":29,"name":CUTCUTCUT}]
[2023-05-23 08:13:14.705] [kemai] [debug] ===> [GET] https://myurl.com/api/projects?customer=22
[2023-05-23 08:13:14.912] [kemai] [debug] <=== {"language":"en","timezone":"Europe/Berlin","preferences":[CUTCUTCUT}
[2023-05-23 08:13:15.251] [kemai] [debug] <=== [{"parentTitle":CUTCUTCUT]
[2023-05-23 08:13:15.251] [kemai] [debug] ===> [GET] https://myurl.com/api/activities?project=60
[2023-05-23 08:13:15.652] [kemai] [debug] <=== [{"parentTitle":CUTCUTCUT]
If I try "Refresh Cache" it seems most times the APIs are returing valid data, but still the window is not pupulated:
[2023-05-23 08:26:13.030] [kemai] [debug] ===> [GET] https://myurl.com/api/customers
[2023-05-23 08:26:13.030] [kemai] [debug] ===> [GET] https://myurl.com/api/projects
[2023-05-23 08:26:13.030] [kemai] [debug] ===> [GET] https://myurl.com/api/activities
[2023-05-23 08:26:14.108] [kemai] [error] <=== Error on request [activities]: Error transferring https://myurl.com/api/activities - server replied:
Bad Gateway
[2023-05-23 08:26:14.820] [kemai] [debug] <=== [projects]: [LONGLISTOFPROJECTS]
[2023-05-23 08:26:15.029] [kemai] [debug] <=== [customers]: [LONGLISTOFCUSTOMERS]
I don't see any reason right now. Is it possible to send PM me with your instance url and some limited credentials ?
Ufortunately I have checked but my company is not willing to do this for security reasons, I'm sorry.
Is there any test I can do that may help?
I understand. I will add some more debug message and track more info about the connection. Can you run your curl test with new params:
curl -v -X GET "https://myurl.com/api/projects" -H "accept: application/json" -H "X-AUTH-USER: myuser" -H "X-AUTH-TOKEN: mykey" | grep -i "^< location:"
Here it comes:
myuser@myPC:~/Tmp/kemai-0.9.3$ curl -v -X GET "https://myurl.com/api/projects" -H "accept: application/json" -H "X-AUTH-USER: myuser" -H "X-AUTH-TOKEN:
mykey" | grep -i "^< location:"
Note: Unnecessary use of -X or --request, GET is already inferred.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.168.28.11:443...
* Connected to myurl.com (192.168.28.11) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS header, Certificate Status (22):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.2 (IN), TLS header, Finished (20):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [15 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [4060 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* TLSv1.2 (OUT), TLS header, Finished (20):
} [5 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=myurl.com
* start date: Apr 1 08:59:21 2023 GMT
* expire date: Jun 30 08:59:20 2023 GMT
* subjectAltName: host "myurl.com" matched cert's "myurl.com"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* h2h3 [:method: GET]
* h2h3 [:path: /api/projects]
* h2h3 [:scheme: https]
* h2h3 [:authority: myurl.com]
* h2h3 [user-agent: curl/7.85.0]
* h2h3 [accept: application/json]
* h2h3 [x-auth-user: myuser]
* h2h3 [x-auth-token: mykey]
* Using Stream ID: 1 (easy handle 0x561c1a792ec0)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
> GET /api/projects HTTP/2
> Host: myurl.com
> user-agent: curl/7.85.0
> accept: application/json
> x-auth-user: myuser
> x-auth-token: mykey
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [130 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
} [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
< HTTP/2 200
< cache-control: no-cache, private
< content-type: application/json
< date: Tue, 23 May 2023 10:40:29 GMT
< server: Apache/2.4.38 (Debian)
< x-powered-by: PHP/8.1.12
<
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
* TLSv1.2 (IN), TLS header, Supplemental data (23):
{ [5 bytes data]
100 15079 0 15079 0 0 34522 0 --:--:-- --:--:-- --:--:-- 34744
* Connection #0 to host myurl.com left intact
When Kemai tries to retrieve from the server info about existing Customers, Activities, Projects... most often than not it fails with errors like:
and/or
and/or
etc..
The end result is that it fails to populate the running timesheet window, as in picture below:
I initially thought it was an issue with the kimai server (running Kimai 1.30.5) but, testing the APIs with curl (e.g.)
curl -X GET "https://myurl.com/api/projects" -H "accept: application/json" -H "X-AUTH-USER: myuser" -H "X-AUTH-TOKEN: mykey"
orcurl -X GET "https://myusr.com/api/activities" -H "accept: application/json" -H "X-AUTH-USER: myuser" -H "X-AUTH-TOKEN: mykey"
etc...it never fails.
May it be an issue with the version of kimai I'm running (not the latest)? I do not think so, since kimai_cmd seems not to be failing.
May it be an issue with some timeout? Is seems not to be the case since with curl the replies come very fast, with no delay at all...