[FOLIO-1751] login requests hang Created: 28/Jan/19 Updated: 03/Jun/20 Resolved: 07/Feb/19 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Bug | Priority: | P2 |
| Reporter: | Zak Burke | Assignee: | Adam Dickmeiss |
| Resolution: | Done | Votes: | 0 |
| Labels: | platform-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||
| Sprint: | Core: Platform - Sprint 56 | ||||||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||||||
| Description |
|
Login requests hang indefinitely on folio-snapshot after signing in with a user account that has no permissions:
Module test: users:new_user
Login > Create new user > Logout > Login as new user > Logout > Login > Edit new user and confirm changes
✓ should load login page (7028ms)
✓ should login as diku_admin/admin (1877ms)
Test suite @folio/users:2.20.0
Live module @folio/users:2.20.1000571 (http://folio-snapshot.aws.indexdata.com)
✓ should open app and find version tag (379ms)
✓ should extract a patron group value (2278ms)
✓ should create a user: ssmith1548845142414/ssmith1548845142414 (2184ms)
✓ should logout (678ms)
✓ should login as ssmith1548845142414/ssmith1548845142414 (289ms)
✓ should logout (577ms)
1) should login as diku_admin/admin
The integration test users:new_user failed. Follow up manual testing shows that login requests hang after signing in and out with a new user account that has no permissions. Reloading the browser resolves the issue. It's worth noting that the browser's network console shows three failed requests for the unprivileged user, but this happens in both folio-snapshot and folio-testing, and the problem with login requests hanging happens only in folio-snapshot. |
| Comments |
| Comment by Zak Burke [ 28/Jan/19 ] |
|
I filed this under FOLIO though I suspect some debugging will point us toward moving it under a backend module. Although reloading the browser allows logins to succeed, suggesting this is a front-end issue, in fact the same UI code is running on folio-snapshot (where the problem occurs) and folio-testing (where it does not) suggesting to me that the problem must lie with the backend as that is the only difference between these environments. A diff of the modules at /settings/about shows several backend module discrepancies. None stand out as obvious red-herrings, but that's the best line of inquiry I can think of: $ diff snapshot.txt testing.txt 14c14 < @folio/users 2.20.1000566 --- > @folio/users 2.20.1000567 18,19c18,19 < @folio/orders 1.1.1000163 < @folio/vendors 1.3.100092 --- > @folio/orders 1.1.1000164 > @folio/vendors 1.3.100093 27c27 < @folio/myprofile 1.4.100044 --- > @folio/myprofile 1.4.100045 37c37 < On URL http://folio-snapshot-551.aws.indexdata.com:9130 --- > On URL http://folio-testing-backend01.aws.indexdata.com:9130 39c39 < 54 modules --- > 67 modules 49a50 > My profile (folio_myprofile-1.4.100045) 50a52 > Description for orders (folio_orders-1.1.1000164) 61a64 > User management (folio_users-2.20.1000567) 62a66,68 > Description for ui-vendors (folio_vendors-1.3.100093) > Audit Module (mod-audit-0.0.4-SNAPSHOT.23) > Audit Filter Module (mod-audit-filter-0.0.5-SNAPSHOT.23) 71a78,79 > email (mod-email-1.1.0-SNAPSHOT.9) > mod-event-config (mod-event-config-1.1.0-SNAPSHOT.9) 73a82 > GraphQL API for FOLIO (mod-graphql-1.1.1000199) 80a90 > OAI-PMH Repository Module (mod-oai-pmh-1.0.2-SNAPSHOT.40) 83a94 > Patron Services Module (mod-patron-1.2.1-SNAPSHOT.29) 85a97 > Mod sender (mod-sender-1.1.0-SNAPSHOT.4) 89a102 > User import (mod-user-import-3.1.1-SNAPSHOT.31) 92c105 < Vendor CRUD module (mod-vendors-1.1.0-SNAPSHOT.33) --- > Vendor CRUD module (mod-vendors-1.1.0-SNAPSHOT.36) 98c111 < 92 interfaces --- > 113 interfaces 103a117 > audit 1.0 113d126 < contact_category 1.0 118a132 > email 1.0 123a138 > graphql 0.0.0 146a162,163 > message-delivery 1.0 > mod-event 1.0 149a167 > oai-pmh 1.0 171a190 > patron 1.1 186a206 > user-import 2.0 189,190c209,224 < vendor 1.0 < vendor_category 1.0 --- > vendor-storage.accounts 1.0 > vendor-storage.addresses 1.0 > vendor-storage.agreements 1.0 > vendor-storage.aliases 1.0 > vendor-storage.categories 1.0 > vendor-storage.contact-persons 1.0 > vendor-storage.edi-ftps 1.0 > vendor-storage.edi-jobs 1.0 > vendor-storage.edis 1.0 > vendor-storage.emails 1.0 > vendor-storage.interfaces 1.0 > vendor-storage.phone-numbers 1.0 > vendor-storage.url 1.0 > vendor-storage.vendor-contact-persons 1.0 > vendor-storage.vendor-types 1.0 > vendor-storage.vendors 1.0 247c281 < @folio/users 2.20.1000566 depends on: --- > @folio/users 2.20.1000567 depends on: 270c304 < @folio/orders 1.1.1000163 depends on: --- > @folio/orders 1.1.1000164 depends on: 277c311 < @folio/vendors 1.3.100092 depends on: --- > @folio/vendors 1.3.100093 depends on: 290c324 < @folio/myprofile 1.4.100044 declares no dependencies --- > @folio/myprofile 1.4.100045 declares no dependencies |
| Comment by Marc Johnson [ 28/Jan/19 ] |
|
Zak Burke Hmm, as permissions were mentioned, I wonder if there is a module permission missing that results in the login for the user without permissions failing. I don't know why that would affect a subsequent request, only in the snapshot environment. |
| Comment by Marc Johnson [ 28/Jan/19 ] |
|
The three failed requests seem to relate to configuration entries. I wonder if failing to read those sometimes results in a corrupt state in the UI? Maybe all users need the permissions to read config? (or the UI needs to fetch that kind of info using different credentials entirely) |
| Comment by Zak Burke [ 28/Jan/19 ] |
GET http://folio-snapshot-551.aws.indexdata.com:9130/configurations/entries?query=(module=ORG%20and%20configName=localeSettings) Access requires permission: configuration.entries.collection.get GET http://folio-snapshot-551.aws.indexdata.com:9130/configurations/entries?query=(module=PLUGINS) Access requires permission: configuration.entries.collection.get GET http://folio-snapshot-551.aws.indexdata.com:9130/configurations/entries?query=(module=ORG%20and%20configName=bindings) Access requires permission: configuration.entries.collection.get |
| Comment by Zak Burke [ 30/Jan/19 ] |
|
This continues to be a barrier to achieving passing integration tests on folio-snapshot. The server-side modules present on folio-testing but absent on folio-snapshot seem like the most likely candidates to investigate: > Description for orders (folio_orders-1.1.1000169) > Audit Module (mod-audit-0.0.4-SNAPSHOT.23) > Audit Filter Module (mod-audit-filter-0.0.5-SNAPSHOT.23) > email (mod-email-1.1.0-SNAPSHOT.12) > mod-event-config (mod-event-config-1.1.0-SNAPSHOT.9) > GOBI® Module (mod-gobi-1.2.0-SNAPSHOT.55) > GraphQL API for FOLIO (mod-graphql-1.1.1000199) > OAI-PMH Repository Module (mod-oai-pmh-1.0.2-SNAPSHOT.40) > Patron Services Module (mod-patron-1.2.1-SNAPSHOT.29) > Mod sender (mod-sender-1.1.0-SNAPSHOT.4) > User import (mod-user-import-3.1.1-SNAPSHOT.31) Curiously, folio_circulation is present in two versions on folio-testing (1.5.1000175, 1.5.1000176) but only one on folio-snapshot (1.5.1000176). John Malconian, Wayne Schneider, is it worth trying to investigate this separately from untangling the dependency issues that prevent those modules from being installed on folio-snapshot or do you think we should focus on that problem and see if this one falls away as a knock-on effect? If you want to pursue this problem independently, the integration test to run is
stripes test nightmare stripes.config.js --run users:new_user --uiTest.username diku_admin --uiTest.password admin --url http://folio-snapshot.aws.indexdata.com
|
| Comment by Marc Johnson [ 30/Jan/19 ] |
|
Zak Burke I think it is worth separating this into chunks if possible. I agree the dual instances of folio_circulation and the configuration entry failures are two separate threads to follow. If login requires one of those modules that aren’t present, then we likely have an implicit dependency and that needs changing. I think to investigate the server aspects more, we need the Okapi, mod-users-bl and mod-login log output following a hang from that test run. And we likely need Wayne Schneider or John Malconian for that. |
| Comment by Zak Burke [ 30/Jan/19 ] |
|
Masterful spelunking by Michal Kuklis uncovered some interesting additional material: after reloading, the requests to /version and /proxy/tenants/diku/modules?full=true fail but stripes continues to load and show the login screen. This allows you to login, but leads to all kinds of problems in the UI because any code surrounded by an IfInterface check fails because stripes believes no interfaces are present. The stripes side of this is clearly a different issue, but the fact that the version and modules requests fail seems likely to be relevant. |
| Comment by Michal Kuklis [ 30/Jan/19 ] |
|
Just for the record Zak Burke was in the same cave with me so we uncovered this together. |
| Comment by Wayne Schneider [ 01/Feb/19 ] |
|
The problem is reproducible using a VM built from the folio/snapshot Vagrant box. This is the sequence I used to reproduce:
Here is the Wireshark log of the sequence: (full pcap file attached: DumpLogin01.pcap Note that the last http request that is made is an OPTIONS request to /bl-users/login. Okapi never responds. I will attempt to reproduce the issue using just API calls, outside of Stripes. |
| Comment by Wayne Schneider [ 05/Feb/19 ] |
|
This behavior is not present on the Q4 release build Jakub Skoczen |
| Comment by Adam Dickmeiss [ 06/Feb/19 ] |
|
Okapi 2.24.1 out. Unfortunately, it's not enough (it works now , but only if mod-audit-filter is disabled). So there will have to be another Okapi 2.24.2 out - hopefully tomorrow. |
| Comment by Adam Dickmeiss [ 06/Feb/19 ] |
|
Okapi 2.24.2 out. This should fix this issue. |
| Comment by Wayne Schneider [ 07/Feb/19 ] |
|
folio-snapshot.aws.indexdata.com no longer exhibits this behavior http://folio-snapshot.aws.indexdata.com:9130/_/version : 2.24.2 |
| Comment by Wayne Schneider [ 07/Feb/19 ] |
|
Zak Burke – is there anything else you want to investigate with this, or should we go ahead and close the issue? |
| Comment by Zak Burke [ 07/Feb/19 ] |
|
My regression tests pass – LGTM! |