Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shield::Middleware doesn't play well when app is on a sub URI #21

Open
LichP opened this issue Jan 22, 2015 · 2 comments
Open

Shield::Middleware doesn't play well when app is on a sub URI #21

LichP opened this issue Jan 22, 2015 · 2 comments

Comments

@LichP
Copy link

LichP commented Jan 22, 2015

Shield::Middleware expects the supplied url to be absolute. This makes life difficult when the app is on a sub uri as the url is passed in class context, and there doesn't seem to be any mechanism for determining the sub uri the app is mounted on at that point. Is there an alternative to simply passing in e.g. '/suburi/login', or could Shield::Middleware#headers prefix env["SCRIPT_NAME"] to url to get round this?

@cyx
Copy link
Owner

cyx commented Jan 22, 2015

One possible solution is to accept a lambda which takes the env as the parameter, that way it will be more generic.

The resulting app code will be longer, but I think it would be fine.

Something like:

    use Shield::Middleware, lambda { |env| env["SCRIPT_NAME"] + "/login" }

The alternative is a specialized solution for just script name:

   use Shield::Middleware, "/login", mounted: true

s/mounted/something better (just throwing it out there)

@LichP
Copy link
Author

LichP commented Jan 23, 2015

I'd lean towards the lambda solution as being the most flexible. Is their any harm in doing env["SCRIPT_NAME"] + url by default though? When app is mounted on root, ``env["SCRIPT_NAME"]` should be empty anyway , I believe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants