I thought that was a small bug, but turns out (at least that's my understanding) that there's a fundamental issue with implementing a private 301 or 302 redirection ...
The nginx config looks like this :
location /foo {
return 302 https://bar.com;
}
For such a small config with a return inside it, I found that the request is not handled by SSOwat at all. (One clue among all is the lack of header X-SSOwat as usually found in other contexts). So it never checks if the user is or not logged in, or anything related to ssowat in general (protected_urls, ...)
Note that this does not affect traditional proxy_pass blocks, so the reverse-proxy case of the app works correctly.
I thought about alternative solution using redirected_urls in ssowat configuration, but there's actually no way to do a protected redirect without having to change the code of ssowat.
But imho there's not such a big use case for protected 301 or 302 redirect ... (One could even argue that a protected 301 redirect is nonsense/dangerous since it get stored in the browser's cache).
Bottom line is : I reworked the whole is_public and redirect_type thing to fix this.
I'm opening this PR in case people want to provide feedback, but I plan to merge it in a few days if there's no complain.
As revealed by the CI, there was a weird issue about installation in private mode ...
https://ci-apps-dev.yunohost.org/jenkins/view/aleks/job/redirect_ynh%20(aleks)/10/console
I thought that was a small bug, but turns out (at least that's my understanding) that there's a fundamental issue with implementing a private 301 or 302 redirection ...
The nginx config looks like this :
For such a small config with a
returninside it, I found that the request is not handled by SSOwat at all. (One clue among all is the lack of header X-SSOwat as usually found in other contexts). So it never checks if the user is or not logged in, or anything related to ssowat in general (protected_urls, ...)Note that this does not affect traditional
proxy_passblocks, so the reverse-proxy case of the app works correctly.I thought about alternative solution using
redirected_urlsin ssowat configuration, but there's actually no way to do a protected redirect without having to change the code of ssowat.But imho there's not such a big use case for protected 301 or 302 redirect ... (One could even argue that a protected 301 redirect is nonsense/dangerous since it get stored in the browser's cache).
Bottom line is : I reworked the whole is_public and redirect_type thing to fix this.
I'm opening this PR in case people want to provide feedback, but I plan to merge it in a few days if there's no complain.
Job 11 is pending on https://ci-apps-dev.yunohost.org/jenkins/job/redirect_ynh%20(aleks)/