KnetSpace login from localhost/aratiny doesn't work in Chrome, works in Firefox

[marco-brandizi]

This is not crucial for the end users, but it's quite important for developing and debugging.

When I login while running the aratiny application, on localhost:8080, I can type my credentials and apparently, the code is successfully getting a positive answer from KnetSpace to the authentication request. However, the UI remains unchanged, there isn't any "welcome marco" message on the top-right side, the "Sign In" items don't change into the user name and the 'my knetspace' button.

On the contrary, in Firefox everything works fine, including the fact that the limit for the genes list box is removed.

Additionally, this is wat the Chrome Javascript console shows from the click on 'Sign In' to the disappearance of the login pop-up:

21:57:11.405 loginUtils.js:209 User isn't logged in, initalizing login Modal
21:57:11.423 google-analytics.js:117 Google Analytics tracker started with ***
21:57:11.440 google-analytics.js:50 Google Analytics, event 'ui:aratiny:uiOpened' sent

# This occurs after clicking on "Sign In"
21:57:20.751 loginUtils.js:213 logged in
21:57:20.865 localhost/:1 [DOM] Input elements should have autocomplete attributes (suggested: "current-password"): (More info: https://goo.gl/9p2vKq) <input type=​"password" name=​"password" id=​"password">​
22:09:08.011 loginUtils.js:213 logged in
22:09:08.123 localhost/:1 [DOM] Input elements should have autocomplete attributes (suggested: "current-password"): (More info: https://goo.gl/9p2vKq) <input type=​"password" name=​"password" id=​"password">​

Surprisingly, Firefox has a few more warnings during the same interaction:

logged in loginUtils.js:213:29
Some cookies are misusing the recommended “SameSite“ attribute 5
Cookie “csrftoken” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. me
Cookie “csrftoken” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. 3 me
Cookie “knetspace_token” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite 2 jwt
Cookie “csrftoken” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. 2 me
Cookie “csrftoken” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. 4 me

If I have to guess, I'd say Chrome is more restrictive than FF on the problem that the FF warning is describing (ie, cross-site permissions with KnetSpace cookies).

A quick workaround to this is testing KnetSpace-related features with FF. Chrome works with a real KneMiner instance that has a real/production URL, so in practice, we developers are the only ones affected by this problem.

[Arnedeklerk]

Thanks a lot for this Marco. Really strange! I suppose Firefox is still of the few not based on Chromium. I'd be curious to know whether it works in Safari.

That said, my feeling on this is that it'll be resolved as part of Nova, and we're rolling out our final pre-redesign update soon, with testing mostly complete already for where this would have been especially helpful (sample queries, etc).

If this does get investigated, it could be mostly for curiosity's sake and can be done last as part of 5.7... @lawal-olaotan

Thanks for checking this Marco. I don't even have FF...

[Arnedeklerk]

@marco-brandizi did we agree to migrate this? Please remind me. It's probably an issue linked only to the current knetspace implementation, so it can rest here in the backlog. Later today we can have a call with the extended team about the importance of testing early on multiple browsers.