TLDR: Don’t use redirects in security step. Just return a 401/403 response and handle on the SC dynamic event.
Wappler’s SC uses Ajax to call the SAs and handle the response. This implementation does not understand the redirect status code. So it ends up doing nothing when you configure login/forbidden options in security restrict in a SA which is used in SC.
The flow here should be to not set these values, and let the security restrict return 401. In the SC, set the dynamic attribute of Unauthorized to handle this - and redirect the user using browser component.
So, the question now becomes - why even have these inputs?
There is just one use case for this. Ideally, these should be hidden inside, say a checkbox “redirect?”. So it should be configured in that one specific scenario (There is a post out there about this… lost in limbo probably).
The use case is when you call the SA directly.
With your current setup, just open the SA URL directly in a tab, and see the redirect work.
There are two ways to call a SA directly - Server Side Data (NodeJS) and URL/Routes (All server models) - that I know of.
As a server side data item, you can configure the SA to redirect if user does not have access - so the page they are trying to open, will not even open.
In Routes panel, you can create something called SC Routes. These are just alias for your actual SA, which can be called directly from a third party service or integration or just within the app as part of some logic.
Hope this helps.