[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: File DumpLogin01.pcap     PNG File Screen Shot 2019-02-01 at 1.52.14 PM.png    
Issue links:
Blocks
blocks UITEST-57 100% passing regression tests Closed
is blocked by OKAPI-701 hang for filter of type headers in so... Closed
is blocked by OKAPI-702 Hang for type headers when request-lo... Closed
Relates
relates to STCOR-324 stripes should halt if the request fo... Closed
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:

  1. Log in as a user with no permissions
  2. Log out
  3. Attempt to log in as any other user

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!

Generated at Thu Feb 08 23:15:39 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.