You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In many Apache configurations (since this is the default value), Apache will refuse any request which contains a URL encoded forward slash in the path component of a URL (see AllowEncodedSlashes Directive).
Given this limitation, it is pretty much impossible to use the return_to named parameter on the above configuration. I realise that you can achieve almost the same result using Auth.redirect session variable, but sessions time out and this can cause confusion to end users. I also realise that the controller can be overridden, but if the functionality is there, it makes sense that it be compatible with most configurations.
I propose that in addition to checking for the return_to named parameter (for backwards compatibility), a query string parameter should also be checked. Perhaps someone else has a better solution.
This is just a suggestion. Maybe no one else has ever had this issue in which case it wouldn't make sense to add this given this is a limitation on a specific setup (albeit a common setup).
The text was updated successfully, but these errors were encountered:
In many Apache configurations (since this is the default value), Apache will refuse any request which contains a URL encoded forward slash in the path component of a URL (see AllowEncodedSlashes Directive).
Given this limitation, it is pretty much impossible to use the
return_to
named parameter on the above configuration. I realise that you can achieve almost the same result using Auth.redirect session variable, but sessions time out and this can cause confusion to end users. I also realise that the controller can be overridden, but if the functionality is there, it makes sense that it be compatible with most configurations.I propose that in addition to checking for the
return_to
named parameter (for backwards compatibility), a query string parameter should also be checked. Perhaps someone else has a better solution.This is just a suggestion. Maybe no one else has ever had this issue in which case it wouldn't make sense to add this given this is a limitation on a specific setup (albeit a common setup).
The text was updated successfully, but these errors were encountered: