-
Notifications
You must be signed in to change notification settings - Fork 20
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
Execute middleware stack for requests not matching any endpoint or mount point. #53
Comments
@adamluzsi , What would be the best approach to get the current list of the middleware in the project and the order? |
Each endpoint can possess its own middleware stack. Representing middleware in a comprehensible manner can be tricky, especially when dealing with procedures. This would benefit from thorough research and user feedback. Perhaps it's a good idea to gather insights from colleagues on this. Personally, I tend to review the class definition to understand the middleware stack and its mount points. What is your take on it currently? |
ok some context 0 howether if I do this it does the difference is that one is in the config.ru and one is using the middleware block. what would have been useful was to see the order on which the middleware were being applied. In rails can see aa list when you run rails middleware I have looked at the code in rails but right now with my level of understanding it is beyond me I am learning more everyday so will soon get it. The point I am making is it is far from simple or minimal. so my real question is what would be a very simple minimalist approach for just keeping tack of the order Middlewares. I looked in https://github.com/rack-app/rack-app/blob/master/lib/rack/app/singleton_methods/middleware.rb and found
could we add more information to the @middlewares collection and expose it? I admit it is a naive approach , but until learn more about how this stuff works that is all I have lol . hope this make sense |
I was thinking, if this is something that I can tackle myself as it Is outside the scope to the project that is cool too, but would be good to know where to start! |
I may not wholly grasp the issue when you mention, "Omniauth does not work." However, if I'm reading between the lines, it seems the OmniAuth middleware isn't just functioning as a simple middleware. Instead, it might be extending the routing logic. When it detects specific paths, like "/auth/:provider", it could interrupt the pipeline pattern propagation and send back a response instead of the original application. With its Radix tree based routing strategy, Rack-app avoids executing any middleware if no matching endpoint is found. This is because middleware execution is strictly tied to endpoints. There are a few potential workarounds:
For now, if you have a middleware that doesn't tie directly to the endpoint but functions more like a hijacker, I'd recommend config.ru or mounting a rack-compliant application with that middleware. I hope this offers some clarity and support in navigating the situation. I get back to you after doing some user interviews with other rack-app users who are acquaintances. |
Typically, OmniAuth's endpoints are better suited for a rack application rather than a middleware. However, not all frameworks support mounting, which is likely why the OmniAuth team chose to implement their solution through middleware hijacking rather than creating a mountable OmniAuth controller application. |
@thilonel, I'd appreciate your input on this. Do you have any use-cases that might be impacted if we change the behavior such that the middleware stack still executes, even if an endpoint results in a 404? |
@adamluzsi first of all thanks again for the fantastic explanation , I appreciate the time as it is really helping my learning. Now looking back on when I created this ticket I wish I would have used anything apart from OmniAuth as an example because after looking into what you mentioned above I can see how does work differently to other middleware. The core issue is actually more about visibility. From my research I found that the order of which a middleware is included matters The issues I was actually highlighting was that if Included the OmniAuth middleware in the config ru it worked because it was earlier in the stack than the app. It took me a long while solving my problem ( putting the OmniAuth in confi.ru) because I do not have visibility on what is in the middleware stack and in what order they will be applied. Is there minimalist way of achieving that visibility? |
Would having a detailed list of all middlewares actually assist in this situation? If such a feature were available, it would essentially confirm what you've already observed: OmniAuth is in your middleware stack. For a quick check, consider using Ruby's pretty printer: require 'pp'
# At the end of your Rack::App class:
pp middlewares This would reinforce what you've identified in your class: the presence of the middleware. In light of this, I feel our initial analysis remains accurate. The challenge doesn't lie in middleware visibility, but in rack-app's inability to execute middleware when the requested endpoint isn't recognized. OmniAuth operates based on this premise, relying on unknown paths to execute its internal logic. I hope this sheds some light on the situation. |
I tried the above and it worked and I got the information I need What was also cool , was I went through looking at the CLI and I found a really interesting switch it list all the routes and the Middlewares I can get all the information I need from here to answer the question I had above! if you play with the order of the middleware you can see it reflected. Sooo thanks for the speedy reply and help! |
I can see that using OmnIAuth was the wrong example to use because it was not like the other middleware, but your explanation helped and this has been fantastic learning exercise. |
However, I think the core issue persists, related to middleware that extends the routing logic with paths unbeknownst to your application, correct? It's amusing, but I genuinely overlooked the options of the routes CLI command helper. 😅
|
Ok just reread the above and looked further and like light switch it all make sense. Yes the problem still exists.
If I understand this correctly
Instead of change to rack app , could we use an adapter pattern approach, a rack app/middleware/adaapter ? I have used and looked through lots of alternative frameworks based on rack and I settled on rack-app because for me it has the perfect blend of simplicity and power with a code base that I can actually read and understand.So I do understand the resistance to change it as it has been stable for so long. I will admit I am coming from a place of ignorance so my idea could be missing the mark so any feedback negative or positive will help and will be appreciated. @adamluzsi I look forward to see what approach you take. |
@dekubu, thank you for being open. Remember, we're equal partners here. I value your input, but there's no need to be hard on yourself. Everyone has unique knowledge to offer. So, let's have a great time collaborating and supporting each other. :) In response to your proposal, I think implementing an adapter pattern approach is quite feasible.
class MyApp < Rack::App
oauth = Rack::Builder.new do
use OmniAuth...
run(lambda { |env|
[404, {'Content-Type' => 'text/plain'}, ['Not Found']]
})
end
mount oauth, to: "/oauth"
end |
@thilonel, if you find the time, could you identify some scenarios where executing the middleware stack in cases of endpoint not being found might have a negative impact on applications? If no significant problems emerge from this, it seems we would be in a good position to proceed. |
I ran into a situation when using rack middlewares
I would like to implement
the idea being, when I call
The text was updated successfully, but these errors were encountered: