Hajk: Getting map config for restricted map can sometimes fail and return `[ERROR] service.auth.v2 - read ECONNRESET`
Describe the bug When AD connection is active and a map config is limited to certain groups, Backend will to a check by grabbing current user’s groups from the AD. This request seems to occasionally crash, leading to an empty array being returned, hence Backend thinks that user doesn’t belong to any group and the access to map is rejected.
At first I thought it was related to the recent changes in API versioning. But I can confirm the same behaviour in the commit before PR merge, i.e. this error happens not only in latest develop
but also in 2759c5574dd1748b88ca47fc8849272450316503 and probably the commits before that.
To Reproduce Steps to reproduce the behavior:
- Checkout
develop
- Make sure your
.env
is configured to use AD authentication. In addition, mine uses an LDAPS connection and I suspect this has to do with the certificates somehow, so if you can, try using an LDAPS as well. - Make sure that you have a map config set up and limit the access to that map to some AD group that the user you will be testing with belongs to.
- Fire up the Backend. Make sure that you see something like this in the log:
[2023-04-13T14:35:40.486] [TRACE] service.auth.v2 - Initiating ActiveDirectoryService V2
[2023-04-13T14:35:40.487] [TRACE] service.auth.v2 - Setting up AD connection to: ldaps://<domain>
[2023-04-13T14:35:40.489] [INFO] service.auth.v2 - Testing the AD connection to ldaps://<domain>…
[2023-04-13T14:35:40.557] [TRACE] service.auth - Initiating ActiveDirectoryService
[2023-04-13T14:35:40.557] [TRACE] service.auth - Setting up AD connection to: ldaps://<domain>
[2023-04-13T14:35:40.558] [INFO] service.auth - Testing the AD connection to ldaps://<domain>…
- Request the map config from the V2 API. You can do it in your browser, or
curl
or whatever you prefer. Basically,GET http://localhost:3002/api/v2/config/{yourMapConfig}
- If you can see the valid output, you’re fine. In that case restart the Backend (by typing
rs
and hittingEnter
in the console where Backend is running). - But if you got a message saying that
Error: [getMapConfig] Access to map "{yourMapConfig}" not allowed for user "{yourUserName}"
, you hit the same error as I do. From time to time… Which is really difficult to test. - So, if you had the error above, I’m certain that you can see this in your log:
[2023-04-13T14:38:35.243] [TRACE] service.auth.v2 - [getGroupMembershipForUser] No entry for '{yourUserName}' in the groups-per-users store yet. Populating…
[2023-04-13T14:38:35.935] [ERROR] service.auth.v2 - read ECONNRESET
Additional context I’m on NodeJS v18.15.0.
Locally, I logged some more info and got this in return, which makes me think this has to do with the LDAPS part:
at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20) {
errno: -54,
code: 'ECONNRESET',
syscall: 'read'
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 19 (18 by maintainers)
Commits related to this issue
- Potential fix for #1320: - See discussion in the issue - I made all new options settings in .env which allows us to have unchange production environments. - The new options in .env default to everythi... — committed to hajkmap/Hajk by jacobwod a year ago
- Potential fix for #1320: (#1337) - See discussion in the issue - I made all new options settings in .env which allows us to have unchange production environments. - The new options in .env default ... — committed to hajkmap/Hajk by jacobwod a year ago
- Minor fix: config option parsing logic was totally broken - my bad. It's fixed now. Doesn't solve the latest issues regarding #1320. — committed to hajkmap/Hajk by jacobwod a year ago
- In an attempt to aid debugging #1320 I added detailed logging to the activedirectory2 library: - Now if you set LOG_LEVEL=TRACE in `.env` you'll see a lot more details regarding the LDAP part. — committed to hajkmap/Hajk by jacobwod a year ago
Im getting ECONNRESET 98% of the time. The other 2% I get data from AD. Tried with the below settings without any luck. reconnect: true, connectTimeout: 60000, timeout: 120000
I searched the logs (almost 3 years back in time) and found only 3 occurrences of this error in production. This makes it difficult to tell if a fix will solve it or not, as I can’t seem to find a way to trigger the behaviour myself.
The solution with reconnecting that you mention @sweco-semara does sound as the correct fix, given that our theory of random connection drops from the server is right. I’ll push it into develop during today (unless you have of course). Thank you.