This change fixes the app-platform login modal to:
use new auth/login endpoints if v41 or greater
use old struts login (/dhis-web-commons-security/login.action) if v40 or less
Detecting version
If a server is v41 or greater, api/loginConfig is accessible with the version. Therefore, this PR assumes that if a request to api/loginConfig succeeds that the server is v41+. This logic, obviously, has some limitations because the request could fail for other reasons (e.g. server is down), but this is not in general likely.
UI Improvements
General
I've disabled the log in button when login is in progress.
Normal apps
When using api/auth/logic, we have a REST api and will get a 400-range error back if authentication fails. This means that we can catch errors and display them back to the user. When using the struts endpoint, even successful authentication errors out. As a consequence, I've added error display if the server is detected as v41+ and have otherwise used the previous approach of refreshing the window (for v40 or less).
Note that you can successfully authenticate (regardless of version), and have CORS errors that are only detected on reload (note that this appears like the older version workflow: you authenticate, the app reloads, and then the cors error leads to the login modal to display again). I have not made any modifications to specifically catch CORS errors and display them.
v42:
v39:
Login app
I have added some handling for the case where you are have a login app. Previously, running the login app required that you specify the DHIS2_BASE_URL environment variable. This adds a bit more refactoring to the code, but I think it's worth it as it makes login app development less finicky and also would be relevant if we introduce "public" app types in the future.
Code notes
I thought about doing a bit more a refactor (e.g. to get rid of need for page refreshing with v41+, but then I felt that was a bit complicated and not worth the effort at the moment).
See https://dhis2.atlassian.net/browse/LIBS-600
Summary
This change fixes the app-platform login modal to:
Detecting version
If a server is v41 or greater, api/loginConfig is accessible with the version. Therefore, this PR assumes that if a request to api/loginConfig succeeds that the server is v41+. This logic, obviously, has some limitations because the request could fail for other reasons (e.g. server is down), but this is not in general likely.
UI Improvements
General
I've disabled the log in button when login is in progress.
Normal apps
When using api/auth/logic, we have a REST api and will get a 400-range error back if authentication fails. This means that we can catch errors and display them back to the user. When using the struts endpoint, even successful authentication errors out. As a consequence, I've added error display if the server is detected as v41+ and have otherwise used the previous approach of refreshing the window (for v40 or less).
Note that you can successfully authenticate (regardless of version), and have CORS errors that are only detected on reload (note that this appears like the older version workflow: you authenticate, the app reloads, and then the cors error leads to the login modal to display again). I have not made any modifications to specifically catch CORS errors and display them.
v42:
v39:
Login app
I have added some handling for the case where you are have a login app. Previously, running the login app required that you specify the
DHIS2_BASE_URL
environment variable. This adds a bit more refactoring to the code, but I think it's worth it as it makes login app development less finicky and also would be relevant if we introduce "public" app types in the future.Code notes
I thought about doing a bit more a refactor (e.g. to get rid of need for page refreshing with v41+, but then I felt that was a bit complicated and not worth the effort at the moment).