Good day!
Firstly, multi-app support is going to be a *lot* better and cleaner in Dancer2, so I doubt we want to do any really major overhauling of Dancer for this, we'd be better off just getting Dancer2 ready for primetime :)
I cannot use Dancer2 I need use a stable version of Dancer for my projects
Here we see that searching is going until the target route will be found in all applications! Imagine that we requested the url /app1/admin/... What happens? The $app1 will get path_info as /admin/... after Plack::App::URLMap and Dancer will start a searching in find_route_through_apps and will find a route of $app2! And it will call it code without middleware Auth! And protected and security data will be given for remote user without protection!
What is result? The /app1/ URLs will sometimes run app2's routes, the /app2/ URLs will sometimes run a routes of app1 and so on. [...]
At a quick glance, it sounds like you might have found the source of the issue some people have seen using multiple apps via Apache2 / Plack, where requests sometimes hit the wrong app.
Yes, but i use Starman + Dancer :-) And use nginx before for static files.
I'm not entirely sure, though.
[...]
What i suggest ?
I think Dancer should have:
1) For get & post now we can pass an options hashref before code like this get '/' => {option1 =>..., ...}, sub {} (i see this in code of Dancer but i didn't find it in docs) . I think there should be option 'route_namespace' for example. If it defined it consists a namespace of this route. If not defined it has a namespace defined in route_namespace command (point 2 here)
2) Should be command like 'prefix' but named as 'route_namespace' fro setting up namespace of routes of this application. The prefix option for real pieces in $request->path_info but this route_namespace for virtual because we cannot get a namespace from path_info (only from $request->script_name but i want to make this behavior flexible for 'route_namespace')
I'm not entirely sure this is required; I think the main fix, if it is required, is to make sure that the code that looks for matching routes can only ever consider routes within the app which is executing, if that's where the problem is.
But this code in Dancer! Dancer's code looks for matching routes. I cannot fix this problem without fixing of Dancer
Personally, I'm not all that familiar with setting up multiple appps via Plack::Builder stuff - in my usage, I've always just started up apps separately via Starman, giving great performance and isolation, and letting me tweak the number of worker processes per-app appropriately, etc, then stick Nginx in front as a caching proxy (and ready to be replaced with a load balancer if the load grows enough to require sharing across boxes).
As i wrote above i use Starman + Dancer too But i don't want use an one Dancer + Starman bundle for one virtual site And more - it's problem FOR ONE SITE for me As i wrote above i wanted to use middleware Plack::Middleware::Auth::Basic for one one path and other path without this middleware. And in this configuration i have a problem - protected data are accessed through public requests and there are random mix of routes for requests... I resolved a problem for me (https://github.com/Perlover/Dancer the branch new/mount_at and to see https://github.com/sukria/Dancer/pull/701) but after i suggested more standardable workaround. But if you want to make Dancer better i think you should research this suggestion :-) Ok, may be anybody will research this suggestion too? Perlover
Anyone else have any thoughts on this?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users