(The specific line-by-line changes here aren't important. These lines look like bugfixes because they're bugfixes. It's the big picture, the pivot in approach to how login works, that's important.)
Big picture: with improvements to miscService.redirectUser it is now preferable to trigger all logins via miscService.redirectUser or via direct hyperlink to login (in the case of a login button on public.my, say.)
Therefore:
Deprecate the undocumented configuration of the "silent" login URL. "Silent" logins in the background on asynchronous requests will work in strictly a subset of the situations in which miscService.redirectUser will work.
Change default configuration of "silent" login to not be "silent", so that where it is still used it will fail less confusingly.
Fix the miscService.redirectUser feature to correctly set refUrl so that it successfully redirects back to the user's place in the app after login
Fix a couple invocations of miscService.redirectUser to correctly convey the status code
Heads up, this one's important.
(The specific line-by-line changes here aren't important. These lines look like bugfixes because they're bugfixes. It's the big picture, the pivot in approach to how login works, that's important.)
Big picture: with improvements to
miscService.redirectUserit is now preferable to trigger all logins viamiscService.redirectUseror via direct hyperlink to login (in the case of a login button on public.my, say.)Therefore:
miscService.redirectUserwill work.miscService.redirectUserfeature to correctly setrefUrlso that it successfully redirects back to the user's place in the app after loginmiscService.redirectUserto correctly convey the status codeExpected result: with corresponding changes in uPortal-home ( https://github.com/uPortal-Project/uportal-home/pull/922 ), we get to fewer code paths that trigger login with better results.
Review for security considerations
PR considerations checklist:
CHANGELOG.mdto reflect this PR's change.