Open cybersafe-dev opened 2 years ago
This would happen for any user who signs up with Internet Explorer because the signup flow functions make use of the js spread operator which not supported by IE.
IE would still allow creation of an account where the email is the only recorded datapoint as email is passed into the function separately from the additionalData object containing schoolName, pupilCount etc (which is spread into the function).
signup.js waits for the full user document object to be truthy before allowing a navigation to the profile page. However as long as at least one piece of data is present this will pass. That check could be extended to other or all important data (e.g. user.schoolName, user.pupilCount etc) before navigating, and set a new error if not.
This would prompt a retry of the signup from the user which would either work properly or error again.
If IE was the cause this could even check the navigator.userAgent for IE and return a 'get a new browser!' error if true.
If there was an error in the document storing it would still pass the UID to the user provider which would make user truthy and allow a navigation to the profile page. However the behaviour we're seeing stores the email at the least, which by that part of the flow is pulled from the same block as other the other required data. Therefore an issue with the spread seems most likely.
If this happened and there was no email either it would probably be because of a storage failure, which could be handled by returning from the signup flow early and passing back an error message as far as signup.js. This may be a wise precaution either way.
There are other spreads in the app, mainly used for keeping track of ongoing survey scores. Despite the fact that the scores wouldn't be properly saved, it seems that the spreads are ignored by IE so no error would be raised and a user wouldn't notice anything awry.
I can't see any issue with async functions that would cause this.
Also an issue for older versions of other modern browsers https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#browser_compatibility
tl;dr: Suggested mitigation is...
Add an early return from the login flow in firebase.js if the user document storage errors, feed error messaging back to the user via setError in signup.js.
Do not allow the form to validate if IE is being used. Add terms to the validator function. Could be extended to non-supported versions of other browsers. Meaningful error messaging on this.
You could also extend the if(user) navigation check in signup.js to check datapoints inside the user object (user.schoolName, user.pupilCount etc). This also might need some useful error handling.
Some schools have appeared in the admin panel with only their email in the data stored - this means that they are being successfully authenticated and logged in, but other data not required by auth (school name, number of pupils etc) is being lost before storage or not stored at all.
The user can still log in and conduct surveys (albeit with the default quota levels which may not be correct), but the lost data is important and means CSK have to manually add it from their own records.
This has not been replicable so far, so it may be to do with a quirk of slow connection or firewall. It is also possible that the page navigates too quickly, dropping the data from state before the data storage function is complete. This may suggest an async issue.
This issue is rare, but has happened on a few occasions.